The other wrinkle to consider is that Ardupilot probably uses a flat
Earth coordinate system, with constant gravity acceleration and the
ground at z=0. Assumptions which are pretty good enough for a UAV.
A good coordinate system for a sub-orbital or orbital rocket would be
Earth Centered Inertial, which is Cartesian (x,y,z) with the origin at
the Earth's center. At the very minimum you will need spherical Earth
altitude and gravity functions, but WGS-84 altitude and gravity would be
better and match up with your GPS. On top of that, the Earth's surface
is spinning wrt to the coordinate system as Norman has pointed out.
On 28/12/2018 9:55, Norman Yarvin wrote:
On Wed, Dec 26, 2018 at 11:07:55PM -0700, Monroe L. King Jr. wrote:
That all makes sense. The problem I have is we have code with an earthPart of what might be puzzling is that there's a very good chance that
frame and we need to go to an inertial frame and I don't know how to do
that. I don't even know where to start to rewrite the code.
the code already implicitly assumes an inertial frame (as in not
having any corrections for Coriolis force and such) and the existing
users are just accepting the resulting inaccuracy. In that case it's
mainly the initial values that need changing: instead of starting at
zero m/s, you'll be starting out moving with the rotation of the
earth. Code alterations might then be needed so that the atmosphere,
too, can be modeled as moving at the same velocity.
By the way, with Ardupilot, the software assumes that it will
constantly be making corrections as a result of feedback. Coriolis
force errors are infinitesimal at first, so when flying a plane the
software doesn't have any difficulty correcting them out just as it
would correct any other random perturbation. But when going for
orbit, the assumption that minor corrections can constantly be made
doesn't apply: you may be doing one burn, waiting, then doing another.
During the wait period it's impossible (or at least much harder) to
correct the flight path.