VTOL Descent and Crash in Mission Mode after Attempt to Switching into Offboard Mode

Hello, all!

This is a shorter (and Gazebo Classic simulation) version of Unexpected and dangerous behaviours after going in & out of Offboard mode.

We are trying to reproduce and investigate the issue of Flight #1 in Unexpected and dangerous behaviours after going in & out of Offboard mode. Basically, we are testing with ROS2 Offboard control and now we are in the very first test, the test procedure is as follows:

  • Start a Python script, waiting to send commands in ROS2 topic;
  • Upload a plan in QGroundControl, including position waypoints and one change_speed waypoint;
  • Start mission in QGC;
  • The script keeps waiting until near a certain GPS coordinate (coordinate of waypoint #5 in our case), then it sends command of switching into Offboard mode;
  • The script deliberately exits, let PX4 fallbacks into Position mode;
  • Mannually switch into Mission mode in QGC;

The reason why we deliberately let the code exits is that, we are trying to investigate Flight #1 in Unexpected and dangerous behaviours after going in & out of Offboard mode, where we were supposed to switch into Offboard mode for 1 second, but the code raised an error and exited, then the VTOL kept descending then crashed into the ground.

We repeated several times and found out that in some cases, the VTOL (standard_vtol to be specific) kept descending then crashed on the ground, but in other cases it followed the waypoints as normal.


Here are the PX4 log files:

Here is the Mission Plan file that we uploaded every time: basic_mission.plan - Google Drive.

We are reallly curious about the issue. Why did it happen? Why not every time? What possibly causes the issue? I will really appreciate it if someone could share some thoughts!

1 Like

We just found out that in runs that VTOL eventually crashed, body angle setpoints (green lines in the plots) just vanished after switching back to Mission mode. On the contrast it stays alive in the normal runs. Here we compared Crash #1 to Normal #1.

We think that is strongly related to the crash issue, but we still couldn’t figure out exactly why.

can you share your ros2 offboard code?

Hello @crazy-robotics, thanks for the reply!

I am sorry that the code is concerning a private project so we could not share it. However I think you could read the vehicle_command outputs from the .ulog file. The code only sent command into Offboard mode, and I think it can be read from the ulog file.

Hello @crazy-robotics !

Even though we couldn’t share our code, we have ROS2 bag recorded everytime.

Link: ros2bags - Google Drive

Every run is related to one ROS2 bag, e.g., the Crash#1 run is related to rosbag2_2025_04_08-21_43_44_0-Crash#1.mcap.

1 Like