Copter 3.5.2 - EKF2 bad behavior with rangefinder enabled

ArduCopter Copter 3.5
, ,
1

Hi
I am trying to use data from a rangefinder for a better height estimation.
I have set EK2_RNG_USE_HGT > 0 to include the rangefinder reading in the EKF2 altitude estimation, however almost immediately I received Alt-Terrain-Variance errors, and the vehicle was unable to maintain stable height (in Pos-Hold, for example). From considering the logs it appears as if the EKF2 is taking rangefinder data in consideration even in times where it does not supply a valid signal (and in these times other parts of the firmware aware of the the rangefinder not being healthy, e.g. when “Bad Lidar Health” is displayed in Mission Planner). I even tried (as an experiment) to set RNGFND_TYPE to 0 and completely disable the rangefinder - but the problem still persists. Only setting EK2_RNG_USE_HGT back to -1 solves the problem.

Can anyone confirm this is a bug or explain this behavior?
@rmackay9 @OXINARF @priseborough

Thanks

2

Can anyone help with this?

3

I tested today with AC 3.5.5 a mavlink-type rangefinder and I almost crashed twice. When it works, it does great, the altitude is perfect, but the transition phase is when I had my altitude dropping almost 2-3 meters.

In my implementation I have a push button on my ground station that quickly activates or deactivates the ability, by changing the EK2_RNG_USE_HGT.

How my implementation works: it reads the sensor and only when it is in range, it sets the EK2_RNG_USE_HGT = 100 and starts sending the mavlink message DISTANCE_SENSOR, with the setup set as PITCH_270. In my case the minimum was set to 10 and the max to 500.

Check the Graphs below, where I plotted the Altitude (Alt), the Sonar Altitude (SAlt), the Desired altitude (DAlt), the desired sonar altitude (DSAlt) and the barometric altitude (BAlt):

image
image.png1682Ă—722 185 KB

image
image.png1630Ă—680 140 KB

image
image.png1323Ă—718 112 KB

You can see thet as soon as I enabled the sonar, the altitude jumped, especially at the end you can noticed that the system dropped as soon as I activated the sonar.

As far as I understand it looks like the system changes the desired altitude in order to maintain a sonar altitude. The range finder is not directly used in the EKF.

Can anybody explain?

EDIT:
Here is the bin file: https://drive.google.com/file/d/1U-J2UVwbyYD0jknDBjutva2_1KmjU-h7/view?usp=sharing

4

Hi, just read my experience with Range finders, maybe not really the same problem, but there is a deep problem using range finders I think. Follow terrain with range sensor Error Failsafe TERRAIN-1

5

Hi Guys, I’m having a very similar issue on my copter. Using a TeraRanger One ToF lidar. It works very well at sub 5-7m but once I climb above that I get large altitude changes uncommanded. At one point it looked like it would climb indefinitely. After landing the HUD shows an altitude of 20+m after it’s back on the ground.

It seems the problem has something to do with the handoff between the rangefinder and the barometer. I’ve attached a bin file and a log snapshot of baro vs rangefinder.

8%2010076%20Baro%26RngFND
2018.3.8 10076 Baro&RngFND.png1920Ă—1080 320 KB

6

It look like you have reached the maximum outdoour range…
Range: Up to 14m indoors (At least 5 to 6m in sunlight)
http://www.teraranger.com/wp-content/uploads/2016/01/TeraRanger-One-Specification-Sheet1.pdf

7

That is what I suspected, so from the log data it looks like it’s only really reliable to 3m, so I’ve adjusted: RNGFND_MAX_CM from 1400 to 300. Will be test flying in a few hours, however what’s concerning is the fact that when the TeraRangerOne failed it didn’t transition nicely at all to the barometer. If was for a quick action to change out of altitude controlled mode and into stabilize it would have taken a nice digger.

Any idea why with a failing range of the lidar the altitude in the HUD would ready >20m above ground after we’ve landed in the same location (only a 3min flight, so no significant air pressure change).

8

Unless I am wrong , this issue does not seem to be related to the EKF2 bad behavior. You can open a new discussion with a log file. I see @tiffo added info to this opened issue https://github.com/ArduPilot/ardupilot/issues/7119

9

There is a real bug with Range Finders operating Outdoor, no problem for those using it only in a garage. What is annoying, is that they are convinced that this is always the lambda user fault, and have difficulty to admit there is a bug. I appreciate Ardupilot and all the efforts that the development team is doing, but they should be happy that users report bugs, but there is something like a taboo with this. They have a free sandbox each user accepts to take some risks playing with parameters, and sometimes it costs money for users, so the only thing I ask is to have a reliable Failsafe management. If the drone is able to Fly Away without a known reason, they should take the decision to suppress a functionality that has not be fully tested…

10

Personally , I never had any difficulties to get dev support if the problem is well identified and the root cause is pointing to code. Its better in that case to open an issue on github with the right information and supporting evidences, like log or else.

