How to efficiently update a local Cartesian frame when traveling over long distances on a curved earth

Question

I have a mobile robot which receives GPS position (lat/lon) and has an IMU for handling gaps in GPS service.

I want to be able to conduct short distance planning in a Cartesian plane, but the robot will ultimately be traveling over long distances. Most references I have found describe using a tangential North-East-Down (NED) frame starting at the robot initial position for local planning. This is fine but I am not sure how to go about updating this plane as the robot moves.

If I was to update (change the origin) for the frame every 5 min, then I would need to compute many new transformations at this time and potentially introduce a repeating lag in the system. How can I avoid this?

Answer 1

Caveat: This is outside my area of expertise so I'm just making stuff up.

The best approach I have thought of so far that avoids extra computation, is to use a distance metric that is a hybrid of true distance and plane approximation distance.

The coordinate of objects, observations, used for planning and navigation are the plane cartesian coordinate, and which mesh element that coordinate is relative to.

For local planning, whose horizon is contained within a mesh element, you can use only the local coordinate. For global planning, the distance between objects is the sum of the great circle between mesh element origins and the local vectors to the start and end point.

Planning and pathfinding with meshes is well researched I think, though you will want to use the great circle distance between nodes rather than the cartesian distance.

You should be able to find a mesh size that works for you. One for which the error in distance is acceptable for the simplification of using a plane approximation locally.

EDIT:

At the boundary you need to convert objects in the current 100m window from the last origin to the next one. This is a simple plane translation or transform which can be done at object creation to spread out the computation cost. You'll need some hysterisis to prevent switching too often at the boundary.

Back of the envelope calcs give about 1mm of error from true position at a 5Km radius. So you could probably get away with increasing your mesh size.

Bottom line, used many fixed location local maps and jump from one to the other rather than dragging the origin of a single map along with you.