Follow terrain with range sensor Error Failsafe TERRAIN-1

Hi, read different posts about this, but not find the answer.
Running Copter 3.5.5 Pixracer Quad config Maxbotix I2C range sensor, everything is running ok when I select Auto mission selecting Relative altitude.

But when I select Terrain option (without Verify Height box selected), I takeoff to maybe 10 meters, and then I launch the mission (as seen in a post problems with TAKEOFF). There the drone climbs up to the Geofence limit, I think, and then auto runs an RTL. The message I was able to see is always the BAD LIDAR health, and then I can see in the log:
Message: Restarting RTL= Terrain data missing
But it NEVER starts the Auto mission.
I have TERRAIN_ENABLE and TERRAIN_FOLLOW set to 1 in parameters.
I have TERRAIN_SPACING set to 50m as this is a very small parcel.
I do not have a Ground Station connected when I flight, as I’ve seen all datas.
My Sonar is facing downward and parameters setup. RNGFND MIN MAX 20 700.
I read in some topics that the data was loaded when the flight plan was created and Write WPs was clicked. Did I miss a point for loading altitude datas in the FC?

Hi Chris,

It sounds like the sonar’s range is only 7m? In that case you’ll only be able to run terrain following missions at that altitude or less. Sorry, we don’t currently support blending sonar and map-based terrain following so it’s one or the other. So if a sonar is attached it’ll try and use that but then the missions need to be really low (under 7m because of the range of this sonar). If no sonar is attached (or you just disable it with RNGFND_TYPE = 0) then it’ll use the map-based terrain data and you can run much higher terrain following missions.


hi, thanks for the accurate explanation, understand better now. yes the max sonar distance is supposed to be 7 meters. but in my test flight, I set the Altitude to 5 meters so maybe this is a problem with the range sensor. I will do more testing at 4 or 3 meters, and give you my feedback. if you need full log, just ask. A nice day, Chris

hi, reading again the documentation, I can see:
Verify height means that the Mission Planner will use Google Earth topology data to adjust your desired altitude at each waypoint to reflect the height of the ground beneath. So if your waypoint is on a hill, if this option is selected the Mission Planner will increase your ALT setting by the height of the hill. This is a good way to make sure you don’t crash into mountains!
Isn’t this check box Verify Height redundant with Terrain (Combo list)?
So for me a Flight Plan with Relative selected AND Check Box Verify Height would have the same result as Terrain WITHOUT Verify Height selected. And what will be the result with both Terrain and Verify Height selected?
I think the documentation should be updated there:
Thanks, Chris

ok, after some tests, I find that terrain datas are not loaded when you upload a mission, but only when GPS is locked, that’s causes my error data terrrain missing. I think it would be a better choice to upload terrrain datas the same time you upload the mission. I plan the missions from home usualy. It’s sometimes not possible in some areas to use ground station connected to the FC. Is this possible to modify this on future relesase?

hi, there is a real bug when a range finder is activated, even with terrain following non activated. I was flying to test the range finder flying over a little obstacle to see if altitude was adapted, it was ok, but at the end, battery failsafe, the drone flight up and never stopped, far away from failsafe max alt. I put 250 to the max range distance… I really think this should never happen, what are failsafe for??? if they do not work like they should??? ! Sorry but it’s very frustrating to see a fly away in RTL because the only thing you can do is watching…

Will definitely stop reporting bugs anymore…

HI Chris reading all the thread I would just recommend changing the sonar for lidar rangefinder, as sonar is not reliable and from my own expricence with them and also looking at what the Devs are doing in code in Github its not really in the roadmap for new development, hence sonar has to many problems when compared to a cheap lidar rangefinder like the TFMINI . Also take a look at the Mission planner docs as it works in meters not feet as you mention that the geofance on your copter was set to 250 . And Mission Planner specs for are in Meters so setting a geofence to 250 would be 820 feet . So the description of the copter flyaway sound more like it never hit the geofence limit of 250m. Anyhow sad to see the crash of the quad we have all had them but hey rebuild the quad , and fly again .


Hi,first thanks for the answer. Just a point, you’re talking about feet, I use cm like in the description of parameters: RNGFND_MAX_CM: Rangefinder maximum distance. So for me 250 means 2.5 meters. Maybe I was not precise enough (because I said MAX DISTANCE) in my description, sorry. My geofence limit is set to 30 meters, so for me a geofence limit should never be transgressed.
Now you’re totally right, this is a very inexpensive sensor and for me should be used only for in room flights, but never outside, as we can see in the wiki
… but which has been successfully used outdoors on Copter……
This is a SAFETY bug that has been closed by @rmackay9

And just reopend 2 minutes ago (strange!)
This is an OLD issue date August 2016 that has been reported and reported.
I know these people are working hard and are very experimented in their area, but they have priorities that had been set by their partners… like @rmackay9 says in his Roadmap 2018 / 2019 , they have Partners, and their priority is to be able to satisfy them…

So 2 points:

  1. basic people like me has learn to read wikis and a l related available information, but when these informations are not reliable, i kindly mention it, but when I have NO ANSWER from the team about SAFETY informations I provide, I “trigger the alarm” (bad traduction I guess).
  2. when FAILSAFE essential functions like RTL or GEOFENCE MAX ALT become unreliable, and devloppment people decide to close the issue, I just say: PAN PAN PAN (people who are also flying real planes will understand that…)

That is what we try to do, but it not as simple as saying : hey my alt is upper that the limit, it should stop…

There are different sonar and connexion, some will be successfull, other not … The wiki is open, feel free to add a correction if your version didn’t work.

We get 800 issues … some are true, some aren’t, some are due to misconfiguration, other by faulty material … We didn’t have that much report on that problem. We will look at it be it takes time…

Totally wrong … read again … We set a roadmap because users ask us … This roadmap is what developpers want to do, sometimes it is also link with some partners developpement, but those are separated … Most of dev contribute on their free time and with no other pay than fun and reward by other user happiness …

Issue from 2016 … Failsafe aren’t unreliable, but as all software we aren’t bug free unfortunaly. Moreover the wiki is open to everybody to update it. Everybody in the dev team is trying to do it, but yes it is sometime outdated. And of course we cannot answer everybody …

first thanks for the answer. I understand your point of view. For the point I’ve just quoted, I think it’s important to minimize the probability that could happen, no? So I think it’s important to report bugs… I use a small lite drone for testing, before validating my config, and then configure the larger cam drone to fly “in safety” but I think improving the code to have a RTL working 100% should be set as priority. How can I help?


Sorry, I forget to answer you … I will try to make a blog post on how to report issue and start investigating the cause.
It seems that I have finally manage to reproduce a part of the bug with the RTL function … I am working on a patch

1 Like

hi, happy to hear that! keep me posted. I have seen a post where someone has a similar problem when Landing mode was activated. Thanks, Chris


Indeed even if I cannot determine if it is the same causes that leads to the same results but the point is reported here

However if a patch has to be made, let it have the best coverage possible.


Looks like the bug I found was just loading a wrong param file … So I get back digging out the problem…

Will it help if I give you my last param file? Or everyting is already in the log.PixracerRTLCrash.param (13.2 KB)