@@ -6,7 +6,7 @@ Core software modules running on the Apollo 2.0 powered autonomous vehicle inclu
* Routing: the routing module is to tell the autonomous vehicle how to reach its destination via a serie of lanes or roads
* Planning: the planning module plans the spatio-temporal trajectory for the autonomous vehicle to take
* Control: the control module executes the planned spatio-temporal trajectory by generating control commands such as throttle, brake and steering
* CanBus: the interface where control commands are passed to the vehicle hardware. It is also where chasiss information gets passed through to the software system
* Canbus: the interface where control commands are passed to the vehicle hardware. It is also where chasiss information gets passed through to the software system
* HD-Map: this module is more like a library. Instead of publishing/subscribing messages, it is frequently used as a query fashion engine to provide add-hoc structured information regarding the roads
* Localization: the localization module leverages various information sources such as GPS, Lidar and IMU to estimate where the autonomous vehicle is located.
...
...
@@ -17,23 +17,21 @@ Every module is running as a separate baidu CarOS based ROS node. Each module no
## Perception
Obviously perception strictly depends on the raw sensor data such as Lidar point cloud data and camera data. However, besides these raw sensor data inputs, traffic light detection also needs to depend on the localization data as well as the HD-Map. Since real-time ad-hoc fashioned traffic light detection is computationally infeasible, the traffic light detection will need localization to determine when and where to start detecting traffic lights through the camera captured pictures.
**Perception seems to be so different from other modules like prediction, routing , planning, control, canbus. Hard to describe its data interfaces. Maybe better to be a little blurring here.**
## Prediction
Prediction module “predicts” the future motion trajectories for all the perceived obstacles. And the output prediction message also wrapps the perception information. Prediction subscribes two both localization and perception obstacle messages as shown below.
Prediction module predicts the future motion trajectories for all the perceived obstacles. And the output prediction message also wraps the perception information. Prediction subscribes both localization and perception obstacle messages as shown below.
When localization update is received, the prediction module updates its internal status. And the actual prediction is triggred when perception sends out its published perception obstacle message.
When localization update is received, the prediction module updates its internal status. And the actual prediction is trigged when perception sends out its published perception obstacle message.
## Localization
The routing module fuses various information to locate where the autonomous vehicle is at. There are two types of localization modes. The first localization method is an RTK based one, with a timer based callback function “OnTimer”.
The localization module fuses various information to locate where the autonomous vehicle is at. There are two types of localization modes. The first localization method is an RTK based one, with a timer based callback function “OnTimer”.
The other localization method is the “Multiple Sensor Fusion” (MSF) method, where a bunch of event triggered callback functions are registered, such as:
## Routing
The routing module also needs to know where the autnomous vehicle location is, as well as the destination, in order to compute the passage lanes and roads towards the destination. The important data interface is an event trigged function called “OnRoutingRequest”, in which “RoutingResponse” will be computed and published.
The routing module also needs to know where the autonomous vehicle location is, as well as the destination, in order to compute the passage lanes and roads towards the destination. The important data interface is an event trigged function called “OnRoutingRequest”, in which “RoutingResponse” will be computed and published.
## Planning
...
...
@@ -44,17 +42,17 @@ The data dependency such as chassis, localization, traffic light, prediction, et
## Control
Control takes the planned trajectory as input, and generates the control command to pass to CanBus. It has main data interfaces like: OnPad, OnMonitor, OnTimer, localization and CanBus messages.
Control takes the planned trajectory as input, and generates the control command to pass to Canbus. It has main data interfaces like: OnPad, OnMonitor, OnTimer, localization and Canbus messages.
The “OnPad” and “OnMonitor” are control interaction with the PAD based human interface and simulations. The main data interface is the “OnTimer” interface which periodically produces the actual control commands.
## CanBus
The CanBus has two data interfaces as shown below:
## Canbus
The Canbus has two data interfaces as shown below:
The first data interface is a timer based publisher with callback function “OnTimer”. This data interface will periodically publish the chassis information as well as chassis details if enabled.
The second data interface is an event based published with callback function “OnControlCommand”, which is triggered when the CanBus module receives control commands.
The second data interface is an event based published with callback function “OnControlCommand”, which is triggered when the Canbus module receives control commands.
