Copter 3.5.2 - EKF2 bad behavior with rangefinder enabled

ArduCopter Copter 3.5
, ,
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.

21

Thank you for the hints @ppoirier. Actually, I have read and re-read wiki, warning posts and description of the related parameters multiple times over the past few months and am right now brooding over those very parameters again, just before a maiden flight hopefully later this week…
I find the EK2 sensor fusioning a fairly complex subject, where a number of things are interacting in ways not always readily apparent to me (yet).

Since you seem more knowledgeable in this, may I briefly outline the use situation, and hopefully you could quickly guide in order to reach a solid setup - without 7m/s descents:

  • Copter flying outside
  • fitted with ToF (Terabee) rangefinder and
  • RTK GPS.
  • Waypoint/ automatic operation at very low level (3 - 0.3m AGL).
  • (some (few) stretches at higher altitude, i.e. when flying to area of operation, or on RTL (ca. 10-15m)).
  • Precision altitude control is needed to achieve accurate distance to (mostly only slightly) varying ground levels. This accuracy is only needed on the low descents, at each waypoint, higher portions of the flight do not have to be as accurate.
  • WPNAV speeds set very conservative (at first at least)
  • NO terrain data stored/ available
  • FW currently v. 3.5.7 - necessary/ recommended to upgrade?

Params seeming relevant are set as follows:
AHRS_EKF_TYPE = 2
EK2_ENABLE = 1
EK3_ENABLE = 0
EK2_IMU_MASK = 3 (IMU 1+2)
EK2_GPS_TYPE = 0 (3D velocity & 2D position)
FS_EKF_ACTION = 1 (Land)
EK2_RNG_USE_HGT = 70 (max)
EK2_RNG_USE_SPD = 2
EK2_ALT_M_NSE = 3
TERRAIN_FOLLOW = 0
TERRAIN_ENABLE = 0
RNGFND_MAX_CM = 500
(specs say can do 1400, reports say 500-700 has been tested in sunlight)

I hope the above is correct and suitable for my use case.
I am quite unclear with the following items:

  • WPNAV_RFND_USE = 1
  • EK2_POSNE_M_NSE = 0.1
  • EK2_ALT_SOURCE = 0 or 1??
    (0:Use Baro 1:Use Range Finder 2:Use GPS 3:Use Range Beacon)

In conjunction with EK2_ALT_SOURCE the error reports in https://github.com/ArduPilot/ardupilot/issues/7119#issuecomment-396112753 make me unsure: “If someone wants to use range finder all the time, then EKF_ALT_SOURCE = RangeFinder should be used, but not in combination with EKF2_RNG_US_HGT”

How do all those settings look like in your view - correct?
Your comments/ guidance toward changes, particularly to the last two items would be much appreciated to achieve safe, accurate and uneventful flights. Thank you!

22

Not knowing how the Terabee react when outside its operational range, I would need to check the logs. Please provide a log with a simple flight going from ground to 20-30 M and land.

23

Will do as soon as weather permits first flights.

1 Like
24

I have been able to do some test flights in the meantime, and with the correct settings the Terabee-fitted hexacopter seems to nicely translate across and past the rangefinders range.

(I do have the occasional Bad Lidar Health notice, and today had a RTL due to "Terrain data missing ", both of which I have not been able to eradicate yet. Unfortunately due to a multitude of flights, I lost overview which logs would contain relevant data. If I run into it again, I will see to note and post it.)

1 Like
25

@camti. I want to use all time range finder. So what will my parameter settings. Could you help me please???

26

Sorry, I am not familiar with the all time range finder, and am not sure that it is implemented? We