Servers by jDrones

Tera Ranger Evo 60m driver issue

Hi

I have some issue with the TeraRanger Evo 60m in 4.0.7 (bad lidar health despite TERRAIN_ENABLE set to 0). So I thought I will do a test with 4.1 beta to find out how it behaves with this firmware version. It seems that the driver has bug, still with 4.1 beta.

The TeraRanger Evo 60 is not able to read distances under 50cm (to my experience is a little more, around 80cm, related to the ground and sunlight). If I lift up the drone smoothly to 2 meters, the are are spikes up to 60 meters visible (max. reading distance).

Is this behavior normal?

Many thanks in advance

Michael

here is the log:https://1drv.ms/u/s!AunrEY0aDm-h4i9v8cdMDVNIObSv?e=rnZfln

Hi, thanks for the report, I’ve added it to our 4.1.0 issues list so it won’t be forgotten. I’ll ask around tomorrow in the dev meeting if any of the devs have one of these so we can try and reproduce.

Hi, I’m the one to blame for the spikes on 4.1 (changes and reasons described here)

In my personal experience with the TeraRanger sensors, they don’t have the precision to read with high accuracy under 50cm because their infrared beam is quite diffuse. They report an “unable to measure” flag when the distance is unreadable (different from being “too close”), which is currently handled in 4.1 by returning an out_of_range_high value (i.e. 60m + 1m, which is the distance displayed in the log above). Actually, from the log the status of the rangefinder is correctly updated when those peaks are shown. Before 4.1, the reading was simply not handled, so it was normal for a log to not display anything without any measurement. This is how the Benewake driver operates as well if I’m not mistaken. I haven’t looked much in the Terrain library, but it should report a “Terrain Unhealthy” status when processing this too high reading.

@rmackay9, as explained I am able to reproduce the peaks (61m) when the sensor fails to read the distance, and mainly, the rangefinder status is correctly updated. While I think the behavior is correct at the moment, displaying these spikes may not be appropriate, especially for log analysis… In any case, I do not perceive any steps when I slowly move the sensor away from an obstacle as @buckker sees them, so this might be the main problem here (Although it’s very dependent on the surface pointed by the beam). I intend to use a TeraRanger for terrain following in the upcoming weeks, so I can manage some tests if you like.

1 Like

Thanks Randy and Pierre-Yves

How does copter 4.1 handle the out of range case during automatic take off in Auto Mission? With the last firmware releases I was not able to take off in Auto Mission due the “bad lidar health” message . The workaround was to start in Loiter and climb a few meters where the sensor is able to read reliable. This issue was not only present with the TeraRanger Evo 60m, also with the Lightware LW20, especially in very strong sunlight environment.

Hi

I was able to do some test flights this morning. As I mentioned before, the underground makes a big difference. I did a test with a copter 4.0.7 equipped quad. If I placed the drone on the field, no bad lidar health message appears:

If I place the quad on the road, the bad lidar health message appears suddenly, and the motors stops after switching from Loiter to Auto:

With 4.1 the behavior is the same, I got the message, Failsafe: Missing Terrain Data. If I like to fly a Auto Mission with rangefinder, I have to start in Loiter and climb a few meters.

I I look a the rangefinder signal, It looks surprisingly not bad:

It seems that a closer look to the library will be necessary .

Let me know If I can support you with further tests to investigate this issue.

log file: https://1drv.ms/u/s!AunrEY0aDm-h4nspXjfDsWg1D5Hy?e=Rgbc4u

@rmackay9 Any news from the dev meeting?

Yes, @hwurzburg also has one of these Lidar so I hope to enlist his help in testing to hopefully improve the situation.

I will be back in town Tuesday, it will take me a few days to hook up mine to a quad and get some logs

1 Like

Have a look at the statement from the TeraBee support:

1 Like

@PY_BRULIN, @buckker

So I guess the change in Copter-4.1 vs 4.0 is that previously the lidar would have reported unhealthy but now it will report out-of-range. I wouldn’t expect this to cause a change in behaviour though because neither is acceptable for terrain following… and I guess this is what @buckker is saying… it is not working well in 4.0.7 and it is still not working in 4.1.

Maybe this lidar just doesn’t work very well outdoors and all we can do is add a note to the wiki… I don’t think we have a bug in the driver (I’m very happy to be corrected on this though)… I think we’re just dealing with a lidar that doesn’t work well outdoors. We can’t do terrain following without a good distance measurement…

@rmackay9 Indeed, and that is why we have used it as a proximity sensor in our recent projects (hence the PR), rather than for surface tracking in automatic missions. The loss of measurement beyond a certain distance threshold on some surfaces is still relatively sufficient for object avoidance.

Adding a note to the wiki sounds appropriate, and a reference to the test report done by TeraBee could also be a nice addition for more transparency. I think this sensor is perfect for an indoor application but suffers a bit too much from the conditions of an outdoor environment.

That being said (sorry I’m getting too far off topic, however @buckker mentionned this as well), I feel like an underlying problem here is the inability to automatically take off if the rangefinder returns anything other than a “good” status. (see sensors.cpp#L51). I’m just throwing out an idea here : maybe the “out_of_range_low” status should also allow for automatic takeoff? Obviously, we want the measurement to be as reliable as possible from a rangefinder, but speaking only of the case where the sensor is at the PITCH270 orientation facing the ground, maybe it could be considered as a kind of ground clearance? Although, on second thought, I don’t think all rangefinders drivers supported today allow for this state handling, so it might not be possible at all when looking at the big picture…

I think the problem is the lidar sensor health check at the ground. If the sensor is unhealthy at this time, the copter wan’t takeoff in Auto Mission. Why we don’t check if the sensor is healthy at the reached takeoff height? If the sensor is not healthy at this time, the copter goes to the missing terrain data failsafe state. Could this maybe the solution?
My suggestion is not only TeraRanger related, I would also help with other sensors (Lightware LW20, Benewake TF03, TF02…)

@rmackay9 as requested here is some 4.1beta data…put the evo60 on an ArduCopter and flew over an asphalt road bordered by tall grass and some boulders…observations:

  1. got no unhealthy GCS messages when out of range low on the ground…did not try arming in AUTO though…but no pre-arms when out of range low
  2. tracked baro/ground well at low altitude either over pavement or tall grass and weeds
  3. above 8m in bright daylight it seems to fail and report out of range max

in loiter no sudden or anomalous behavior noted as AP switched from baro to RF and back smoothly…
overall would not consider this a 60m altimeter for outdoor use…rather a 7-8m one…performance wise, the simple TFLuna seemed to work as well at 8m and below…


if there are other tests you would like done, let me know, or if additions to wiki are needed…

1 Like

@hwurzburg,

Great thanks very much for the testing. I’m surprised that the range is reduced so much outdoors but then again I hadn’t realised that this was an infra-red based rangefinder.

I’ve changed the wording on the wiki to be like below but if you think I’m being too strict or whatever feel free to change it of course.

The TeraBee EVO family of rangefinders are lightweight distance measurement sensors based on infrared Time-of-Flight (TOF) technology. They are much faster than ultrasound and smaller, lighter and require less power than laser-based lidar but also have a shorter outdoor range.

Note: Feedback from users and developers indicates the manufacturer’s range estimates are probably based on indoor use. If used outdoors (especially with bright sunlight) the actual range is much shorter. For example the Evo 60’s reliable outdoor range may be less than 10m.

Servers by jDrones