I have octocopter based on Arducopter 4.03, Cube Orange, Drotek Sirius F9P GPS (RM3100 magnetometer) with 16" propellers weight around 12kg. It fly ok, alt is holding very good I didn’t have any problems with it. But I wanted to get Flow Hold possibility and better resistance for bed reception of GPS, maybe indoor loiter flight possibility, etc… So I bought HERE FLOW and Lightware SF30/D Rangefinder and the problems started. I have standard settings for Rangefinders so main source of alt is BARO (EK2_ALT_SOURCE:0), but when I am flying over the bushes or trees alt is getting crazy. Copters motors and ESCs are working harder alt is not stable like without rangefinder. Copter is changing altitude quite rapidly. Sometimes even few meters. It’s important that I don’t change the throttle ! I am trying to fly at the same height. I have standard settings so no any terrain follow etc. I tried to change:
EK2_HGT_I_GATE
to lower:from 300 to 100 but it didn’t help.
Every time the copter is over the bigger plants, bushes, trees altitude is not constant. I tried even different rangefinder Benewake TF03 180 and the problem is the same. It looks like Arducopter firmware still using rangefinder data to estimate the altitude??? It’s a bug ? Maybe I am missing something? Any parameter to change such behavior of the copter??? How to get stable alt hold with rangefinder?
My logs and parameters:
https://fotostacja.pl/logs_SF30d.zip
https://fotostacja.pl/parameters.param
Hi, I use sf11c and see the same behavior, though I don’t see crazy actions, the vehicle does rise above bushes. It happens in Loiter and PosHold and the same as in your case, terrain follow is off.
Ok so that’s normal that when using lidar for ALT HOLD copter always do some terrain following? The worst is flying over the bushes and reeds. Alt is jumping constantly.
It seems to me that when the parameter is setup on BARO (EK2_ALT_SOURCE: 0) the Lidar is not desactived.
According to the settings of RNGFND min and max if the drone is included in this value it will use the lidar and if you are outside these values it will use the barometer.
Can you tell me if for you the lidar also works in Auto mode ?
@chr89 I will not test AUTO mode until I would not understand how copter the copter holds ALT with rangefinder.
In auto mode, the rangefinder is not used during flight, unless you change the settings. However, it is already used during landing. If the drone is at a higher altitude than the lidar range when landing at a location other than takeoff, the drone will stop landing and return to home. To prevent this from happening, you need to use a lidar with the right range or change the parameters, now I don’t remember what. But then it makes no sense to use lidar.
I asked this question because in my case, I want to use the lidar for flight at low altitude 2 / 3m from the ground and it does not work in Auto mode. This is why I asked the question see my post:Problem of rangefinder in Auto mode
@chr89 ok I understand. I think when the problem with ALT HOLD and lidar will be resolved it will be useful also in AUTO mode. Something will be improved here because in 4.04 firmware I can see new settings for rangefinders:
RNGFND1_WSP_MAVG: Moving Average Range
RNGFND1_WSP_FRQ: Frequency
RNGFND1_WSP_AVG: Multi-pulse averages
RNGFND1_WSP_THR: Sensitivity threshold
I also found in my 4.03 parameter:
RNGFND_GAIN
Is there anyone who can explain from experience how it works ?
I’ve scratched on this a little in https://github.com/ArduPilot/ardupilot/pull/14346
I’m not sure my change is right, but I definitely don’t think it’s working at the moment
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?
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
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.