As @timtuxworth points out, DO_LAND_START is used for go-arounds. I often set up missions that way without using RLT_AUTOLAND. I think the check is a good idea, but maybe this needs to be the other way around, that if RTL_AUTOLAND is 1, then check for a DO_LAND_START.
1 Like
I agree with @Allister and can I ask if you could revert this change from 4.2.0, even if the ‘fix’ can’t make it in?
@Allister @timtuxworth I’ve opened a PR to make this arming check specific to quadplanes. On quadplanes you can’t do a DO_GO_AROUND, so there is no use for DO_LAND_START without RTL_AUTOLAND.
That will still leave us with an annoyance for QGC auto-created missions, but I think we need to fix that in QGC.
Thanks for the feedback!
I like how QGC does this, just saying …
In your 4.2 announcement on RCGroups you mention Soaring speed to fly additions. I can’t find any other mention of this. Can you please elaborate?
Thanks
Sam has some info in his video from the last dev conference:
For more detail on how to use it I suggest asking in the soaring topic:
@Allister @timtuxworth I’m wondering if a better solution is to just suggest that users who want DO_LAND_START without any RTL_AUTOLAND set RTL_AUTOLAND to -1. That works now, and prevents the arming check failure.
I really do want this arming check as the vast majority of users who setup DO_LAND_START do want to use it for their landing sequence, and I’ve seen how forgetting to set RTL_AUTOLAND can lead to disaster and loss of an aircraft. The user sees the DO_LAND_START marker in the mission and assumes the plane will start the landing sequence there.
@tridge according to the docs there is no “-1” on RTL_AUTOLAND and QGC has no option to set it to -1.
Are we trying to implement a general solution for a specific problem? What exactly caused “it didn’t”, and what was the unusual flying location?
I don’t know if you’ve seen my post about a crash I had when my plane did an RTL after it had landed (caused by the geofence being too close to the runway). Geofence breach RTL after landing = crash
I’m not trying to change the subject, just thinking that the whole auto land design maybe needs some thought end-to-end, including input from @iampete and @WickedShell and others, rather than just patching individual issues with possible unintended consequences.
Sorry that’s the wrong post - hang on, I’ll fix it. Ok - fixed. Geofence breach RTL after landing = crash.
I could live with that. Then it’s a user choice one way or the other to set it up or leave it. It will need a wiki update. I should learn how to do that just to help out…
2 Likes
Are you sure? How about this? You are landing a quad on a ship … an unexpected large wave buffets the vessel just as you are about to touchdown with the quad. You abort the landing - but you still want to land - so - go around? (start again)?
So does this mean we need to get QGroundControl changed? If it’s data driven I guess it might work, but right now there is no option in QGC to set RTL_AUTOLAND to -1
Admittedly I’m not a regular user of QGC. I mostly only use it from my iPad in the field with a few vehicles. But I think you can use the “advanced settings” in a parameter to override the basic choices.
Oh I see you can do that - you have to select “Advanced Settings” and then “Manual Entry” - so this means that for the wizard generated drag and drop landing in QGC, it will always throw this error on arming and the user will have to figure out that they need to manually override this value.
It kind of defeats the “user friendly” idea of having the landing setup wizard no?
I use QGC whenever I can, mostly because I got rid of my last Windows machine more than 10 years ago, I only have Macs, one in the office, one for the field.
i’ve updated the PR so there is a new RTL_AUTOLAND=3 that disables the arming check and allows for go-around usage of DO_LAND_START
So that would be the same as the -1 you mentioned before?
yes, both -1 and 3 will work, I just decided to make 3 the one that will appear in the dropdown menu when setting the param
1 Like
That makes sense. I’m good with it. Thanks!