CBSystem Software Architecture & Data Flow
From CajunBot Wiki
CBSystem includes several modules that are compiled and run as independent programs which communicate through POSIX shared memory. The software modules may run on several different machines and communicate using UDP packets over ethernet.
CBSystem is written in the C++ programming language and has many scripts written in BASH and AWK. Because of the shared memory and scripting requirements, Unix-based systems are most suitable for running CBSystem. In practice, we have always compiled and run our system on Linux machines, though with some grunt work it may be able to run on the Mac OS platform.
Contents |
[edit] How Shared Memory Works
Shared memory is a means of interprocess communication (IPC), and is usually done between distinct processes rather than separate threads of the same process. It is an extremely efficient method that has little overhead.
We use the POSIX libraries to create a section of memory that can be accessed by multiple processes running on the same system. For example, by using one producer and multiple consumers, we can temporarily store data collected from a sensor into a queue residing in main memory, that several obstacle detection processes can then dequeue data to make calculations with.
In CBSystem, we populate several different data queues of multiple types to handle the piping of data between processes.
Read More
Below are some links pertaining to shared memory:
[edit] Input & Output Data
Input data into to system primarily comes from sensor drivers. These drivers interface with the physical device to:
- Collect the latest data,
- Put it in a common packet format (queue type),
- Publish to the queue that it is the sole writer of.
Note that this process is not limited to sensor drivers, as they are one of many steps in the pipeline.
An aggregation program my collect various sources of sensor data read from the queues, and produce as output its analysis on where it believes there are neighboring obstacles to the vehicle. This step is known as sensor fusion, as many data sources are potentially merged into a single output stream.
At this point, a path planning algorithm uses its last known state and the output from the sensor fusion module to update its mission. After an iteration of the path planner executes, it then produces as output new steering data to be be by a steering controller program.
All of these processes occur in parallel and rely only on steady input to function (in most cases). After each iteration, they produce new output that is put into a data queue to be used as input to another process.
[edit] Software Modules
You might be getting the idea that CBSystem is just a collection of many individual software modules that all communicate to each other through a common mechanism, and you'd be right. That common mechanism is CBSystem's middleware known as cbipc or CBWare.
Since a common middleware has been established, CBSystem is very modular in nature. As long as a new module provides the right output data, it is pretty much free to do what it wants.
This is very powerful because it means that a new path planner module can be substituted at any time, for example. It could choose to read from a different set of data queues as input, but still writes to the steering queue as output. It may choose to ignore sensory input entirely.
Suppose a new steering controller were designed such that it read from a data queue that contained current air pressure in each of the tires. Given a sudden drop in air pressure, this new steering controller would react safely to bring the vehicle to a halt, despite what the path planner may be writing to the steering queue. It is this powerful modularity that allows CBSystem as a whole to be flexible and new capabilities to be added easily.
[edit] Data Flow
As the diagram below shows, there is a certain data flow that must be maintained between certain module types to keep the entire system running safely and effectively.
This diagram illustrates the following:
- Device drivers for things like the INS, LIDAR, and other sensors are the initial sources of input to the system, but they also provide input to programs in the middle of the data flow pipeline.
- Aggregation programs such as sensor fusion perform obstacle detection calculations and feed output to a data queue.
- Lower level path planners use obstacle data as well as raw sensor data to determine the next course of action.
- A high level path planner uses the output from local path planners to form a cohesive mission plan.
- Steering and control programs then take orders from the high level path planner and control signals to cause the vehicle to perform some action such as accelerate or turn.
[edit] Tour Navigation
- Hardware of an Autonomous Ground Vehicle
- Hardware-Software Connection
- Build and Test Cycle
- CBSystem Software Architecture & Data Flow
- Taking the plunge: Getting CBSystem
- Using CBSystem
