Can someone clarify that? Is that normal that even when
EK2_ALT_SOURCE: 0
(so the BARO is main ALT source) and you fly over the trees or bushes rangefinder is used and messing ALT HOLD ?
That’s a bug or that’s normal behavior of EKF 2 ? Is there any pull request for that ?
This is the real fix: https://github.com/ArduPilot/ardupilot/pull/14375
Not sure what happens when you fly over bushes or trees in this instance.
Here is the wiki page for terrain following in AltHoold, Loiter, etc.
Here is the wiki page for terrain following in autonomous modes.
You can turn off terrain following in these modes using an auxiliary switch, hopefully you’ll find the link on the pages above. The EKF is not involved in terrain following.
If you’re flying outside you definitely don’t want EKx_ALT_SOURCE = 1. If you are flying outside, leave EKx_ALT_SOURCE = 0 (Baro).
@rmackay9 I understand that. I just can’t understand why even when EKx_ALT_SOURCE = 0 (Baro) is set, the ALT HOLD mode is messed by rangefinder. I don’t need any terrain follow in LOITER or POS HOLD I need rangefinder for optical flow sensor.
I get nice solution from anbello that I can enable/disable rangefinder by auxiliary switch info here and choose when I want to use it. I checked this and this works nicely.
Hi. I have a SF11 and have the same problem when in Auto and flying over obstacles like trees and then flat ground in short distances, that is my Hex will suddenly climb and descend when crossing high object’s like trees. It seems that when flying over this type of terrain the best solution is to disable the rangefinder when in Auto which is disappointing. The wiki video showing auto being used on a ski field looks great but it is over flat terrain.
As there doesn’t seem to a setting that evens out the altitude change when suddenly flying over obstacles like trees while in Auto mode can this be looked at in future versions?
I agree, this is the biggest problem with Arducopter‘s terrain following. Some kind of algorithm that average the measured height during a short distance would be nice.
Or, maybe it could be a approach, if there would be a posibility to adjust the climb/decent speed during terrain following?
2 Likes
Do you have Terrain Following enabled and active? (different from SURFACE TRACKING which rangefinder does) and EKF2/3_ALT_SORUCE=0 as recommended for outdoor flying?..because rangefinder based Surface Tracking should not do rapid,large changes to the target altitude…it has a filter to reset to the EKF estimate if that happens, like when flying low over trees and it suddenly drops to bare ground…target alt resets to the EKF estmate and stay at that altitude until the Terrain data (if in that mode) changes or steady RF reports occur…if not TERRAIN_ENABLE, then it should stay at tree height (or whatever the mission requires but based on EKF alt estimates) unless it comes back into RF range and then set and track target alt based on the RF data, as I understand it
PS working on an understanding altitudes in ardupilot page for the wiki
1 Like
speed is controlled by WPNAV_SPEED_UP and _DN
In my oppionion, this is not the right approach. The best way would be a averaging of measured height. A separate setting for terrain correction up and down speed would be some kind of workaround. But this must be independ from WPNAV_SPEED_UP / _DN, because this would also slow down the general climbing or decenting during missions.
have any solutions been found to this problem?
No.
With the Copter 3.6 version I did lots of flights with rangefinder terrain follow last year without bigger issues.
This year, with Copter 4.03, I had lots of problems.
I had several unpredictional and strange failsafes with „missing terrain data“ errors in rangefinder (!) missions. Even old and well flown missions from last year, sometimes do not work any longer with the 4.0 version. Same machine, same configuration.
The flights itself are much more „jumpy“ with the copter hopping around. Often the flight behavior is terrible.
I raised an issue, also I wrote several times here in the forum, without solution. Sometimes I did not get a reaction at all.
To be honest, I have the impression that the whole terrain following thing with rangefinder support is broken in Copter 4.0.
I have not tested under Copter 3.6 only on 4.0.
What I find unfortunate is that the RNGFND_Gain is disabled in Auto mode because when I test in Loiter with the Gain Active mode, the behavior has nothing to do with it.
1 Like
Hi, does anyone know the way to get copters be at actual attitude with respect to rangefinder at low altitude (<= 10m). EKF altitude is always different from the actual altitude measured by rangefinder. I am flying in the flat terrain and I expect the copter should maintain at the height that rangefinder reads?
It works a lot better in master because it contains some fixes for this very situation. Are you willing to test github`s master branch?
1 Like
In current firmware 4.05 when range finder is on during loiter and position hold and alt hold modes copter changes the altitude rapidly, especially when ground is not flat and there are bushes or trees. So usually I just turn off the rangefinder to have more stable alt hold by auxiliary functions switch.
https://ardupilot.org/copter/docs/channel-7-and-8-options.html
Does anyone knows that even when the rangefinder is turn off by aux switch is it used for landing and for flow sensors ? Rangefinder is very useful for landing it is also needed for optical sensors. Is this function disables the rangefinder only for flying modes or for all functions in arducopter autopilot ?
Yes lidar is working the same on 4.0.3 firmware. There is possibility to make lidar measurements much less important for EKF. There is function “RNGFND_GAIN: Rangefinder gain” and you can set it for 0.01 and altitude will not change so rapidly during flying over bushes and trees. But “RNGFND_GAIN: Rangefinder gain” only works for Loiter, Poshold, alt-hold flight modes not for AUTO.
Abut landing wth rangefinder. There is some more info:
https://ardupilot.org/copter/docs/common-rangefinder-setup.html
https://ardupilot.org/copter/docs/terrain-following-manual-modes.html
https://ardupilot.org/copter/docs/terrain-following.html#terrain-following
Here I described another inconsistency with rangefinder altitude: Barometric desired Dalt has some smoothing when the control input is released to accomodate the inertia/vertical deceleration of the copter (I guess it is according to PSC_ACCZ).
But rangefinder desired DSalt does not have this, it keeps the desired altitude exactly at the point where the stick goes to zero.
This can cause quite big discrepancies between the two desired altitudes. Practically this will make the copter bounce back to DSalt when in range. When out of range we have dont have this, and the copter stays at the altitude it decelerated to. For me this is an inconsistent and therefore potentially dangerous flight behavior. When vertical speeds are high, those differences can be quite huge and the copter bounces back several meters. And during that time it is difficult for the pilot to make controlled corrections.
I think DSalt calculation should also take PSC_ACCZ into account, the same way Dalt seems to do. Discrepancies between DSalt and Dalt should be caused by rangefinder/terrain changes/sensor drift, but not by control inputs.
2 Likes