FW landing: terrain altitude saving, flare pitch control and rangefinder bump


So I’ve been thinking about a couple of things related to the fixed wing autoland. Basically I’d like to include some of the features that are implemented in Ardupilot or could make the landing very precise even with just a low range sonar.

  1. Ardupilot handles the change in altitude (the “rangefinder bump”) when the distance sensor gets its first reading by steepening/flattening the glide slope. Is there a safety mechanism in PX4 for avoiding possible deep dives near the ground?

    What has been my solution for this in PX4 is that the glide slope + flare part are just moved further away if the vehicle is too high when the rangefinder gets its reading. If the moved distance is too high, the vehicle will just abort the landing. What do you think, is this even required?

  2. Possibly a better solution for the pitch control in flare? Now the pitch just seems to be increased to the minimum flare pitch at touchdown. There is an elegant path calculated for the flare (in landingslope.cpp), could this be utilized with the tecs controller?

  3. I think I read that in Ardupilot, if the rangefinder bump can’t be handled (too steep resulting glide slope), the vehicle will abort the landing and save the terrain altitude for the next landing try.

    I implemented (3) for PX4 so that the terrain altitude is tracked while landing (while having a valid reading). In case of a go-around, the difference between the actual terrain altitude and the landing altitude setpoint is added to all the following waypoint altitudes. What do you think? Here is the branch: https://github.com/PX4/Firmware/compare/master...almaaro:land-terrain-alt-adjusting

Best Regarda,


Auto abort can be a neat feature if implemented correctly. However, it should be enabled by a parameter since many users may want the vehicle to never auto abort. In my experience, I’ve used auto abort type functions (on other UAVs that had them) only when the landing was very-very far from the intended altitude or cross track (e.g. >30 meters altitude or cross track error).

Neat branch. One thing that might be important is a “point of no return” when the vehicle is too close to the ground to safely perform an auto abort. Maybe the flare point is a good place for this, or maybe you want it before the flare point. I strongly believe the user should be able to manually abort anytime the vehicle is still flying (e.g. slider button in QGC), but auto-abort should have some safety limits. In my opinion anyway.

@almaaro have you ever considered some sort of “bump landing” feature to aid in landing accuracy? The concept here is a mechanism for the user to make small adjustments in real-time to the landing slope and track to manually compensate for the autopilot’s altitude and cross-track error. The user interface for this would be some buttons on the screen (e.g. in QGC) or arrow keys on a keyboard, or map to a gamepad/joystick. This idea works quite well if implemented correctly. There are a many ways to approach it, but they generally either involve: a temporary shift (or bump) to the position of the Land point, a temporary shift (or bump) to the lateral and vertical rate control, or a combination of these concepts.