Starling 2 Max - max thrust in position mode, with throttle at 0, causing it to jump into the air unprompted.

[aspen]

Hi, we experienced an unexpected takeoff from the startling 2 Max. After flying a short hop to validate the GCS failsafe would trigger, we landed and then 40 seconds later the starling jumped up into the air unprompted.

Sequence of events:

• We flew the drone in position mode, forced a return to land by disabling the GCS (to see that the failsafe was behaving as intended) and then we let the drone land.
• The drone landed (visually) but never disarmed.
• It sat on the ground with 0 throttle from the pilot, but never disarmed.
• After 40 seconds, the starling 2 max shot up into the air 15 meters at max speed (with the throttle still down)
• The pilot took control in stabilised mode, landed the drone, disarmed and unplugged the battery.
• We have not flown since.

We were flying outdoors, with a 3D GPS fix ~25 satellites (we are now aware of the GPS EMI interference issues with the starling, which we believe has been causing us to have very poor altitude tracking +/-10 meters).

** Possible cause **
We noticed in the logs that the vehicle_local_position_setpoint/acceleration value increases from about 20 to a number so large it causes a floating-point overload, causing the acceleration to go negative.
At the point where the value goes negative, the propellers spin up full speed, and the drone jumps 15 meters.
The increase in value took place over about a second.

What is going on here?

138.0s into the flight, the acceleration setpoint starts increasing rapidly.
At 139.7 seconds into the flight, the thrust starts increasing, which coincides with the acceleration setpoint overloading and flipping sign.
The event ends at about 141.5s into the flight, by that the time the drone is almost 15m into the air.

We do not know the root cause of the acceleration spike.

Questions:

1. Why did the drone not land when it came to a stop on the ground with 0 throttle?
2. Why is the acceleration unbounded? Has anyone seen this before? Are there known fixes in later versions of PX4?

[aspen]

@aspen
It could be because of a race condition discussed in an older version of PX4: https://github.com/PX4/PX4-Autopilot/issues/20275,

In PositionControl::updateHoverThrust(const float hover_thrust), _hover_thrust_new is not constrained by the same amount as the stored _hover thrust because we are pulling down on throttle and keeping ourselves stuck to the ground the estimate for hover thrust is much smaller than the 0.1 default constraint.

This then leads to a build up here

I threw in the other constraint as well to _vel_int(2) here just be more consistent as there are a lot of steps that use it before it eventually gets constrained here link

Ref: https://github.com/PX4/PX4-Autopilot/issues/20275

I suspect that it is an issue that the PX4 community have identified and solved, and needs to be pulled into the modal-ai fork.
I worry that this might happen to any drone that is armed and idling on the ground.

This does not solve the issue of the drone not correctly identifying that it had landed.

[Eric Katzfey]

@aspen Can you provide the log file? There is a version of px4 v1.16 available here: http://voxl-packages.modalai.com/dists/qrb5165/dev/binary-arm64/voxl-mainline-px4_1.16.0-1.0.4-202509030932_arm64.deb

[aspen]

@Eric-Katzfey
Hi @Eric-Katzfey, I've uploaded the log here: https://drive.google.com/file/d/1EB-k81ApQx6CwbW7mSUm39lCofRdbEXm/view

[Eric Katzfey]

@aspen The landing detector in PX4 isn't perfect (obviously) so in this case it didn't detect the landing. I would map one of the switches to toggle between arm and disarm so that when the drone lands you can disarm via switch. Did you try the v1.16 package?