MC Waypoint land and RTH land descent rate

[Jetrell]

I was reminded when looking over some multicopter DVR footage from back in October. That WP landing and RTH landing are acting differently in the descent control.

The MC RTH landing descent cycle works correctly... While Landing based on a Waypoint condition. Will only place the multicopter in the correct position to land. But appears to negate nav_land_maxalt_vspd. And instead jumps straight to nav_land_minalt_vspd.
Which obviously takes a long time to descend at 0.5m/s.
This was observed in multiple tests that day, with the same settings.
And I have also ran that same mission many dozens of times previously, in other firmware tests. And had not observed that behavior.

Has anyone else experienced this ?

[breadoven]

Probably caused by #8555 which changed the RTH landing code (WP missions use the RTH landing code to perform a landing). Don't why this was changed the way it was ... doesn't make much sense.

[Jetrell]

Thanks for taking a look and reporting back 👍

[JulioCesarMatias]

@breadoven I also don't understand the reason, but the line that is causing this is an if condition:

uint32_t remaning_distance = calculateDistanceToDestination(&tmpHomePos);
if (STATE(MULTIROTOR) && (remaning_distance > NAV_MC_RTH_LAND_MARGIN_CM)) {
descentVelLimited = navConfig()->general.land_minalt_vspd;
}

If he wanted to apply this only to VTOL, using the STATE(MULTIROTOR) check was not the correct step.

Some things are merged into master, and there seems to be no correct revision of what is being merged...

[breadoven]

It seems to be intended to slow down the landing if the quad drifts too far away from RTH home position, to give it time to move back into position I guess. But it overlooks the fact the RTH landing method is also used for a WP landing which could be anywhere other than the home position.