The technical ROS ecosystems in a nutshell

The Robotic Operating System (ROS) community describes its robots via a digital twin meta model called “Unified Robotic Description Format” (URDF). This format distinguish between links and joins. Links are components of a robot who are connected via joins. Joins brand in the movements.

Robot state (aka digital twin)

Mapped to a vehicle it has at minimum a chassis frame “link” (aka frame), with 4 attached wheel “links” (front-left, front-right, rear-left, rear-right).

Common joint and link types are

1. Continuous Joint: This joint type is similar to a revolute joint but allows continuous rotation with no defined upper or lower limits. It is often used to model joints that can rotate indefinitely, such as a wheel
2. Prismatic Joint: A prismatic joint enables linear movement along a single axis. It can be visualized as a sliding joint, similar to the motion of a drawer or piston.
3. Base Link: The base link is the starting point of the robot’s kinematic chain. It serves as the reference frame for the entire robot and provides the foundation for all other links and joints.
4. Collision Link: A collision link is a simplified representation of a physical link used for collision detection purposes. It helps to ensure that the robot does not collide with obstacles or itself during motion planning and execution.

Complementary formats in ROS are

1. Semantic Description Format (SDF), which includes the description of the robots world of the Gazebo Simulator and
2. Semantic Robot Description Format (SRDF), which in addition extends the URDF format of/for the MoveIt motion framework needs.

More details can be added flexible e.g., introduces axis. Some nice GitHub projects showing URDF definition for vehicle:

Project	Github Link	URDF file
AutoCarROS2	https://github.com/winstxnhdw/AutoCarROS2	https://github.com/winstxnhdw/AutoCarROS2/blob/master/autocar_description/urdf/autocar.xacro
CarSim	https://github.com/CihatAltiparmak/car_sim	https://github.com/CihatAltiparmak/car_sim/blob/main/car_sim_description/urdf/car_sim.urdf.xacro
Car Gazebo	https://github.com/danieljeswin/car_gazebo	https://github.com/danieljeswin/car_gazebo/blob/master/car_description/urdf/simple_car_description.urdf

State Management

Besides the robot model, each robot has a robot state. Here the ROS(2) middleware comes into the play. Core of ROS2 middleware is the communication middleware DDS, as specified by the OpenGroup. Different implementations do exist, which are not detailed here.

DDS is a data centric communication middleware and follows the publish-subscribe pattern incl. remote procedure calls (aka ROS services or actions, compare here). In any case, we do have topics which are addressed via messages.

A brief explanation of each and the differences between them:

1. ROS2 Messages: Messages are used for one-way communication between nodes. They are the most basic form of communication in ROS 2 and are typically used for publishing and subscribing to data. Messages define the data structure and format of the information being sent between nodes. Publishers send messages on specific topics, while subscribers receive and process those messages.
2. ROS2 Services: Services provide a request-response mechanism between nodes. They allow nodes to make a request for some operation or data and receive a response in return. Services use a pair of messages, one for the request and one for the response. The requesting node sends a request message to the service server, which processes the request and sends a response back to the requesting node.
3. ROS2 Actions: Actions are similar to services but provide a more advanced form of asynchronous communication. Actions are typically used for long-running tasks that require feedback and progress updates. An action consists of three parts: a goal message, a feedback message, and a result message. The requesting node sends a goal message to the action server, which starts the action execution. The server then sends periodic feedback messages to the requester, providing updates on the progress of the action. Finally, when the action is completed, the server sends a result message back to the requester.

Changing the robot state

Changing the state of a robot (component) usually happens via commands. A “command” refers to a specific message class, that contains instructions or directives for a robot or system to perform a specific action or behavior.

Exemplary topics for a robot are as follows. Multiple robots usually distinguished via DDS (topic) namespaces.

1. Topic “/joint_states”, typically includes the position, velocity, and effort (torque) values for each joint.
2. Topic “/tf” or “/tf2” , for the ROS(2) transformation messages as the transform between different links of a robot.
3. Topic “/robot_state”, to publish the complete state of the whole robot including all joins.

Note: ROS tf2 (Transform Library) is a library in ROS (Robot Operating System) that provides support for working with coordinate transforms in a distributed system. It allows for tracking and maintaining the relationship between different coordinate frames in a robotic system.

Controller

