Why does drone suddenly switch AUTO.LAND mode from offboard mode when descending? (Failsafe enabled: no offboard)

[AlexWUrobot]

Thank you very much for your help.

Is there any min height setting in QGroundControl, which will trigger the AUTO.LAND mode?
During my offboard control descending, the drone suddenly switch to AUTO.LAND mode from offboard mode.

I am confused about that and the unexpected switch mode makes the programmed descending drone has a unexpected spike, like the video at 1:47

There is the Pixhawk log and the screenshot of the distance sensor.

At the time stamp: from 1686240419 to 1686240422
the unexpected switch mode behavior makes the drone fall suddenly, when it was from offboard mode to AUTO.LAND mode.
When it resumes from AUTO.LAND mode to offboard mode, the drone spikes suddenly.

In the python script terminal,

In the communication terminal:

In the rosbag record:

I also suspect my fail safe setting is like this

similar issue:
CMD: Unexpected command 520, result 0

[AlexWUrobot]

Similar situation happened again.
During a flight, the offboard flight mode switch to land flight mode for 0.5 second and then switch back to offboard mode repeatedly.

I guess the Pixhawk loses connection with Jetson TX1 (offboard mode), so the Pixhawk turns to land flight mode automatically.
After 0.5 second, the Pixhawk gain the Jetson TX1 again, so the Pixhawk returned from land flight mode to offboard mode.

The python flight script (program) running on the Jetson TX1 (offboard mode)

failed landing video (autonomous control) (13:01 missing connection) (log) (terminal)

[sibujacob]

Hi,

There are two parameters which determine the landing scenario - LNDMC_XY-VEL_MAX and LNDMC_Z_VEL_MAX …Kindly try adjusting this to a lower value and report here … Also LNDMC_TRIG_TIME . …

[AlexWUrobot]

Thank you very much for the information.
It is very helpful.

According to the document, LNDMC_XY_VEL_MAX and LNDMC_Z_VEL_MAX are to set the max velocity allowed landed state.
Thus, if decrease the value, maybe the drone may never land, because the drone flies at the speed over the VEL_MAX?

On the other hand,
my current overall XY and Z velocity is lower than 1 m/s, according to the log and the topic /gps_vel.

3rd flight (Offboard control) (land) log and terminal happened
“unexpectedly mode changed from offboard to AUTO.LAND”

but, the velocity looks ok at the time 1687906269. There is the full log video.

Thus, I am suspecting some possible reasons may unexpectedly trigger AUTO.LAND during offboard control.

1. Low Battery: If the battery voltage drops below a predefined threshold set in the flight parameters, Pixhawk and QGroundControl can automatically trigger AUTO.LAND mode to ensure the aircraft lands safely before the battery is depleted.
2. Lost Communication: If communication between the ground station (QGroundControl) and the aircraft is lost for a specified duration, AUTO.LAND mode can be triggered as a failsafe mechanism to initiate a controlled landing.
3. Failsafe Conditions: Pixhawk and QGroundControl have configurable failsafe conditions that can be set by the pilot. For example, if the aircraft loses GPS signal, experiences a loss of control link, or encounters other predefined abnormal conditions, AUTO.LAND mode can be automatically triggered to ensure a safe landing.
4. Geofence Violation: A geofence is a virtual boundary set by the pilot using QGroundControl to restrict the aircraft’s flight within a specific area. If the aircraft breaches the geofence boundary, AUTO.LAND mode can be triggered to bring the vehicle back to the ground safely.

I may exclude 1 and 4, because there is no warning in the log. Battery is full and Geofence is off.

[AlexWUrobot]

Testing flight
Change LNDMC_Z_VEL_MAX from 0.5 to 0.3 m/s
Change LNDMC_TRIG_TIME from 1.0 to 0.8 sec

The issue “unexpected switching from offboard mode to AUTO.LAND mode” still happens.

There is the Pixhawk log and terminal record.

I found the

Unknown event ID 27046499
Unknown event ID 24156043
Unknown event ID 27600898

may be the cause.

I further read this log by PlotJuggler.
The error is Failsafe enabled: no offboard

Thanks a lot for any advice ^^

[Benja]

hi @AlexWUrobot
The Failsafe enabled: no offboard is triggered when you loose offboard control, it could be caused by some delay on your ROS 2 side or some bottleneck on the serial communication,… or something else.
You are landing because that is the failsafe behaviour imposed by COM_OBL_ACT .

Now you have to debug why you loose connection.

