Real-Time Vehicle Control Systems
Our vehicles are becoming more and more computer systems, computer systems with wheels, wings, propellors, and many variations such as caterpillar tracks.
Real-time vehicle control and monitoring is an important and complex scenario for advanced C++ development. In this scenario software has to be developed that can be entrusted with the well-being of the vehicle’s crew and passengers. In this scenario, we examine what libraries might prove to be valuable building blocks, what kind of architecture and control flow might be involved, and best-practices for safe systems.
As an example, we will look at a work-horse vehicle, the caterpillar tractor. The following image shows how much a modern interface might influence the design of the interior of the cab:
With this high-tech control system in mind, let’s examine the role individual Boost libraries might play.
Libraries
| Lbrary | Possible role in the tractor |
|---|---|
Real-time-ish I/O, CAN adapters, Ethernet, serial devices, timers |
|
Lock-free/shared state between control threads |
|
Sensor/command queues between acquisition and control threads |
|
Worker threads and synchronization |
|
Precise timing and control-loop periods |
|
Prevent mixing meters, feet, radians, PSI, kPa, etc. |
|
Simulating vehicle dynamics and hydraulic/engine systems |
|
Filters, interpolation, statistics, numerical functions |
|
Vehicle position, heading, paths and spatial calculations |
|
Recent sensor history / moving windows |
|
Efficiently indexing large collections of sensor/device data |
|
Diagnostics and event logging |
|
Diagnostic information after failures |
|
Portable error handling |
|
Configuration/calibration parameters |
|
Configuration and diagnostic interfaces |
|
Saving/restoring configuration or state |
|
Vehicle operating modes and state machines |
|
High-performance state-machine implementation, if appropriate |
|
Detecting arithmetic errors in safety-sensitive calculations |
|
Automated testing of control algorithms |
Architecture
The basic architecture of a vehicle control app could be as simple as:
every 10 ms
┌───────────────┐
│ Read sensors │
└───────┬───────┘
│
▼
┌───────────────┐
│ Validate data │
└───────┬───────┘
│
▼
┌───────────────┐
│ Update state │
└───────┬───────┘
│
▼
┌───────────────┐
│ Control law │
│ PID / model │
└───────┬───────┘
│
▼
┌───────────────┐
│ Send commands │
└───────┬───────┘
│
▼
wait until next 10 ms startsPID stands for Proportional-Integral-Derivative. It is one of the most common feedback-control algorithms used in engineering. (1)
Footnotes
(1) In the tractor example, “Control law — PID/model” means that the software controlling things such as hydraulic valves, blade position, engine speed, or vehicle speed could use either a PID controller, a model-based controller, or a combination of the two. Suppose the tractor’s blade is supposed to be at a particular height. The controller continuously compares desired blade height against actual blade height, the delta being treated as an error. A PID controller uses that error in three ways:
| Part | Meaning | Intuition |
|---|---|---|
P |
Proportional |
“How far away am I right now?” |
I |
Integral |
“How long have I been wrong?” |
D |
Derivative |
“How quickly am I approaching the target?” |
The P component might say: "We’re 10 cm low, so raise the blade substantially" and as the blade gets closer: "We’re only 2 cm low, so raise it much more gently". The I component notices if, for example, the blade consistently stays 1 cm below the target because of hydraulic leakage or load. The D component notices that the blade is moving rapidly toward the target and reduces the command - to help prevent overshooting.