The important software component are controller which are from DDS perspective are simply subscriber nodes, controlling the behavior of a robot. ROS(2) provides the “ros2_control” framework for developing and managing controllers. It introduces the concept of “hardware interfaces” and “controller interfaces”:

1. Hardware interfaces define the abstraction for interacting with the physical robot hardware, such as reading sensor data and sending actuator commands.
2. Controller interfaces define the interfaces and behaviors expected from controllers. Multiple controller are managed via a so called “Controller Manager”.

Behavior Management

The ROS(2) framework “ros2_control” introduces a so called “Control Manager” to manage the interdependency between multiple controller, in an expected control loop. But the ROS(2) ecosystem offers a brought variety of alternative frameworks and approaches e.g.

1. The behaviortree_cpp_v3 package is a C++ library for behavior tree implementation in ROS 2. It provides a flexible and modular framework for defining and executing behavior trees. This package supports ROS 2 features and can be integrated with other ROS 2 nodes and components.
2. The nav2_behavior_tree package is part of the Navigation2 stack in ROS 2. It provides behavior tree implementations specifically for navigation-related tasks, such as path planning, obstacle avoidance, and goal reaching. This package is designed to work with the Navigation2 framework and can be customized to fit specific navigation requirements.

Note: ROS Nav2 is a navigation framework for autonomous mobile robots built on top of ROS (Robot Operating System) 2. It provides a modular and flexible architecture for implementing navigation capabilities in robots, including map-based localization, path planning, obstacle avoidance, and control.

Navigation

The “controller manager” is often called a local planner. From a bird view the planning starts in the environment.

1. It starts with the usual routing e.g, via the Dijkstra algorithm,
2. global planner taking constraints such as traffic flow management
3. local planner including the motion management and all related controls e.g., for dynamics.

Motion Management

Having the sensing and actuating of robots in control, it is important to step into the motion planning. MoveIt(2) provides algorithms and tools for generating smooth and collision-free trajectories for robot arms or manipulators.

Vehicle specifics

Autoware offers a framework for autonomous driving vehicle, including

1. perception,
2. localization,
3. planning
   • path planning
   • motion planning
4. control
   • dynamic control
   • motion control
5. up to specific hardware system integration for lidar, radar, etc.

In comparison to MoveIt(2) the path planning focus is on smooth and collision-free road paths for the vehicle to follow.

The specific motion planning behavior (strategies) focuses on e.g., lane keeping, lane change.

For the specific behavior and necessary dynamic control Autoware supports trajectory generation, which involves generating a sequence of vehicle states (positions, velocities, and accelerations) that adhere to the planned path, PID (Proportional-Integral-Derivative) controllers or model predictive controllers and handling characteristics based on its dynamics model e.g., capturing the vehicle’s physical properties, such as mass, inertia, tire characteristics, and suspension parameters and sensor feedback.

This encloses aspects such as

• adaptive cruise control (ACC), which enables the vehicle to maintain a safe distance from the vehicle ahead and adjust its speed accordingly.
• antilock braking system (ABS), which prevents wheel lock-up during braking by modulating brake pressure to individual wheels. This feature helps maintain steering control and reduce stopping distances.
• electronic stability control (ESC), that monitors the vehicle behavior and apply selective braking to individual wheels or adjust engine torque to counteract oversteer or understeer conditions.
• traction control system (TCS), which prevents excessive wheel spin during acceleration in low-traction conditions. TCS systems reduce engine power or apply braking to the spinning wheels to maximize traction and maintain vehicle stability.
• electric power steering (EPS), which provide assistance to the driver based on vehicle speed and steering inputs, making steering efforts easier while maintaining stability and road feel.

The specific motion control includes motion control algorithms that translate the desired trajectory into low-level control commands for the vehicle’s actuators.

