From time to time the terrain clamping warning pops up. It typically clears - so isn’t an issue.
I can’t find anything in the wiki that explains exactly what is “Terrain Clamping?”
I know that a terrain model is (or can be) loaded by the firmware so that terrain information is available to the autopilot. The terrain clamping warning seems to be involved with this.
From this post - there seems to be a known bug about this - that is still open:
The bug title refers to non-gps navigation - and a ModalAI camera is mentioned - but I’ve gotten this warning with a normal Orange Cube and Here3 gps.
Just for general information, could someone please explain what “terrain clamping” is - and what the warning is saying is going wrong.
AP has a built in assumption that the vehicle is taking off from 0m above terrain (i.e. it is on the ground) so if the altitude according to the GPS+baro does not agree with the terrain database, we shift the terrain database altitude up (or down) to match the vehicle’s current GPS+Baro alt (at the moment it takes off).
There’s a sanity check though that it doesn’t shift the terrain altitude up or down too much though and if it does it displays this warning. It is possible to increase the amount that it will shift the terrain altitude which will make the warning go away by increasing TERRAIN_OFS_MAX. The current limit is 15m which I have always thought this is too strict and it should probably be increased to 25m.
The “clamping” message could be a serious issue if the vehicle flies a mission with waypoints using terrain altitudes because the vehicle could fly too high or too low.
The issue linked re Non-GPS navigation is really only for users of one of the Non-GPS solutions.
If there were a parameter to notify the AP that takeoff is not at ground level, then there probably ought to be something to indicate the planned landing is not at ground level either.
I’m trying to remember - If you use a Lidar rangefinder, (I’ve used a Lightware LW20/C) - isn’t it possible to use the rangefinder input to control landing distances?
It’s not stated explicitly here - but I get the impression from this wiki page that perhaps the AP already uses rangefinder input for landing.
If I understand correctly you can let ArduPilot know the landing altitude in a mission though I am not sure if it works for rally points.
PS there is no guarantee that the next takeoff happens at landing location and altitude so differentiating between ground and object landing shouldn’t be needed. Maybe except plane with downwards rangefinder where it would indicate that the drone should likely reject rangefinder data. (Except when overflying the landing spot).
Yes, when landing (in Land mode or the final stage of RTL) the vehicle will slow to LAND_SPEED if the rangefinder reports that the vehicle is within 10m of the ground.
I think you could essentially do the same thing by setting TERRAIN_OFS_MAX to zero. The terrain’s altitude would then stay at whatever the terrain database reports.
Joe commented on my behalf after I experienced this terrain clamping issue, prohibiting my takeoff on two different occasions, with two nearly identical drones.
The second time I had this issue, you had already commented and I thought your parameter suggestion would fix this issue if I encountered it again. I set TERRAIN_OFS_MAX to zero, rebooted, and was still prohibited from takeoff with the same error. I also tried setting the value to 25 based off your previous comment, also to no avail.
Do you have any other suggestions to workaround this issue prohibiting takeoff? I would like to learn more about terrain clamping, understand why it is needed, and how we can disable it if need be, as one of these two issues is effecting one of our demo drones and another is effecting a customer’s drone.
Let me know what other information you think would be helpful to review.
The terrain clamping should not actually prohibit arming so I think maybe another error is be displayed? If you could post an onboard log that would help. It will probably be necessary to set LOG_DISARMED = 1 to produce a log before the vehicle is armed.
You are correct, thank you. We are all set now as one of our engineers figured out an intern plugged in our PWM breakout into the FMU instead of the I/O and I did not notice previously.
how to identify what value to be changed when terrain clamping error is there, i am using a terrain radar and this clamping error comes at 10 m then 15 m standard value at parameter and when i did 3 m it was not there i have to do more flight test to see if this clamping offsets comes or not, but my question is how to calculate this limits in meter that it should 10 15 or whatever, and why does this error come at first place, when i am getting all the satellites and baro meter is calibrated, using a pixhawk cube plus and neo 3 pro gps with terrain radar on my agri drone. i am not able to understand this clamping
If you use GNSS with good altitude information (aligned with SRTM reference or your DEM provider depending on which you use) and tend to operate from elevated platforms set it to 0 so terrain is clamped to where it really is.
On the other hand if you use baro for altitude reference and don’t take off from elevated platforms (more than 2-3m above or below the terrain) set it to a fairly large value so the drone assumes it takes off from the ground and aligns the DEM to its altitude reference.
Re-reading this thread, I was wondering if ArduPilot development has ever considered the ability to accept altimeter settings - like “real” airplanes.
I bet the FAA would like that…
And if a Terrain Clamping error came up when using local altimeter settings, there might be cause for concern.
Here in the USA, it’s pretty easy to get METAR data from a close by airport. But I’m sure there are parts of the world where this simply isn’t true.
Technically - if the topo data is accurate, the flight controller’s baro sensor should be used to determine the local altimeter setting. That’s how airport weather stations work - they look at the air pressure at a known altitude.
