Hi! I’ve got a question that I didn’t see addressed anywhere:
I’ve got a couple quadrotors, very different sizes, different boards, and even different Arducopter builds (one is 3.x era, one is 4.x), but both exhibit the same behavior - when in Auto, and commanded to land, there is a small (2-3 ft.) commanded altitude gain, before the landing commences. This is reflected in the DALT value, which the aircraft then matches (see attached for example). This doesn’t seem to be vibration related; the altitude estimate is good, the track is reasonable - just the setpoint ramps up, and the aircraft follows it.
I’m assuming this is an intentional behavior - having said that, is there a way to disable it? I’d like to be able to shoot a straight-in approach to landing.
Ah, very interesting. I haven’t flown the 4.x bird for a few months, and it isn’t currently available for a quick re-test; I’ll take a look at what logs I can dig up. (This is a very latent question - it was on the squawk list that I’m finally getting around reviewing.)
In the meantime, any general suggestions as to who the usual suspects might be? Any wound-up integrators I should be looking at, etc.?
Not really. Vibe levels from the mode switch event maybe. Pressure bubble from unshielded baro. Or maybe just poor tuning. Why isn’t everything on latest Stable or Beta?
Also, your graph didn’t include some potentially useful data.
One was a Part 107-registered vehicle (I don’t have access to that right now), it was on Stable, as of last summer; the other was an ancient 3DRobotics Iris (just checked, that’s running 3.2.1); the previous pilot never updated it, since it was basically used exclusively in LOITER mode.
One thing to clarify - I’m not mode switching - this is all in nav (AUTO) mode.
Yeah, sorry for the poor quality of the plot (that’s from the Iris) - it was only meant to illustrate the basic phenomena; i.e. the altitude setpoint was changing. I’ll update the Iris to 4.1.5 - with any luck, the jump goes away - if not, I’ll post logs.
That would have been apparent had the graph included it. Is it a Land mission command or RTL? Anyway I think your question was answered this isn’t a feature you can disable.
Also yes, much appreciated, knowing that this is a non-standard behavior is definitely helpful. I’ll let you know what I see after firmware updates, either way.
Ok, I’ve updated to 4.1.5, swapped the old Pixhawk for a Cube (Orange), and went out and flew the same simple flight plan, ending with a LAND mission command. The attached log has two executions of the same plan, and in each one, there’s the exact same desired altitude bobble at the LAND command.
Note I ran the log through the Mission Planner anonymizer, so it’s a .log, not the .bin; nothing particular to hide, but I fly in my back yard, and as a matter of personal preference, I try not to post my exact coordinates on the internet. If this is a problem, I’ll post the original .bin.
I would start with some tuning. Configure the Dynamic Notch Filter, which is part of standard tuning, and then run Auto Tune. So the 1st thing to do is to set INS_LOG_BAT_MASK to 1 and make a simple AltHold Hover flight for a minute or so. Forget about the Auto Mission until it’s tuned.
And set these as per the Tuning wiki from the MOT_THST_HOVER value.
PSC_ACCZ_I
PSC_ACCZ_P
It’s covered here: PSC tune
No problem with anonymized logs (.log) for evaluation with Mission Planner.
OK, I’ll step through the tuning tomorrow. The default value tune was reasonably flyable, so I ran the previous flights just to see if the commanded 0.5m climb-on-land was still there.
Genuine question, I’m trying to get a better grasp on the architecture here: based on a cursory examination of the source code, I’ll admit I don’t understand how poor tuning would cause changes in the altitude (and altitude velocity) desired values. Obviously, the actuals could be all over the place, but the land routine basically just passes the Z-loop a fixed descent rate for the setpoint, right?
Side-note: dodging between afternoon rainstorms, I did run a couple tests in LAND and RTL modes (switching from STAB and LOITER). I know, not tuned; but neither LAND nor RTL exhibited the 0.5m climb-before-landing in the altitude setpoint - they were exactly like the example you posted.
Well, I just solved my problem. The fact RTL and LAND mode worked as expected got me thinking - my land waypoint altitude had always been set to zero - seemed to make sense at the time. Throwing figurative spaghetti at the wall, I set it to 10 ft., and bam - no more climb-before-land. The profile is now exactly as expected; descending from cruise, hit the hover point, and then descend to touchdown. The log probably isn’t of interest, but here’s a screenshot of three iterations. The plateau on the climbout is the end of takeoff, and the counterpart coming back down is the hover point, just before the landing routine starts.
In any case, I’ll tune as suggested, and then explore this more.
An addendum: if lat/lon for the land waypoint are set to zero (i.e. land at current location), then the altitude can also be set to zero, and it will still behave as expected. Based on this, I suspect that the desired altitude increase originates in the IF statement at line 1315 in mode_auto.cpp, specifically, when target_loc is set by the terrain_adjusted_location function call and the state is changed to FlyToLocation, which are only invoked for non-zero lat/lon values. Otherwise, it immediately sets the state to Descending, just like RTL and land mode, and unsurprisingly, performs a direct descent.
