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.
