Fusing GPS + IMU For Fun and SBETS
By David Bulnes and Jian Wu, Engineering
Last month, we held the second webinar in our ongoing and live-broadcasted Getting Started with Sensor Data series. (We’ve also published an archive of the video playlist here.)
In that session, we covered the basics about a few sensors which should be relatively familiar to some of our readers — IMU (Inertial Measurement Unit) and GPS (Global Positioning System). We also discussed why these sensors are commonly used and the role that they play in Civil Maps’ localization and mapping stack.
IMU and GPS are just two of a significant and growing number of sensor types with which Civil Maps currently works. Depending upon our individual client’s specific needs, we are accustomed to working with different setups and constraints. Appropriate to the wide variety of sensors and data types on the market, we’ve built our software to easily handle a nearly infinite variety of different configurations. As IMU and GPS are “workhorse” sensors for localization and autonomous driving functions, you’ll commonly see them used in a lot of prototype cars. (Civil Maps’ technology stack is also built to leverage some more exotic sensors, but that’s a topic for another webinar/blog post!)
Another key subject covered in our latest webinar was SBET creation (Smooth Best Estimated Trajectory), a synthetic data type composited from the output of both IMU and GPS sensors. An SBET file is actually a sequence of SBET points — each SBET point has time of day, positional coordinates, and rotational information. After calculating our SBET from IMU and GPS and accounting for sensor boresighting and mounting information, we synthesize this data with that captured via LiDAR or conventional cameras to register a point cloud.
What Types of Information Do We Get from the IMU?
- Accelerometer — Acceleration values across the XYZ axes
- Gyroscope — Orientation by measuring the angle of the spinning flywheel as it spins independent of its stationary frame
- Magnetometer — Tilt with respect to the Earth’s magnetic vectoring, parallel to the ground. (Think of a magnetometer like a 3D compass)
- Barometer — Elevation by tracking local air pressure, which varies with regularity relative to sea-level
What We Get from GPS
To codify and index our GPS data, we use the WGS84 ellipsoidal, vertical reference frame and for horizontal positioning, we use the UTM horizontal reference frame.
- WGS84 ellipsoidal elevation datum — This measures altitude and elevation according to the planet’s mean sea level. Since the Earth is not a perfect sphere, ellipsoidal elevation models primarily even-out the various irregularities of the earth’s surface into a smooth ellipsoid, ensuring consistency in measurements and geoindexing.
- UTM (Universal Transverse Mercator) — Although there are many different projection schemas, for our horizontal/planar location, we divide the earth into 60 zones, with each zone having its own range of XYZ coordinate values. For example, Northern California is Zone 10, while Southern California is Zone 11. We also use UTC (Coordinated Universal Time) in our development stack. UTC is based both upon the rotation of the Earth around the Sun, and the rotation of the Earth around its own axis. The GPS timestamp we receive from orbiting satellites, on the other hand, is in GPS time, which is measured in the number weeks, days, seconds since January 1, 1980.
Due to this discrepancy, we run a conversion of our GPS data into the format native to our software stack. In the recent GPS/IMU themed webinar, we explained the math we use to convert from GPS time to UTC, with careful consideration going towards not forgetting the leap seconds that have to be added in periodically to keep UTC accurate.
Synthesizing IMU and GPS output into an SBET
As the video above explains, we read in our IMU data — (and we’ll be releasing the source code for how we do this next week on Github) — and buffer it. After this, we verify and add in our GPS data, along with a Dilution of Precision coefficient value that reflects our degree of confidence in the GPS data. Dilution of Precision is the geometric relationship between the location of the GPS satellites in the sky and our GPS antenna — if the sites are too close together, the resulting geometric confidence isn’t really that strong and deterministic — i.e. there is a lot of uncertainty/probabilistic noise. Weather and environmental geometry also factor into the accuracy of GPS readings. In general, Civil Maps doesn’t rely heavily on GPS readings. In fact, it seems like we use less of it every day. GPS is more about the initial lock, and generally, we don’t shift our SBET that much based on its data. (In Parts 3 and 4 of the webinar we go into our calculus in greater detail.)
Civil Maps verifies our precision by doing simulations in which we can reverse-engineer point clouds and sensor data. Running multiple trips in the same simulation environment gives us a composite “ground truth” beyond what can be determined from real world data.
More to Come
Look out for more webinar materials in a few weeks. We are working on sharing content from Webinar Three (Sensor Fusion Pt 1). Webinar Four, the last session in the series, is a continuation of the Sensor Fusion topic and takes place on Thursday June 29th, 1:30 PST. You can register and catch up with past webinars from the series here.
Meet and greet Civil Maps at our post-webinar gathering! Please RSVP to info@civilmaps.com with the subject line “Webinar Happy Hour.” The drinks will be on us.
P.S. We’re hiring! Don’t see your role there yet? Email: jobs@civilmaps.com
