Autoware.Auto
|
|
A vehicle interface interfaces a general autonomous driving software stack with a specific vehicle. This includes the transmission of commands to the vehicle hardware, and the receipt of reports or sensor data from the vehicle platform.
Until a standard interface is defined, each different type of vehicle will need slightly different vehicle interfaces.
This section defines general use cases and settings a generic vehicle interface might encounter.
A vehicle interface should broadly do the following:
For the purpose of actuating the vehicle and receiving the information needed to appropriately actuate the vehicle safely, the vehicle interface should replace a human driver.
Other aspects such as prediction, planning, routing are out of scope.
Actuation generally refers to controlling the steering, throttle, braking, gears, and indicators of the vehicle.
Receiving information generally refers to information found on the driver's dashboard, such as vehicle velocity, fuel information, and the current state of indicators, gears, and so on.
Certain vehicle platforms may have a more granular set of sensors that are not directly exposed to a human driver, such as individual wheel odometry, or front facing radars. The signals from these sensors should additionally be exposed to the wider autonomous driving system stack.
The vehicle interface should prevent actions that are known to be unsafe or damaging to a vehicle.
This can include rapid actuation of the brake, throttle, or steering, and shifting gears to park when the vehicle has non-negligible velocity.
The vehicle interface should provide interfaces with varying levels of granularity. A low granularity interface should be provided to abstract a significant amount of control and edge cases from the user. A high granularity interface should be provided to expose the full functionality of the hardware-software interface to the software stack.
While "easy development" is ill-defined, an approximation would be to minimize the number of degrees of input freedom.
More concretely, development can be facilitated by supporting the following use cases:
In addition, depending on the amount of logic present in the vehicle interface, it may be useful for the interface to be compatible with simulators, so that the interface logic can be appropriately tested and exercised.
Finally, making it possible to support multiple hardware-software communication mechanisms would also simplify development.
If the vehicle interface is the only arbiter of control to the vehicle platform, then the vehicle interface should preferentially permit physical actuation of the vehicle. In the case of development, this should always be the case. In a production vehicle, it may be appropriate to never permit physical intervention.
Many vehicle platforms may allow this implicitly by how the drive-by-wire interface operates.
The use cases above can be decomposed into requirements:
To satisfy the requirements of the vehicle interface, the following components (which roughly correspond to classes in object-oriented programming) are defined:
RawControlCommand
VehicleControlCommand
HighLevelControlCommand
VehicleStateCommand
VehicleOdometry
VehicleStateReport
This components are described in detail further below. All components can be combined in a manner specified by the below UML diagram:
A fundamental requirement of the vehicle interface is to manipulate the kinematic state of the vehicle. As such, an interface which defines the requested kinematic state is required.
Multiple message types are defined for vehicle control. This is because no one message type can appropriately cover the desired use cases (of easy development, preventing unsafe actions), while remaining as concrete and unambiguous as possible.
For each message type, both longitudinal and lateral control actions are combined into a single type, and predefined message definitions are not used. The purpose of the former is to remove the need for time synchronization or message alignment within the vehicle interface. The latter is imposed in order to minimize the size of the communication messages and remove ambiguity.
In all cases, these messages are intended to be published at a high frequency, approximately 100 Hz.
This message type is defined as follows:
This type is intended to be used when direct control of the vehicle hardware is required. As such, no assumptions about units are made. It is the responsibility of the system integrator to ensure that the values used are appropriate for the vehicle platform.
This message type is defined as follows:
The message semantics represent instantaneous control of the vehicle (i.e. hands on steering wheel and feet on pedals). This type is intended to be used as a middle ground for representational power, exposing direct wheel angles, but abstracting away some braking/throttling details.
A vehicle interface using this type as the primary input is expected to include at a minimum the safety state machine.
The rear wheel angle is kept for possible future extensions to Quadrasteer or rear-steering platforms.
This message type is defined as follows:
This type is intended to be used as an interface when only simple control is required, and thus abstracts away more direct control of the vehicle.
A vehicle interface using this type as the primary input is expected to include at a minimum the safety state machine and the controller.
Additional interfaces types are defined for the vehicle interface.
This message type is defined as follows:
This message represents lower frequency control of all other aspects of the vehicle related to driving.
This message is intended to be published at some lower, unspecified rate, such as 1-10 Hz.
This message type is defined as follows:
This message represents common sensing information from the vehicle platform needed to estimate the vehicle's kinematic state.
This data is expected to be high frequency, and can be treated as "best effort".
This message type is defined as follows:
This message represents the non-control related state of the vehicle platform.
It is intended to be used to update state machines in the vehicle interface and behavior planners.
This data is expected to be moderate in frequency, and can be treated as "best effort".
Each vehicle platform has some communication mechanism by which commands can be transmitted, and reports received.
Most vehicle platforms use CAN. Supporting simulators may necessitate the use of custom interfaces, or other communication mechanisms, such as ROS 1/2 publishers, or websockets.
Each vehicle platform may have different control characteristics, for example a vehicle-specific brake or throttle table.
The purpose of this component is to convert general, platform agnostic commands into vehicle-specific data, and to transmit these commands to the vehicle platform itself.
Similarly, this component must receive reports from the platform, and translate this information to a vehicle-agnostic message.
As the communication mechanism may vary from platform to platform, this component should encapsulate whichever communication mechanism the platform makes use of.
The safety state machine maintains an internal state that minimally represents the vehicle platform. This state machine is then used to translate a potentially incompatible set of commands to a consistent set of commands.
Concretely, the state of this safety state machine should be approximately what is represented in the VehicleStateReport
type (it may be a subset or superset).
An example of some of the combinations of commands that this state machine should reject are requirements 3.2, 3.3, and 3.4.
The vehicle interface is a higher level component which provides an interaction point with the larger ADAS stack via ROS 2's IPC mechanisms. All other components listed here are composed into this component.
A generic low-pass filter, or any equivalent filter (e.g. Butterworth, Chebyshev, etc.) should be optionally available to remove high frequency noise from the control signals.
A controller should be optionally available in case the developer wishes to control the vehicle via velocity rather than acceleration. This can be any simple reference-tracking controller, such as a PID controller.