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.
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)
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 . …
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”
Thus, I am suspecting some possible reasons may unexpectedly trigger AUTO.LAND during offboard control.
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.
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.
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.
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.
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 .
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 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?
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
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.
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)
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%.
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