Today I tried to fly a short mission with my self-build GPS RTK Arducopter. As soon as
I switched into the AUTO Mode, the Copter rose more than the specified takeoff
height of 2 m. It rose to about 7m (I switched to LAND mode because I don’t know
how high it wanted to go and feared losing control of my copter).
Similar Missions have worked fine before and therefore I am very confused. I have tried
it twice with all Waypoints having a relative height reference and once with all
having terrain as reference. Nothing changed and I always stopped the mission
to prevent any unwanted behavior.
I have a rangefinder and WPNAV_RFND_USE = 1, and an active RTK GPS (GPS: RTK Fix) so I would assume that the copter could achieve the wanted altitude easily.
I had a look at the messages tab and the log but didn’t see anything interesting.
If you have any ideas on why that happened or how I can achieve accurate height control I
would be really happy. log
Thanks for taking a look yourself before posting. I’m also taking a look.
In your log, I see 3 takeoffs which travel >5m as you describe.
The first thing I notice is that the controller’s RelHomeAlt and RelOriginAlt are -56 m. That’s suspiciously close to the difference reported in the message Terrain: clamping offset -87 to -30. Did you notice that message when you looked?
My hypothesis: some sort of -87m terrain offset exists, but that’s clamped instead to -30 m, meaning copter “starts underground 57 m”. If its attempting to rise to 2 m but starting from -57 m, it’s going to fly up 59 m! (Good thing you were alert and stopped it.)
Frist of all I want to thank you for also taking a look.
I have to admit, that I missed the “Terrain: clamping offset -87 to -30” message completely and due to being relatively new to Ardupilot the RelHomeAlt and RelOriginAlt being -56 m didn’t concern me much.
Your hypothesis seems logical, but I wonder how something like this could happen.
I have now taken another look at the log and compared different altitude measurements and estimates. However, I don’t know how most of them are captured or calculated so that didn’t quite help. But one thing I noticed is the difference between the BARO[0] AltAMSL (~150 m) and the GPS[0].Alt (~100 m) which is about 50 meters. Nevertheless, I don’t know why it was like this and if this huge difference is normal.
I also compared it with a log from another day where I flew (and completed) a similar mission multiple times (same location).
That day, I also got the “Terrain: clamping offset -87 to -30” message (by the way I don’t know what it actually means) and RelOriginAlt was also negative (~ -80m) but RelHomeAlt was not identical (it was ~ 0m).
(I just found out now, that you could see the MavLink text messages from a log in the online UAV log viewer.)
The maximum adjustment of terrain altitude based on the assumption that the vehicle is on the ground when it is armed. When the vehicle is armed the location of the vehicle is recorded, and when terrain data is available for that location a height adjustment for terrain data is calculated that aligns the terrain height at that location with the altitude recorded at arming. This height adjustment is applied to all terrain data. This parameter clamps the amount of adjustment. A value of zero disables the use of terrain height adjustment.
I think I have now found the cause of the Problem. Due to an error in my Rasberry Pi RTK Base program, the wrong height was saved after the survey-in. Because of this, I had an offset of around 45 meters. After fixing this, the mission worked as well as before.
