I’ve been increasing flight duration and can see a growing error in home altitude after (auto) landing, fortunately I have lidar.
However my last flight of 105 minutes resulted in a altitude error of 20 meters and I had to land manually.
This is of course due to ambient pressure changes in the weather. I can think of two possible solutions:
Set APM to be more biast towards GPS altitude, it looks like the GPS is more accurate in determining altitude as soon as 20 minutes into the flight. Can someone confirm that POS.Alt is the correct log value to look at to see GPS Altitude?
Send a new ground pressure value via MAVLINK to calibrate it in real time. I think the best method is to set the GND_ALT_OFFSET parameter while in flight, but this needs to happen frequently, otherwise the EKF might reject the alt as noise, if I understand from github.com/diydrones/ardupilot/issues/1586. In it, Tridge mentioned “I’ve tested the EKF reponse to GND_ALT_OFFSET and it does work, but the response is slow, not sudden like with DCM.” What is the DCM he is referring to? Is it a better way to keep altitude accurate?
DCM has been replaced by EKF. A slow response is ok for your needs. Just send the correction up before you start your approach.
My iPhone 6 has a built in baro that seems quite accurate. There are many apps that track the baro, graph it, and show delta alt from when you started. You could use this to see how much the ambient pressure has changed over time. Another possibility it to edit your LAND WP to have an alt other than zero.
This is brought up in a few issues on the Ardupilot Github.
If you have a LIDAR I don’t understand why you had to abort an auto landing as the baro won’t be used once the lidar is turned on.
I put in a request for Tower to use the baro on a phone and conduct a calibration to give us the correct offset numbers to put into “GND_ALT_OFFSET” but, as of right now you have to do it very gradually as a large change in GND_ALT_OFFSET can cause the EKF to go crazy and ignore the baro thinking there is an error.
You can set your land altitude different, but, you won’t know what the offset is until after it lands, so that is difficult to predict accurately.
DCM is the old attitude heading reference system. It has since been replaced by the EKF.
Also, if using a tracking antenna with another APM, I believe it automatically updates baro offsets, or if not yet it will soon.
You can use a spare APM for getting the correct offsets as well, hopefully they add the calibration to the app soon so we can just pull it whenever needed and slowly change the offsets before landing.
As of right now, the best solution is LIDAR range finder. But you stated you have one so I don’t understand how you had an issue with landing?
Thanks both of you for replying and clearing up the DCM question.
@iskess, that’s great, I’ve resigned to use a second APM on the ground - my androids don’t have barometers!
@Jman841, I’ve read through the issues I could find, but wasn’t sure about particular versions. The LIDAR works great with small offsets, say less than 10m. The problem is the LIDAR is only good for up to 40m and also is only practical to use on the last 200m or so - very few runways are completely flat more than 200m away - there are invariably trees, hills, gulleys, buildings leading up to it.
If my last waypoint altitude is before landing is 40m and we’re out by 20m, or even more, APM has to make a major change right at the time it’s supposed to start to settle in on it’s landing glide slope. It manifests in a sharp, full throttle climb and by the time it’s at the target altitude, it’s too close to the runway to lose the excess altitude.
It’s also very nerve wrecking - the last turn before landing approach is supposed to be 60m, trees can easily reach 15m hight, add a slight hill and a loss in altitude on a downwind turn and I’ve had to urgently take over control of the sticks or else multiple thousands of dollars are distributed on cow manure!
I plan to update the GND_ALT_OFFSET every 30 minutes. This should be a maximum of 5 meters I hope - do you think that is too much for the EKF?
Why don’t they write code to update the barometric pressure periodically using GPS altitude? Seams like that would be a simple solution. Just sample GPS altitude for a period of time like a minute or more to get a good reading. When I look at GPS altitude plot it looks very steady.
Make it an option that you can turn on or off. Also make the GPS sample time a parameter.
RC Mike, I think the problem is sometimes the GPS can glitch an with some versions of GPS and options I don’t think Z is available even. It’d be nice if the developers can support a 3DR branded USB based barometer to automatically keep the aircraft’s alt offset correct.
I have another Issue in with Mission planner to display GPS altitude so you can use it for corrections in area’s that have good Z value inputs. I’m not sure why mission planner doesnt display GPS altitude, but, if added it could be another fix.
The issue with doing it automatically is some places in the world (I believe thailand was mentioned) GPS altitude can be over 100m off and if the plane tried to automatically correct for this, it could cause a serious crash.
The exception to this, and I believe they have a way to use only GPS data for elevation or using GPS as the primary is RTK. With new RTK sensors becoming available at low cost, it is by far the most accurate way to get altitude and much more reliable than standard GPS and baro pressure.
That makes sense about issues with the LIDAR. I am a bit concerned about a few tree’s we have before our runway when using LIDAR for landing as it may cause a pitch bump right before the landing sequence.
The best solution IMHO is using a ground baro that gives you the offsets continuously and you can slowly change them, or, if using a tracking antenna, have it continuously update the air vehicle as it can continuously calculate the baro offsets.
I hope the devs correct the issue with large changes causing EKF issues so we can make large changes smoothly.
I believe 5 meter increments would be ok, but, testing would need to be done to verify. I wouldn’t go much over that however.
Hopefully after 30 min the changes won’t be very drastic.
I just plugged in a spare pixhawk to look at the altitude offset numbers and find “Alt error” and “Bar error” to display the offsets.
Which parameter are you guys using to make your corrections during flight? Just compare the Alt Error or Bar Error of the calibrated pixhawk to the one in the air and use the difference as the ground altitude adjustment?
I’ve done ground test yesterday, letting a spare APM drift until it’s 16m over, then I input -16 to GND_ALT_OFFSET and wrote the parameters, according to planner, the altitude went to 0 again, which is correct. I didn’t see any problems with EKF filtering. I’ll try in the air sometime next week - bad storms currently.
How are you going to measure drift on the ground side? Just calibrate two APM’s at the same time and adjust for the drift?
Or will you use the altitude error and baro error parameters and recalibrate to see the differences between the flight controller and the ground controller?
If you use a spare Pixhawk to obtain the ground baro value , how can you connect two Pixhawk at the same time with MP or do you connect to ground Pixhawk, read baro offset, close, connect to flying Pixhawk and upload the offset ?