Skip to content

moa_controllers

Jump to bottom
Adam Keating edited this page Jun 25, 2023 · 14 revisions

moa_controllers pkg

list of all interfaces between software and hardware components

ack_to_can Node

Description

The ack_to_can node is a crucial part of a ROS2-based application that interacts with a vehicle's CAN (Controller Area Network) bus. This node is responsible for receiving Ackermann drive commands in the form of AckermannDriveStamped ROS messages and converting them into CANStamped messages, which are suitable for transmission over a CAN bus.

The Ackermann drive model is a mathematical model used for steering vehicles, and it's widely used in autonomous driving systems. Ackermann commands include values for speed, acceleration, jerk, steering angle, and steering angle velocity. These are transformed into a CAN message consisting of data bytes suitable for the vehicle's CAN bus.

Before conversion, the ack_to_can node validates the data in the incoming Ackermann messages. The values must fall within specific ranges to be considered valid. If any of the values are out of bounds or invalid, the message will not be converted, and a warning will be logged.

Inputs

Stamped Ackermann Messages

The ack_to_can node subscribes to a ROS topic named 'cmd_vel'. The messages received over this topic are of type AckermannDriveStamped, and they include the following fields:

  • speed: The vehicle's desired speed, in meters per second (m/s). Valid values range from 0 to 120 km/h (converted to m/s).
  • acceleration: The desired acceleration of the vehicle, in meters per second squared (m/s²). Valid values range from 0 to 256 m/s².
  • jerk: The desired jerk of the vehicle, in meters per second cubed (m/s³). Valid values range from 0 to 1 m/s³.
  • steering_angle: The desired steering angle, in radians. Valid values range from -45 to 45 degrees (converted to radians).
  • steering_angle_velocity: The desired steering angle velocity, in radians per second (rad/s). Valid values range from 0 to 1 rad/s.

Outputs

Stamped CAN Messages

Once an Ackermann message has been received, validated, and converted, the ack_to_can node publishes a CANStamped message on a ROS topic named 'pub_raw_can'.

The CANStamped message includes the following fields:

  • id: The identifier of the CAN message. For now, it's set to a static value of 25, but future versions may support dynamic values between 0 and 20, corresponding to different vehicle systems such as the accumulator, inverter, or brake sensor.
  • data: The CAN data bytes, derived from the original Ackermann message. The bytes correspond to the following values:
    • Byte 0: Speed
    • Byte 1: Acceleration
    • Byte 2: Jerk
    • Bytes 3-4: Steering angle
    • Byte 5: Steering angle velocity
    • Bytes 6-7: Null (reserved for future use)

Output CAN Message Format

Byte 0: Speed

This byte represents the speed of the vehicle. It's encoded as an unsigned integer (uint8) in the range of 0 to 255, representing a speed range of 0 to 120 km/h (converted to m/s).

To decode this byte, interpret it as an unsigned 8-bit integer and scale it to the original speed range. The formula for decoding the speed would look like this:

speed_m_per_s = speed_byte * (120 / 3.6) / 255

Byte 1: Acceleration

This byte represents the acceleration of the vehicle. Similar to the speed, it's encoded as a uint8, but the valid range is from 0 to 255, representing an acceleration range of 0 to 255 m/s².

To decode this byte, interpret it as an unsigned 8-bit integer. The value corresponds directly to the acceleration in m/s².

acceleration_m_per_s2 = acceleration_byte

Byte 2: Jerk

The jerk is represented by a single byte, encoded as a uint8. It's scaled by a factor of 100 for precision before being encoded, so the range of values is from 0 to 100, representing a jerk range of 0 to 1 m/s³.

To decode this byte, interpret it as an unsigned 8-bit integer and then divide it by 100 to get the jerk in m/s³.

jerk_m_per_s3 = jerk_byte / 100

Bytes 3-4: Steering Angle

The steering angle is represented by two bytes, encoded as a 2-byte float (np.float16), and then converted to a 2-byte representation for transmission. This allows for greater precision in the steering angle values. The valid range for the steering angle is from -45 to 45 degrees, which is converted to radians before being encoded.

To decode these bytes, combine them to form a 16-bit value, interpret it as a float16, and then convert it from radians to degrees if necessary.

steering_angle_rad = np.frombuffer(bytearray([steering_angle_byte1, steering_angle_byte2]), dtype=np.float16)[0]

Byte 5: Steering Angle Velocity

The steering angle velocity is represented by a single byte, encoded as a uint8. Like the jerk, it's scaled by a factor of 100 before being encoded, so the range of values is from 0 to 100, representing a steering angle velocity range of 0 to 1 rad/s.

