trying to use terrain following in missions, I think that it could be enhanced (or maybe I did not understand everything). I use a downward facing Lidar and when it is out of range, the mission goes into Failsafe if the next waypoint is of type Terrain (I mix relative and terrain waypoints in my missions which is maybe not recommended). Why not using SRTM as a backup as long as the Lidar is out of range and switch back to Lidar as soon as it recovers good distance measures ?
My second question is regarding Terrain waypoint behavior : when my copter comes from relative altitude waypoints, it has a strange behavior at the last relative alt waypoint before the terrain waypoint : It stops and turn around at this relative waypoint before going back to the next waypoint which is the Terrain one. I don’t understand why the goes did not just follow the mission path.
In this example, 10 is a relative alt waypoint at 8m and 11 is a Terrain waypoint at 5m:
You can clearly view the back turn on 10 instead of continuing normally to 11. Maybe is it because I use Spline waypoints ? The Plan looks like that at this point:
Thanks for any help on understanding that.
Thanks for the report. Any chance you have an onboard log we could look at? This should hopefully help us reproduce the issue. The use of spline waypoints is definitely related to the issue.
Re mixing rangefinder and SRTM data it is on the to-do list but it is not as easy as it seems because the two altitudes are really quite different because a rangefinder sees obstacles on the ground (rocks, house, trees) while the SRTM data has an overall average of the ground’s altitude (above sea-level).
See this: insert a relative waypoint before the terrain waypoint with same lat/lon and a height within rangefinder range, safe for barometer control (may be down to 2-3m), editing the waypoints file.
Thanks Webillo. To be honnest I did not understood everything in this Video and did not find a way to interpret it in order to solve my problem Anyway, I will try your advice of inserting a relative waypoint at the position of the terrain waypoint to see how it behave.
This is a capture on SITL simulation from link above, transitioning vertically from relative/2m to terrain/1m (red). On the real thing the same happens.
This is expected behaviour when you end a spline with a pause or a change from relative to terrain. Both of these cases define the final spline waypoint without a approach vector. Therefore the direction the aircraft will approach the final spline waypoint will depend on the spacing and locations of the previous waypoints.
If you want to specify the direction the aircraft approaches the spline waypoint then you need to have another normal waypoint after that is the same altitude type.
However, in trying to generate a graph to demonstrate this I think I have found something we are not doing correctly though these interfaces that needs to be fixed…
Thanks for pointing this out. While this is expected behaviour it has highlighted another issue.
His thanks a lot guys, it becomes more understandable to me now. I will try this asap but if you don’t mind, can I ask if there is something on the roadmap to support “direct” or “straight transitioning” from vectored waypoint to “not vectored” ones without having to add “dummy” waypoint in between ? It is something hard to manage in mission planner plan tab. If you put 2 waypoints the exact same location then it becomes hard to select one or the other as they are overlapping. But I also know how spline management could be a complex mathematical thing so no worries if not.
That said, thanks again to all involved people on this amazing software
Randy and I created an issue to ensure we try and improve on this behaviour:
What do you mean? Do you mean spline and normal waypoints. If so, yes this should result in the spline waypoint connecting to the straight waypoint at a tangent.
If you mean terrain following and non-terrain following then no. We will need to have a stop when changing terrain altitude type to ensure we don’t run into terrain due to going to fast at the transition.
I have a mission with terrain WPs loaded.
I fly im Loiter-mode above the lidar range and switch to “Auto”.
But it is switching to RTL (failsave) instead, which is quite confusing.
It should refuse to change the flight mode in this case --> “Flight mode change failed”
@Rainfly If you could, upload a .bin log (dataflash) of the issue. You may have to use a file hosting service if this board software cant handle the upload.
@RainFly Something to try- It looks like the error happens when your RAD.RSSI is at its lowest point, I wonder if its unable to get enough terrain data from the groundstation? You could try generating the needed terrain data and putting it on the SD card https://ardupilot.org/copter/docs/terrain-following.html
My experience is that the system doesn’t “know” how to reach a terrain (rangefinder) waypoint from above rangefinder range (starting there, or from a relative waypoint above rangefinder range).
So, as said above, insert a relative waypoint with same lat/lon as that terrain waypoint, with altitude within rangefinder range, before that terrain waypoint. The system “thinks” during some instants and does the transition (this is clear in above video). Perhaps some developer can explain the system conditions for this to happen.
I am not sure if that trick always works, though. Anyhow, the message “Failsafe: terrain data missing” and subsequent RTL seems to come from some rangefinder problem. Terrain following or card data seems not related (the rangefinder is much more precise).
Anyhow, how can a mission mix relative and terrain waypoints in a different way?
I think the suggestion to fail to enter Auto is a good one so I’ve created an issue here. I can’t promise when we will get to this but it would be a good enhancement in any case.
I hate to revive an old thread, but it seems more efficient than to rehash all of the above - I have basically the same situation: transitions from Relative to Terrain frames require that the aircraft be within sensor range of the ground, or I will terrain failsafe RTL; if I fly above sensor range while in Terrain, same thing. Nothing new to add there.
However, I would like to highlight that using a Relative waypoint to walk the aircraft back into sensor range is a little precarious when using short-range sensors; combined with a flight worth of barometer drift, getting into ground proximity without actually hitting the ground can be hit-or-miss. I’d suggest that a Relative-to-Terrain transition behavior would seem to be a logical solution - basically “descend towards waypoint until rangefinder data is available OR waypoint altitude in Relative is reached”.
Tangentially related, it would be very nice to be able to specify a minimum safe AGL value, and have the rangefinder guard that in AUTO, even when the waypoint type is Relative, and/or pass back the traditional enunciator message (“TERRAIN, TERRAIN, PULL UP!”). Technically this would be vertical obstacle avoidance rather than terrain following, but it would certainly be useful for low-altitude operations in AUTO.
Either one of these seem like a possible stop-gap method to provide at least some of the functionality that Webillo et al. were discussing, without having to do the more complicated implementation of mixed rangefinder and SRTM data.
Yes, I agree, in general it works out, but every once in a while, I get just enough barometer drift to make that 3m turn into 1m, haha!
I just finished doing some preliminary testing on a Lua script I threw together as a proof-of-concept for automated transition; you still have two waypoints, but as you approach the Relative waypoint, the script is watching the rangefinder and looking one command ahead - when the rangefinder shows values approaching the next-waypoint Terrain altitude value, it executes a DO_JUMP to the Terrain waypoint. The script runs in the background, looking for Relative–>Terrain transitions between waypoints - from a flight planning standpoint, it’s pretty much invisible. It isn’t perfect (obviously, if you set the Relative waypoint too high, it will still failsafe), but it definitely works, and you don’t have to worry as much about CFIT due to barometer drift.
Anyway, I will try your advice of inserting a relative waypoint at the position of the terrain waypoint to see how it behave.