@patrick-n This is mostly up to the vehicle interface developer. The idea behind the generic autoware_msgs/VehicleCmd message is to provide several options for how the vehicle can be controlled and each drive-by-wire interface developer will handle the information provided in a different way. Unfortunately, there is currently no "developer guide" for compatibility of drive-by-wire systems with Autoware.ai.
Regarding the components of VehicleCmd, they are combined by the twist_gate node from several input topics:
The accel_cmd, brake_cmd, steer_cmd, gear_cmd, mode_cmd, and lamp_cmd values are populated by individual topics (named the same as the value names) which are published by upstream components. These comprise one method of vehicle control.
ctrl_cmd contains linear_acceleration, linear_velocity and steering_angle properties. This is another method of vehicle control.
twist_cmd contains a geometry_msgs/Twist message which, in turn, contains linear and angular components. This is another method of control.
Depending upon which components are enabled upstream and which options are set on them, different portions of this message will be populated. The typical methodology for how to handle this is either:
- Decide that you will only support one control method and inform your users.
- Listen to all components but create a priority order within your interface.
I'm sorry this isn't more straightforward but this is one of the tasks that the Autoware Vehicle Interface Working Group is trying to tackle. Please let me know if you have further questions.
Has the safety of this implementation been assessed?
Considering it will be a non-commercial limited use case implementation, I doubt we will assess the safety of it.