we use mavros to load a mission into our quad, and when we fly it, at the last waypoint the quad rises to ~40m before coming down and landing.
Here is a log:
The mission starts with a takeoff command, after which we put in all our waypoints and (potential) ROIs. After the last waypoint, we set a land mission item with a specified position. When the quad reaches that mission item, it flies to the correct spot, rises to approx. 40m and then lands normally.
When we use mission planner to put in a similar mission, we don’t see that behaviour.
Any ideas why that could happen/what we do wrong in setting up the mission?
I just tried it again, it even happens when using a WP on the same GPS position beforehand.
Still need to try if it happens if I first use a WP to fly to the desired position and then land at 0,0.
If this is a bug then it may be an issue within the precision landing code. @WARGRaph could you try disabling precision landing to confirm the issue goes away?
I tried to recreate this in the simulator but wasn’t able to. Of course that doesn’t mean there isn’t a problem, just saying that I’m having a hard time tracking down the issue.
I see that the RNGFND1_MIN_CM has been set to zero and this seems to be causing the rangefinder to think that it has a good altitude when it doesn’t. In the graph below we see the distance (in green) and the rangefinder’s state of health in red (high means good). We see it is going healthy when the altitude has dropped to zero which isn’t good. Could you try increasing RNGFND1_MIN_CM to 10cm?
Good “nose”, that fixed it!
I don’t even fully remember why we set it that way.
Thanks for the help!
I actually noticed while trying that out that LAND with given GPS coordinates always seems to return to home, which I did not expect. I will open another topic for that.
OK, great thanks for confirming that and glad that it is resolved for this vehicle at least. Leonard and I will continue looking into whether there is a bug that led to the odd behaviour… I think there must be.
OK, I’ve gotten to the bottom of this issue and it turns out that it is a long standing issue.
The problem is that when a Land command has the lat/lon specified the vehicle will always try to fly to that lat/lon at the current altitude-above-terrain completely ignoring the altitude frame set in the command. This was likely done on purpose a long time ago before Mission Planner (and other GCSs) supported setting the frame individually for each command.
I’ve created a PR to change the behaviour so the vehicle will obey the altitude frame specified.
Of course the scary thing about your experience was that the vehicle flew up to 40m (and it would have flown much higher if the altitude fence hadn’t been enabled). This was caused by the vehicle attempting to do terrain following with a rangefinder that was incorrectly reporting that it had a good altitude when it didn’t. This problem stems from a limitation in the Benewake TFmini (which is what I think you’re using) in that it does not report a “reliability” like the TF02 (and perhaps other Benewake lidar do) meaning that the driver doesn’t know if “0” is a valid reading or not… I might check with Benewake about this though and maybe their lidar will never report 0 if the distance is valid.
… by setting the RNGFNDx_MIN_CM to 10 you effectively told the driver that 0 was an invalid reading and resolved the problem. In general RNGFNDx_MIN_CM should never be set to zero… perhaps we should enforce that somehow.
EDIT: the above PR actually would have avoided the problem you saw from happening I think even with the RNGFNDx_MIN_CM set incorrectly.
EDIT2: In case you’d like to test this here is a binary for the MatekH743-bdshot which is Copter-4.2.1 with this patch applied. It would be most interesting if you could set RNGFND1_MIN_CM back to zero and test what happens. Be ready to re-take control of course but I suspect it will display an error message but still perform the land correctly.