[AlexWUrobot]

Dear Benja:

Thank you very much for the information.
My hardware is Jetson TX1 and Pixhawk PX4_FMU_V5.
Run ROS1 on Ubuntu 18.04 in the Jetson TX1.
The Software Version is v1.13.3 in Pixhawk.

My COM_OBL_ACT is 0 (Land mode) and COM_OF_LOSS_T is 1 sec

The jetson TX1 publish /mavros/setpoint_velocity/cmd_vel at 20 Hz.
I find the issue tends to happen during descending, instead of hovering.

There is the log and code for descending.
There is the log and code for hovering.

I also tried to lower the publish rate from 20 Hz to 10 Hz.
The log still shows the same issue happening.

[Benja]

A snapshot of your descent flight is this:

The offboard control is running on MAVLINK 1, Telem2, and you have a ttl2USB adapter.
I see two possibilities:

1- your code is running correctly, but there is an issue on the serial link
2- the serial link is ok but for some reason your code does not send the commands with correct timing.

As there is also [commander] Connection to mission computer lost which means that even the telemetry is not coming… a mavros issue then.
But if you are hovering… no issues!

Are you overloading your companion computer in the descending phase?

[AlexWUrobot]

Dear Benja:

Thank you very much for the detailed explanation.
There is my system overview. Yes, I connect Pixhawk to Jetson Tx1 through the TTL-232R-USB cable.

I have the rosbag record and a camera running on the Jetson TX1.
Besides the log and code for descending, I also run the rosbag record and python script in terminals.

The python script running in the terminal shows the “unexpectedly mode changed from offboard to AUTO.LAND”, at the timestamp 1687906269.
There is the full terminal record

However, the rosbag also looks ok, at the timestamp 1687906269.
There is the full log video and rosbag file.

I further change
COM_OBL_ACT from 0 to 1 (Hold mode)
SDLOG_MODE from 1 to 0 (Record log during arm and dis-arm)
and flied three tests today.
1st flight (RC manual control) log
2nd flight (Offboard control - hover) log
3rd flight (Offboard control - descend) log

I find that the the disconnect issue also sometimes happens in hover.

[AlexWUrobot]

I further looked up my previous flight and find the issue does not happen.
log_138_2023-2-11-14-34-18
log_139_2023-2-11-14-45-36
log_140_2023-2-11-14-53-48
log_141_2023-2-11-15-03-38
log_142_2023-2-11-15-09-08
log_157_2023-2-12-18-46-50
log_175_2023-5-21-21-09-30
And the issue started to happen on
log_178_2023-5-21-21-37-46

Compared to the setting,
I suspect the value of baud rate may affect the connection of the companion computer.

[AlexWUrobot]

I further completed eight flights.
log323~326, set (SER_TEL2_BAUD: 921600)
log323, manual (RC control)
log324, Feb_12_twoTag (timestamp = 1688593134.568808) (MAV_1_RATE:115200) (issue happens)
log325, Feb_12_twoTag (timestamp = 1688593848.701527) (MAV_1_RATE:60000)
log326, Feb_12_long.py (timestamp = 1688594073.086129) (MAV_1_RATE:60000) (issue happens)

Suddenly, I met an issue “TM : RTT too high for timesync: 0.0”
solved it by set timesync_rate to 0.0 in the file /catkin_ws/src/mavros/mavros/launch/px4_config.yaml
and then keep testing the issue (Failsafe enabled: no offboard)

log327~330, set (SER_TEL2_BAUD:115200) (MAV_1_RATE: default 0)
log327, Feb_12_twoTag (timestamp = 1688597156.887726)
log328, Feb_12_long.py (timestamp = 1688598109.500374)
log329, June_8_20Hz_land.py (‘date and time=’, ‘05/07/2023 19:06:38’) (issue happens)
log330, June_8_20hz_land.py (‘date and time=’, ‘05/07/2023 19:16:45’)

I suspect the rosbag record may overload the Jetson TX1 and sometimes causes the connection unstable?
There is the screenshot of the htop.
The 2nd CPU threads is 100%.

[AlexWUrobot]

I guess the reason is that rosbag record the camera video put too much pressure on Jetson TX1.
After I do not record the rosbag. the issue seems less happening.
There is the flight log.
13-09-2023 00:36
13-09-2023 02:17
13-09-2023 03:10

[AlexWUrobot]

Finally, I think that I found that the issue.
The battery of the RC controller should be about 8.1 v to 8.4 v, instead of 7.7 v.