Deleted - unproductive thread

deleted - unproductive thread

Are you aware what is the current status of Amazon Prime Air?

deleted - unproductive thread

deleted - unproductive thread

For a start, good topic and I look forward to it continuing, but,
you are using and old APM board and should really upgrade to a later pixhawk with the latest code.
You will find the performance, especially at this end of the precision scale, to be very different.

The GPS values you talked about would be a ‘no fly’ situation for todays craft.
HDOP is not a bad measure but its not the only one used in todays Audupilot.
The EKF has to be happy with the values AND the velocities before it settles.

An M8N UBlox has very different performance characteristics than the (probably v6) GPS attached to an APM 8bit board.
So an upgrade there will yield much better results.

deleted - unproductive thread

For a Rangefinder your choice is Analog Sonar with the APM and AC3.2.1 you are using and the performance of those units is very poor. You can go back to 2014 or so on the old forum for some info on those units from Maxbotix.

You’re asking for debugging support on firmware that’s more than 5 years out of date.
If your problems indicate a bug in that firmware, it might well have been fixed in a newer version of the code, so the first thing to try is updating to the latest release.

It should also be moved to the Arducopter 3.2 thread…

For example, this question, “If I can be advised that only the barometric altimeter is used for Auto missions” The anaswer to that in AC 4.0 does not apply to AC3.2.1 so why ask it here?

deleted - unproductive thread

The current EKF code fuses GPS, barometer and accelerometer data to estimate altitude.
This page indicates that it’s a lot different from whatever was implemented on APM hardware: https://ardupilot.org/dev/docs/extended-kalman-filter.html#overview

Precision height, I understand your question, and please don’t get frustrated with us pointing out the age of the gear you’re using.
The APM 2.5 is a good board and I still have a few around, and I had tried to get sonar working since APM 1.4 as well as the 2.5 without success I am sorry to say.
The code was much simpler than todays code, and the x/y accuracy was good, depending on what sort of a GPS day you were having.
Z accuracy, as you are finding out, is a lot more complicated.
And this, as well as other enhancements, was a driver in getting more processing power (32bit chips) and more involved code (EKF amongst other changes).

Now we get to vertical elevation precision in common software.
Google Earth as your finding out, has varying accuracy from pretty good to not even close.
There are ways of importing your own DEM (digital elevation Model) into Mission Planner as covered in the Wiki pages.
Where you get that DEM from and how you get it will determine the final vertical accuracy of your mission.

Sensors are the final word so your copter can see the ground coming.
Sonar as a downward looking sensor never really worked adequately as it is too easily disturbed by the prop wash, of which we have an abundance.
The advent of affordable lidar has improved this and I am sure there are discussions on here regarding implementation that would be of assistance. These have serial interfaces, amongst others, which might connect to the APM successfully.

So what you are asking about is the enhancement of accuracy in Mission Planner which in itself relies on the accuracy of the DEM used by Mission Planner and the implementation of your own more accurate DEM.
Is this about right?

1 Like

deleted - unproductive thread

What about going to the site (or using your friend) to get the exact GPS coords of the landing site using a phone, and sticking that in the mission as the landing point?
And try the “View KML” (over on the right side) button in MissionPlanner - this should give you an idea of the expected path against the terrain.
Setting up the mission, do you have the “Verify Height” option selected?

deleted - unproductive thread