Immediate Offboard Loss Despite Receiving Messages?

Hi, my PX1 running fmu_v3_default 1.14 would immediately trigger offboard_loss failsafe after arming.
My Goal: send message to /fmu/in/trajectory_setpoint, and observe that there is pwm output on the pixhawk according to the message.

My setup:
Companion Computer: Linux VM ubuntu 20.04 running QGC and ros2, connected to pixhawk using uXRCE-DDS over serial(USB to ttl) with baudrate 921600
Pixhawk: running fmu_v3_firmware, but modified such that RC, GPS, esc, and battery pre-arm checks are disabled in HealthAndArmingChecks.hpp , GPS failsafe also disabled in failsafe.cpp. Pixhawk shows “Ready to Fly” in QGC

hardware: Pixhawk has only usb-cable attached to power itself, and connection to serial adapter on telem2. no rc, no gps, no battery, no esc. PWM output is measured by an oscilloscope.

For the ROS2 message over /fmu/in/trajectory_setpoint and /fmu/in/offboard_mode, I am using the package from the official example “GitHub - Jaeyoung-Lim/px4-offboard: Example of offboard control over microdds using python ROS 2” where the only difference that instead of connecting to a SITL pixhawk over UDP, I connected a real one over serial.

Connection is good because $ros2 topic list$ shows the topics and $ros2 topic echo$ shows both sensor readings as well as the messages published to /fmu/in/
From the mavlink console $uxrce_dds_client status$ shows good, and the RX traffic shows ~4000b/s meaning that the pixhawk is indeed receiving the messages sent from computer.

ISSUE: according to the documentation: “A stream of setpoint commands must be received by the vehicle prior to engaging the mode, and in order to remain in the mode (if the message rate falls below 2Hz the vehicle will stop).” –Offboard Mode | PX4 User Guide
my messages have a far higher frequency, but the pixhawk immediately triggers offboard loss failsafe after arming.
I am also very certain is is “offboard_loss” failsafe triggering specifically because by changing COM_OBL_RC to disarm, terminate or other options, the failsafe reaction changes accordingly. Also I forgot to mention RC_loss is set to ignore in offboard mode.
Even more wierd is the fact changing COM_OF_LOSS_T (0~60s) should supposedly set a delay before the failsafe is triggered, but no matter what I set it to, failsafe happens instantaneously after arming.

Any help would be appreciated.

Hi @Cmdr_Core ,
could you check from the nuttx console that you are indeed receiving the offboard_mode messages? Let’s try to narrow down what is causing the issue.

@Benja Thanks for the reply,
I have checked from nuttx console with $listener trajectory_setpoint$ and it shows it’s actually receiving normally. (here it’s a velocity setpoint, but I have tried pos, vel and accel to no avail)
image
image

If you restore the original firmware the issue remains?

I am getting a radio and then I will try the default firmware. The modified firmware was to bypass rc / joystick requirements. Will update this post once I tried it out.

If you want to do tests without radio and joystick, you can set COM_RC_IN_MODE to 4