Note: Autoware (https://github.com/autowarefoundation) is a semi open source project. It distinguishes between a fluent “universe” and a “core”. The “core” is shared in a binary version. The “universe” is open to everyone. The former version of Autoware, also called Autoware.AI, is (partially) still shared as source code.

Generally speaking the high level order is:

1. Motion Planning: Motion planning is the process of generating a high-level plan or trajectory for a robot to move from its current state to a desired goal while avoiding obstacles and adhering to any specified constraints. This is typically done based on a representation of the robot’s environment and the desired goal. The motion planning algorithm considers factors such as path optimality, collision avoidance, and goal reaching. The output of motion planning is a path or trajectory that guides the robot towards the goal.
2. Dynamic Control: Dynamic control focuses on optimizing the robot’s motion and behavior while taking into account the dynamic properties and constraints of the robot, such as its mass, inertia, and actuator limits. It involves designing control strategies that can adapt to changing conditions and disturbances in real-time. Dynamic control algorithms aim to achieve desired performance criteria, such as stability, accuracy, and responsiveness, while considering the physical limitations of the robot.
3. Motion Control: Motion control deals with the low-level execution of the planned trajectory or motion commands to drive the actuators of the robot, such as the motors or joints, to achieve the desired motion. It involves translating the higher-level motion commands into specific control signals that control the robot’s actuators. Motion control algorithms may include PID controllers, odometer (position and direction) estimate, trajectory tracking controllers, or other control techniques to accurately track the desired trajectory and regulate the robot’s motion.

Some general

a. Topics (sensing), also compare https://autowarefoundation.github.io/autoware-documentation/main/contributing/coding-guidelines/ros-nodes/message-guidelines/

1. /vehicle/status: This topic provides information about the status of the vehicle, such as its speed, acceleration, position, and orientation.
2. /vehicle/velocity: It publishes the current velocity of the vehicle, typically in meters per second (m/s).
3. /vehicle/steering: This topic conveys the steering angle or steering command for controlling the vehicle’s direction.
4. /vehicle/brake: It publishes the brake command or brake pressure for controlling the vehicle’s deceleration or stopping.
5. /vehicle/throttle: This topic communicates the throttle command or throttle position for controlling the vehicle’s acceleration.
6. /vehicle/gear: It provides the current gear information, indicating whether the vehicle is in neutral, park, drive, reverse, etc.
7. /vehicle/imu: This topic publishes the data from the Inertial Measurement Unit (IMU) of the vehicle, including the accelerometer and gyroscope readings for sensing vehicle motion.
8. /vehicle/gps/fix: It publishes the GPS fix data, including latitude, longitude, altitude, and GPS quality information.
9. /points_raw: This topic conveys raw point cloud data captured from sensors like LiDAR, providing a 3D representation of the surrounding environment.
10. /detection/lidar_detector/objects: It publishes the detected objects from LiDAR-based object detection algorithms, including their position, size, and classification.

b. Actions (Control)

1. /planning/mission_planning: This action is used for mission planning, which involves defining high-level goals and waypoints for the autonomous vehicle. The action allows for sending mission goals and receiving feedback on the progress of the mission.
2. /planning/navigation: This action is used for navigation planning, which involves generating a trajectory or path for the vehicle to follow based on the defined mission or goal. The action allows for setting navigation goals and receiving feedback on the progress of the navigation plan.
3. /perception/lidar_detection: This action is used for LiDAR-based object detection. The action allows for sending a detection request and receiving feedback on the detected objects in the LiDAR point cloud.
4. /perception/camera_detection: This action is used for camera-based object detection. The action allows for sending a detection request and receiving feedback on the detected objects in the camera image or video stream.
5. /control/trajectory_following: This action is used for trajectory following and control. It allows for sending a trajectory or path to the vehicle controller and receiving feedback on the execution of the trajectory, such as tracking errors and control signals.

c. Commands (Actuation)

1. /vehicle/cmd_vel: This command topic is used to send velocity commands to control the vehicle’s linear and angular velocities. It typically includes fields such as linear x, linear y, and angular z velocities.
2. /vehicle/steering_cmd: This command topic is used to send steering commands to control the vehicle’s steering angle or steering rate.
3. /vehicle/brake_cmd: This command topic is used to send brake commands to control the vehicle’s braking system. It can include fields such as brake pressure or brake pedal position.
4. /vehicle/throttle_cmd: This command topic is used to send throttle commands to control the vehicle’s acceleration. It can include fields such as throttle position or desired torque.
5. /vehicle/gear_cmd: This command topic is used to send gear commands to control the vehicle’s transmission. It typically includes fields such as the desired gear state (e.g., park, drive, reverse).

d. Nodes and further details

• https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture/node-diagram/
• https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture/vehicle/
• https://autowarefoundation.github.io/autoware-documentation/main/design/autoware-architecture/control/#autoware-control-design