uXRCE-DDS Leak-through into Position and RTL Flight modes

Hello,

I recently started using XRCE-DDS as a bridge into a ROS2 companion computer. While in offboard mode, the system functions as intended - I send commands through the attitude + thrust control message, the vehicle responds accordingly. But I have found some worrying behaviour - when I RTL from my controller, or go into position mode, the system STILL attempts to follow the commands the offboard mode is publishing, and so it often jitters between my controller’s command and the offboard commands. We have stopped sending offboard commands when not in offboard, but we are very concrned about this behaviour, as it caused a nearly half mile fly-away before we regained control (through stabilized, which seems unaffected).

Here is our hardware/version setup:

Jetson Orin nano (ROS2 Humble), connected through UART to a Ark FPV FC, using e-prosimas xrce-dds agent, v.2.4.3.

The FC runs px4 1.16.0.

This is perhaps unrelated, but sometimes when I RTL from crazy manuvers that our offboard sends to our drone, the drone disarms in midair and crashes.

Has anyone else experienced this issue with uXRCE? We never had problems on MAVSDK, but we are finding reliablility dropping across the board with our change.

Same issue as reported here [Bug] Offboard control setpoints affect vehicle when offboard control is not enabled · Issue #25273 · PX4/PX4-Autopilot · GitHub

And possibly related to [Bug] Setpoint inconsitencies on switching from and to external flightmodes · Issue #26006 · PX4/PX4-Autopilot · GitHub

Hi @Marcsprk43 ,

please see my reply in GitHub: [Bug] Offboard control setpoints affect vehicle when offboard control is not enabled · Issue #25273 · PX4/PX4-Autopilot · GitHub

All you saw is expected and it is part of the tradeoff you have to pay for lower lever access to PX4 internal components: lower latency and more control of the vehicles are the PROS, more responsibility in doing it right is the CONS.

you were sending unwanted trajectory setpoints which were overlapping with your rc position setpoints and the navigator RTL setpoints. These setpoints, all overlapping one to the other, ended up in the position controller logic. Switching to stabilised saved the day as that mode disables the position controller. The main setpoint for stabilized mode is vehicle_attitude_setpoint which is used by the attitude controller. That setpoint was not being contaminated by your ROS 2 code and therefore you regained control of the vehicle.

@dakejahl I don’t think it relates to the second link you shared. But if it does, then it is about the transition phases when one internal setpoint publisher stops and one external one starts (and vice versa)

1 Like

I am also fairly certain this issue is not related to the second issue, as only goto set

points but no trajectory set points are sent there.