I stumbled over two behaviors in LAND mode that I would call bugs. Especially when using LAND mode in combination with a failsafe, such as battery failsafe:
1.: The Quad descents to 10 m and waits there for an unknown time (seen anything between 10-20 secs) and only then continues to descent.
Quite honestly: 20 secs is a long time, too long in a battery failsafe scenario. Imho I wish that value was a) deterministic, b) documented somewhere (it’s not documented here: copter.ardupilot.com/wiki/land-mode/) and c) configurable
2.: While the Quad “sits” at 10 m and waits it’s not possible to force it into descending via the throttle control. Imho this should be possible.
Did I miss something or are the behaviors I experienced really the anticipated ones?
Thanks
HRM, RTL has RTL_LOIT_TIME, Time (in milliseconds) to loiter above home before begining final descent which was like 10 seconds for me by default and I dialed it back to 1 second.
I don’t know if Land uses that, probably not. Is your failsafe set to RTL?
But I agree with you on both issues if RTL isn’t what you need but I suspect you already know that.
I have the failsafe configured for LAND for sure. And even when initiating the LAND mode manually from the RC transmitter, I get the same behavior. I went through that exercise a few times, just to be on the safe side.
Let me change the RTL_LOIT_TIME value and see if it has any influence on the LAND loiter time.
But I guess there should be a LAND_LOIT_TIME value instead, which doesn’t exist today.
hi, maybe that helps: I just tested RTL and LAND (from waypoint LAND and battery LAND) and its working perfectly. I’m using 3.1.2 on a pixhawk. in RTL there is a short time wait and loiter (some seconds, but not 10-20) after quad reached the GPS cords until it starts descending.
maybe try it with a fresh 3.1.2 reset of all parameters?
I agree that it should be possible to manually land the quad faster (take over altitude control as in loiter) in a failsafe LAND or RTL.
It is not a bug. We have that delay in there by design. Pausing allows the inertial nav altitude and the baro altitude estimates to align so that we can continue the decent to the ground at a very controlled rate.
As the vehicle flies through the air, the local air pressure drops (Bernoulli principle). How much the pressure changes depends on how fast the vehicle has been travelling and the specific geometry of your particular air frame. If you look in your logs at the baro alt and the inertial alt you can adjust the RTL_LOIT_TIME if they are converging faster than the default time.
@ziisco: I’m already using version 3.1.2, but still see this behavior with LAND mode. Keep in mind that I’m not talking about RTL, but LAND mode.
Try the following: Place the Quad at 12-15m and initiate LAND mode. It will descent to 10 m and wait there. Try to force it to descent via Throttle. Won’t work, which is imho bad. Wait and see how it will take until your Quad starts the descent from 10m.
@Craig3DR: I do understand the necessity of loitering in a RTL case or even in the case that LAND was called as part of an autonomous flight.
But in case LAND was triggered by a failsafe, I would argue that “speed to ground” beats “very controlled decent rate”. Maybe we need a special FS_LAND mode that differs from LAND mode used in autonomous flight.
Also a few questions that remain open:
Does RTL_LOIT_TIME also apply to the loiter time in LAND mode?
Why is the loiter time of LAND mode not documented?
And while in altitude loiter - whether RTL or LAND - I would also argue that one should still be able to initiate a manual decent and thus override Arducopter without having to do a mode switch.
I get a bad feeling when the operator is “overriden” by an automatism.
I’m wondering if this problems is actually that the Loiter performance is a bit loose, and the WP Radius is small. I’m not sure about Land mode, but I know this has caused me problems on RTL. It wants to make sure you hit the RTL waypoint precisely before it begins the land. And if it’s moving around a bit, it won’t be satisfied, and will keep trying to get that target point. This causes an non-deterministic delay on the RTL landing.
So, you could try opening up the WP Radius parameter a little bit.
Rob you’re the best, I bet that is why I have some trouble with RTL when it is windy, the almost 6 ft octo doesn’t hold position too well in 20 mph wind and sometimes will take forever to land in RTL.