ROS2-Powered SU17: A Full Control-Chain Upgrade

In the wave of continuous evolution of unmanned system technology, ROS2 is gradually becoming the mainstream choice for the next generation of robot software architecture with its distributed communication mechanism, real-time guarantee and cross-platform scalability. AMOVLAB adheres to the concept of "opening up from the bottom and verifying the whole link from simulation to actual flight". It is the first to fully migrate the Prometheus self-developed flight controller framework to the ROS2 platform. From the initial verification of basic control in the ProSim simulation environment, to now allowing SU17 to run completely in real flight.ROS2 full link control, we have completed multiple rounds of firmware changes, communication optimization and function expansion, and achieved stable flight results both indoors and outdoors.

Benefits of adapting to ROS2

Very low resource usage

The equipment has been optimized and the resource usage is extremely low. Selection, zero-copy communication, and memory management are mainly realized through DDS.

The experimental tests are as follows:
1. Node memory consumption
Test environment: Hardware: SU17 (intel 8365U, 8GB RAM) System: Ubuntu 20.04 + ROS 2 Foxy vs. ROS 1 Noetic
Test scenario: A single node publishes/subscribes sensor_msgs/Image messages at 100Hz (640x480 RGB).

2. Multi-node communication overhead Test scenario: 10 nodes communicate with each other (publish/subscribe), and the message type is geometry_msgs/Twist.

real-time advantage

The real-time advantage of ROS 2 is mainly achieved through the DDS underlying protocol, thread model optimization, deterministic scheduling and low-latency communication.

Single node end-to-end latency test:
Test environment: Hardware: SU17 (intel 8365U, 8GB RAM) System: Ubuntu 20.04 + ROS 2 Foxy (Fast DDS) vs. ROS 1 Noetic
Test scenario: Single publisher-subscriber transport std_msgs/Float64 (1 kHz frequency)

Real-time thread priority testing
Test scenario: ROS2 allows assigning real-time priorities (Linux SCHED_FIFO) to critical threads (such as control loops), while ROS 1 does not have this feature.
Test scenario: Tested with two nodes (control node \@ 1 kHz + background computational load).

QoS (Quality of Service)

Consistent with standard DDS, it supports refined control of communication reliability, delay, bandwidth, etc. to ensure the reliability and real-time Nature of key data.

QoS core strategies and quantified impact ROS 2 provides multiple QoS policy combinations. The following are the key policies and their effects:

Reliability testing in high packet loss environments
Test scenario: The network simulation packet loss rate is 20%, and 1000 std_msgs/String messages are transmitted. Compare RELIABLE vs BEST_EFFORT QoS.

lightweight protocol

Compared with the standard DDS protocol, microRTPS message headers are shorter, reducing transmission overhead. Efficient point-to-point communication: Through reliable real-time communication mechanism, rapid data exchange between devices is achieved, suitable for embedded devices (such as flight controller).

microRTPS message header

1. microRTPS message header size:

• Only 4~8 bytes (redundant fields are reduced to only necessary identifiers and serial numbers).

1. PX4 measured data:

• For small messages (such as sensor data), the message header proportion of microRTPS is reduced from 30\%~50\% of DDS to 10\%~15\%.

• Example: Transmitting a 16-byte vehicle_odometry message: Standard DDS: Total size = 16 (payload) + 28 (header) = 44 bytes.

• microRTPS: total size = 16 (payload) + 4 (header) = 20 bytes (Transmission efficiency increased by 54%）。

3. Latency test (PX4 SITL + RTPS proxy)

• Test environment: SU17: buntu 20.04, PX4 v1.13, UDP transmission, local loopback.

• Test results: Standard DDS: average delay 1.2~2.5 ms. microRTPS: average latency 0.3~0.8 ms.

4. Throughput test

• Scenario: Continuously send sensor_combined messages at 100Hz (payload 64 bytes).

• Standard DDS: Maximum stable throughput approximately 800 Hz (CPU usage 15%).

• microRTPS: Maximum stable throughput 2000 Hz (CPU usage 8\%).

Resource usage comparison

In addition, ROS2 has other benefits compared to ROS1, such as:

Multi-platform support (Cross-Platform)
Distributed Systems
Security
Lifecycle management (Lifecycle)
Dynamic parameter configuration (Dynamic Reconfiguration)
Tools and Ecosystem

System architecture

SU17(PX4) ↔ microRTPS ↔ ROS2 ↔ Prometheus

• microRTP is a communication tool in the PX4 ecosystem used to implement the RTPS (Real-TimePublish-Subscribe) protocol.

• It is a bridge between PX4 and ground control stations or other systems that support RTPS (such as ROS 2).

• microRTPS uses Fast DDS (formerly Fast RTPS) as its underlying implementation.

From simulation to real machine

In ROS2 from ProSim simulation In the process of migrating the environment to real aircraft, we have flight controller firmware, parameter configuration as well as Intermediate communication mechanism A lot of adaptation work was carried out and the ROS2 control communication link was gradually opened. In the indoor flight scenario, the localization module (BSA_SLAM) equipped on SU17 directly forwards the localization data to the microRTPS interface through the program, and then receives it by the PX4 flight controller system, achieving efficient closed-loop control without additional middleware. This method not only simplifies the system architecture, but also significantly reduces delay and coupling, and improves the real-time performance and stability of the overall flight controller.
Simulation demonstration:

Real machine demonstration:

In addition to the controls demonstrated above, other control interfaces are also fully adapted. The complete control interface is as follows:

• 1. Inertial frame-position control (XYZ_POS)

• 2. Inertial system-fixed height speed control (XY_VEL_Z_POS)

• 3. Inertial frame-speed control (XYZ_VEL)

• 4. Machine system-position control (XYZ_POS_BODY)

• 5. Machine system-speed control (XYZ_VEL_BODY)

• 6. Machine system-fixed height and speed control (XY_VEL_Z_POS_BODY)

• 7. Trajectory control (TRAJETCORY)

• 8. Attitude control (XYZ_ATT)

• 9. Longitude and latitude height control (LAT_LON_ALT)