Demo 0a structure
The Global Planner (lanelet2_global_planner_node) can't read minds-- tell it where you want to go by publishing a geometry_msgs/PoseStamped message to /planning/goal_pose.
See Demo 0 usage for details.
The lanelet2_global_planner_node subscribes to /planning/goal_pose (goal location) and /vehicle/vehicle_kinematic_state (current location).
When a new goal pose is received, it requests our stored HD map via the Lanelet2 map provider service
(had_maps/lanelet2_map_provider_node).
Using the two provided points along with the map, the Global Planner publishes a route (autoware_auto_msgs/Route) to /planning/global_path.
In autonomous cars, the behavior planner refines a route into a detailed path, adding information like speed along the way.
In Autoware.Auto, the Behavior Planner manages two separate planners, each of which produces their own paths: the Lane Planner and Parking Planner.
Normally, the Autoware.Auto's Behavior Planner would break the global path it receives into parking and lane sections. It sends an action request to the relevant planner to process that section (pulling out of a parking space would be done with an action request from the Behavior Planner to the Lane Planner, for example).
Since our demonstation doesn't include parking, we only really interact with the Lane Planner.
The Behavior Planner creates a detailed path that it publishes as a autoware_auto_msgs/Trajectory, which is a sequence of up to 100 TrajectoryPoints that each hold a position, velocity, and time from start (the time that the car should reach that specific point).
Oddly, the Behavior Planner also subscribes to the /vehicle/state_report and ./vehicle_kinematic_state topics. It also publishes commands to ./state_command. This mostly has to do with requesting gear changes (backing into a parking space, for example) and getting the car's current location.
It's possible that it connects to these topics for other reasons...
The lgsvl_interface_node translates between the SVL simulator and Autoware, but it does not actually publish and receive data from SVL (the Bridge does that).
For example, Autoware treats negative angles as clockwise while SVL treats them as counterclockwise. Without the Interface, there would be chaos.
To clarify:
SVL <--> Bridge <--> Interface node <--> Autoware
This is how you control:
- Driving mode (autonomous or manual)
- Headlights
- Blinkers
- Gear
- Hand brake
- Wipers
- Horn
See autoware_auto_msgs/VehicleStateCommand
This is identical to state_command, but it instead publishes the current state of the vehicle. Useful for checking if you're in autonomous driving mode, for example.
See autoware_auto_msgs/VehicleStateReport
The vehicle's speed (from spedometer), steering angle (I think?), and position (from simulated GPS, I think).
Also includes a standard ROS Transform-- possibly from /base_link->/odom.
See autoware_auto_msgs/VehicleKinematicState
Autoware calls its maps with lane information "HAD maps" (Highly Autonomous Driving). You'll also see them called "HD" or "semantic" maps.
The Map Provider Service (called lanelet2_map_provider_node) provides our stored Lanelet2 map upon request (from the global planner).
The separate visualizer node simply provides the map as an image that tools like Rviz can display.
Whew, this one's a lot to cover. I'll try to add more later, maybe.
The NDT Localizer compares the current Lidar data (from lidars/points_fused_downsampled) to the known map (./ndt_map) to find its bearings. Once it's calculated a location on the map, it publishes this as a transform from the map's origin to the car.
In order to get started, it needs an approximate initial location. This is normally provided by the GPS, but here it's manually supplied by the user at the start of the demo.
See the Autoware.Auto localization docs.
A URDF file includes useful information about the physical properties of a robot. This node publishes the vehicle's URDF file so that all nodes can access it when needed.
For example, the URDF includes a vehicle's center of mass. This is needed for a transform between /base_link (the midpoint of the rear axle) and nav_base (the center of mass).
It also includes a 3D model of the car, which is useful for visualization tools like Rviz.
"Transforms" are just values that we can add and subtract from a frame of reference to arrive at a new frame of reference.
We divide these into static transforms (say, the center of the Earth to the center of Dallas, TX-- a constant value) and moving transforms (the distance from the vehicle to a parking space, as the vehicle drives towards it).
Just about every part of the autonomous driving system uses transforms regularly. Depicting this would require lots of messy arrows, so I added an "*" instead.
It all starts with the raw data, published to lidar_rear/points_raw and ldar_front/points_raw by the SVL Bridge.
The raw points are centered around the Lidar sensors, but we want the point coordinates to be based on the center of the vehicle. We also want to get rid of useless data-- flat ground, for example. This is what the point_cloud_filter_transform_nodes do.
The filtered points are combined into a single pointcloud by the Point Cloud Fusion node, then downsampled (simplified).
The finished pointcloud is published to lidars/points_fused_downsampled.
Rviz is ROS's official visualization tool. It can display maps, sensor data, and other information useful for debugging.
Demo 0a stops with the calculated trajectory.
Future demos will feed this trajectory into the MPC controller to generate steering commands, then publish these commands to SVL.