To decode this byte, interpret it as an unsigned 8-bit integer and then divide it by 100 to get the steering angle velocity in rad/s.

steering_angle_velocity_rad_per_s = steering_angle_velocity_byte / 100

Bytes 6-7: Null

These two bytes are reserved for future use and currently hold a null value. When decoding, they can be ignored or used as placeholders for future data fields.

Launching

The ack_to_can node can be launched either from a launch file or directly from the terminal.

Launch File Code

The node can be included in a ROS2 launch file with the following code:

launch_ros.actions.Node(
    package='moa_controllers',
    executable='ack_to_can_node',
    name='ack_to_can_node')

Terminal Command

Alternatively, you can launch the node directly from the terminal with the following command:

ros2 run moa_controllers ack_to_can_node

as_status node

Description

This node takes various hardware states and mission states to determine the state of the autonomous system. It follows the logic outlined in Figure 17 from section T14 of the FSG Rulebook.

Inputs

Stamped Ackermann Messages

These messages are received by the as_status node on the moa/curr_vel topic. The AckermannDriveStamped message type contains the following information used by the node:

  • speed: The vehicle's desired speed, in meters per second (m/s). Valid values range from 0 to 120 km/h (converted to m/s).
  • acceleration: The desired acceleration of the vehicle, in meters per second squared (m/s²). Valid values range from 0 to 256 m/s².

The as_status node checks these fields are both 0.0 to determine if the car is stationary. If car is stationary the car_stopped variable is 1 and vice versa if not stationary.

Stamped Hardware State message

This is a custom message in the moa_msgs package. The as_status node receives messages of the HardwareStatesStamped type via the moa/hardware_state topic. The HardwareStatesStamped message contains the following fields:

  • ebs_active: A boolean value signifying whether the EBS is active or not. Valid value is 0 or 1.
  • ts_active: A boolean value signifying whether the TS is active or not. Valid value is 0 or 1.
  • in_gear: A boolean value signifying whether the car is in gear or not. Valid value is 0 or 1.
  • master_switch_on: A boolean value signifying whether the ASMS is active or not. Valid value is 0 or 1.
  • asb_ready: A boolean value signifying whether the ASB is active or not. Valid value is 0 or 1.
  • brakes_engaged: A boolean value signifying whether the brakes are engaged or not. Valid value is 0 or 1.

Abbreviations:

  • EBS: Emergency Brake System
  • TS: Tractive System. Every part that is electrically connected to the motor(s) and TS accumulators.
  • ASMS: Autonomous System Master Switch
  • ASB: Autonomous System Brake

Stamped Mission State message

This is a custom message in the moa_msgs package. The as_status node receives messages of the MissionStatesStamped type via the mission_status topic. The MissionStatesStamped message contains the following fields:

  • mission_selected: A boolean value signifying whether a mission has been selected. Valid value is 0 or 1.
  • mission_finished: A boolean value signifying whether the the active mission is finished. Valid value is 0 or 1.

Outputs

AS Status code

After each update cycle is performed, the as_status node publishes the determined UInt8 AS status code to the as_status topic. Below are the possible states that the AS can be in. Please refer to Figure 17 from section T14 of the FSG Rulebook for the logic diagram.

State 0 : AS finished

For this state to occur the ebs has to be active, the car must be stationary and the mission has to be finished.

State 1 : AS emergency

The electronic brake system is active but either the car is still moving or the mission isn't finished or both.

State 2 : AS ready

This state indicates that the electronic brake system is not active, but all the mentioned conditions are met, including the mission selection, austonomous system master switch activation, autonomous braking system, tractive system activation, and the brakes are engaged.

State 3 : AS driving

This state indicates that the electronic brake system is not active, but all the mentioned conditions are met, including the mission selection, austonomous system master switch activation, autonomous braking system, tractive system activation, the car is in gear, and the brakes are engaged.

State 4 : AS off

EBS is off and either some or none of the following are inactive, mission selection, austonomous system master switch activation, autonomous braking system, tractive system activation. Or the aforementioned are active and the brakes are not engaged.

Launching

Launch file code

The node can be launched in a ROS2 launch file by adding the following code to the LaunchDescription object:

launch_ros.actions.Node(
    package='moa_controllers',
    executable='as_status_node',
    name='as_status_node')

Terminal command

Alternatively, you can launch the node directly from the terminal with the following command:

ros2 run moa_controllers as_status_node can_id=300

NB: can_id argument is optional and default value of 300 can be changed

Clone this wiki locally