Let’s say you’re building a robotaxi, and you’ve bought HD digital maps of the city you operate in for the vehicle to use for navigation. During the integration stage, you notice a problem. According to map data, you’ve arrived at a specific coordinate – and while the robotaxi’s own GNSS system agrees that you’ve arrived at that location, it’s giving it a different coordinate. What gives?
In this article we’ll explain a common challenge with autonomous navigation – datums – and how to solve it.
What is a datum?
There are actually two datums that we talk about in the field of inertial navigation – horizontal and vertical. Both datums are a combination of two different bits of data that are vital for creating maps:
- A reference ellipsoid of the earth
- A reference frame that that ties the coordinate system of the map to the earth to a specific point
Imagine you had a piece of cloth with a grid drawn on it, and a giant balloon. The balloon is the reference ellipsoid, and the datum reference frame is the cloth. If you draped the cloth over the balloon, that would be a horizontal datum. Vertical datums give us a way to measure height, and some use the hypothetical surface of their reference ellipsoid (the balloon) as their reference point, while others use the seal level at specific points on the earth.
Where it gets complicated is that there are lots of different datums – and each will give you a slightly different location result. Some differences between datums arise from their use of different reference ellipsoids (imagine draping the same cloth over a different shaped balloon), while others might come from using different reference frames (imagine draping a different cloth over your original balloon) – or both of those factors (am I overdoing the cloth and balloon example?).
The upshot is that the same coordinates can refer to different locations in different datums – and, on the flip side, the same location can have multiple coordinates in different datums.
What does this have to do with autonomous navigation?
Different organisations use different datums. In Australia, for instance, there are three datums actively in use by various organisations: the most current datum, GDA94, its predecessor AGD84, and an older version called ADG66. The map data you bought for your city will have been created using a specific datum – and your autonomous vehicle will be navigating the world using its own datum. If the two don’t match – or you haven’t accounted for the differences between them – you will find that your GNSS data doesn’t match up with your map data.
And (just in case you’re tempted to think that this is a minor issue), differences between datums can cause big problems. Referring back to our previous example, the same coordinates in GDA94 and AGD84 can differ by more than 200m in some places. Plus, a mismatch in vertical datums could cause your vehicle to inaccurately estimate its height compared to the height of, say, a bridge it needs to go under. Hopefully you can imagine the consequences this could cause for your vehicle and anyone on the bridge at the time!
How do I deal with multiple datums?
It’s relatively simple to convert coordinates from one datum to another – but the key thing is to know which datums you are working with. You’ll get to choose the datum your INS uses to interpret data it receives from GNSS satellites, but you’ll need to find out which datum any external map data you’ve bought has been created in.
You’ll also need to be prepared for different maps to use different datums – so, if you’re looking to sell autonomous tractors in more than one country (or continent), you’ll need to configure your vehicles differently depending on which map data they are using. If your vehicle is travelling far enough that you need to combine two sets of map data, then you’ll need to know the datums of both maps and exactly when to change the conversion you’re doing as your vehicle stops using one map and starts using another.
It’s also important not to forget the vertical datum. While most GNSS satellites provide height relative to an earth ellipsoid (specific to each GNSS constellation), the processor in your GNSS receiver will also contain a model of the geoid (click here to learn what that is) which is used to present you with geoidal height (this article has a great explanation of the different types of height measurements). However, there are issues:
- The geoidal height calculated by your GNSS receiver may not be very accurate – low-grade receivers often only have a very low-resolution geoid model to work with.
- Different GNSS cards use different geoid models to calculate height.
- The HD map data your vehicle is using will also have used a specific vertical datum to calculate its heights – which may not be the same as yours.
To make sure your height estimations are correct (which might be important if your autonomous vehicle needs to fit under things like bridges or gantries), you’ll need to make sure you’re using the most accurate height estimations possible, and are converting correctly between the different vertical datums used in your GNSS receiver and your map.
The OxTS solution
At OxTS we’ve attempted to make our INS devices more flexible for users by enabling them to output position data in real time using the following datums:
- WGS84
- ITRF2008
- ETRS89
- NAD83
It certainly doesn’t remove all the work a user would need to do – but it does make the job easier by giving you a range of datums to work with.
Our INS also allows you to choose whether to output height data based on a GNSS receiver’s own calculations of geoidal height, or to use the ellipsoid height. As the GNSS receiver’s ellipsoid height is usually much more accurate than the geoidal height, this enables you to build a system that works off the most accurate height possible – as long as you remember to convert all your height measurements to the same datum before integrating them.
Questions?
We hope this article has been helpful to you if you’re researching the ins and outs of inertial navigation for autonomous vehicles. If you have any questions that you’d like help with, we’re always happy to talk – just get in touch with us at support@oxts.com