@chris661 Just to let you know that garage experiments are great for testing for non GPS flight system, the sensors can be indoor type or outdoor type. The experimenter has the responsibility to check for specs and validate experimentally if the sensor he choose can accomplish the mission within the parameters defined in the specific environment. For example I am flying the OpticalFlow setup outdoor using a LidarLite V3 that can read no problem up to 40 Meter, using the EK3 and set RangeFinder as the main altitude sensor and its doing terrain following like a charm.

11

I respect all the tests you’re doing in your garage, I’ve posted issues in GitHub about the subject, the issue has been closed and re-opened. I post my bin log in the forum, nobody from development gave me an answer. I even told you some weeks ago about this fly away problems, never get a valid answer. Now I can see in the forum some users describing the same kind of problem, but no, you still think the Ardupilot is perfect and error free… How could you accept that a Fly Away could occur and the drone fly outside the Geofence limits? It’s like accepting driving in a car without brakes…

12

@ppoirier FYI Follow terrain with range sensor Error Failsafe TERRAIN-1

13

@ppoirier FYI RTL causes Fly Away with range sensor I2C Maxbotix - safety warning

14

@chris661 I will test with same parameters and report. May take a while though, its still snowing here :wink:

15

thanks Patrick, but be careful! We also had very cold weather there end February, - 25°, now seems better. I’m a little bit too “sharp” in my comments, but just try to improve the way to report bugs that seems to me important regarding safety , I’ve tried with issues, but I think there should be a possibility to set the priority (low high) from user side, and then, the "development team management " (or something…) could prioritize this. A kind of issue management workflow.

16

you will have to wait until the battery failsafe is auto triggered, and attach the drone :wink:

17

hi, still snowing? here it’s Spring time now!

18

We ran into this same issue with Copter 3.6.0 and Rangefinder EVO 60m sensor.

We completed two waypoint flights - first without EVO sensor, and second one with EVO. Attached Pixhawk data logs of both flights. Times (for example :33s) mentioned are timestamps on the flights logs.

Both times we takeoff to 40m altitude, fly short waypoint mission and on last waypoint descend to 7m and then ascend back 40m and do this twice and then do RTL. On our first flight (without EVO, using barometer for altitude estimations) everything went smoothly - our drone flies at around 43 meter altitude and acts normally. It starts to descend to loiter point (:33s), goes from 40m to 10m altitude (:82-:92sec) at the speed of 1.25m/s, stays at 7m altitude for 15 seconds and then heads to next round, does that and returns to launch normally.

With EVO sensor we planned to do two rounds like previously. Drone flies little higher (45m, because of sensor?). Drone starts the descend from 40m to 7m (:43s) instead of landing at smooth speed it comes down at 7m/s. After that pilot sets the controller mode to LOITER to take manual control of the UAV. Even after that the drone doesn’t respond normally, there is some kind of latency in throttle so it seems like the rangefinder also causes issues on the manual flight mode (LOITER). It was pure luck that during this flight the UAV survived and didn’t crash to the ground.

We first asked from the sensor manufacturer (Terabee) about this problem, and their answer:

Thanks to you, we have had the chance to look deeper into what’s happened during your flight and found that the issue is with the APM control loop for the use of rangefinders as altimeters. What is happening is that, when the sensor doesn’t send a distance data, the system should switch to rely on the barometer for altitude hold, but it appears that it doesn’t correctly execute this transition.

It is the first time that one of our customer reports such issue and this transition used to work well. What I would recommend though at this point in time is that you post your in-flight data on ardupilot for the community to jump on it asap.

From the google drive link (https://drive.google.com/drive/folders/1YnXkkwQ3BTuOP-n6dDjav6STAL44UilH?usp=sharing) you can find following files:

00000080+Barometer.BIN - pixhawk flight logs from the flight without EVO sensor
00000081+RangeFinder.BIN - pixhawk flight logs from the flight with EVO sensor
20181119 Avartek+RNGFND.param - pixhawk parameters during the EVO flight
Avartek Pohjoinen+Loiter_Time.waypoints - mission waypoints

1 Like
19

@eeroniemi
That’s very concerning and makes automated flights extremely stressful…
I am working on a somewhat similar setup and was wondering if you have since been able to resolve/ manage this problem?

20

I strongly suggest you read the wiki, as the usage of rangefinder as primary altitude estimator is restricted to specific use cases (read Indoor on flat surfaces):
http://ardupilot.org/copter/docs/common-apm-navigation-extended-kalman-filter-overview.html

EK2_ALT_SOURCE which sensor to use as the primary altitude source

  • 0 : use barometer (default)
  • 1 : use range finder. Do not use this option unless the vehicle is being flown indoors where the ground is flat . For terrain following please see copter and plane specific terrain following instructions) which do not require changing this parameter
  • 2 : use GPS. Useful when GPS quality is very good and barometer drift could be a problem. For example if the vehicle will perform long distance missions with altitude changes of >100m.

Personally I am using rangefinder outdoor as primary but I know how to react if something goes wrong, and switching to manual is essential. BTW loiter is NOT manual, generally I use stabilize , making sure I kick the throttle to appropriate power level before switching to this mode.