From GNSS to INS
Focusing on mobile mapping applications over the past several months we have looked at what is available regarding the GNSS component. Now it is time to move along to the INS. There seems to be considerable confusion and misunderstanding about the role of GNSS receivers in an INS. By this I mean it is often thought that the two were almost the same or that the GNSS receiver was the more critical part of the INS. The fact is, both are important and without either we are pretty much stuck in the pre-1980’s era. Let’s start by clarifying a few terms.
The GNSS, or Global Navigation Satellite System, is a system of satellites that provide 3D geo-positioning information (e.g. lat., long, elev.). As we have previously noted there are several GNSS working at least in part already. GPS is the most common GNSS and the terms are often used interchangeably in conversation.
The INS, or Inertial Navigation System, uses dead reckoning to compute the position, orientation, and velocity of an object using accelerometers, gyroscopes, and magnetometers. The position is relative to some arbitrary starting point. It does not require any external reference. Additionally, the INS is completely passive. It does not require input from any outside source (aside from the natural environment, most notably gravity). Often times, the term IMU – inertial measuring unit is used interchangeably with an INS, as defined.
It is plain to see then that a GNSS provides position in a worldwide framework and an INS provides a local position along with orientation and velocity. To this point the two are completely separate and independent. For mapping, we tend to work in a worldwide reference frame even if it is a local state plane coordinate system or something similar. This is where GNSS comes in to make what we typically refer to as our INS for mapping.
For the INS to work as we expect, we generally must have a good GNSS lock or positional fix at the beginning. This is critical as it is the basis for all updates that are derived from the INS. Without this fix, we are working in some unknown location (last best known position or something completely arbitrary) and consequently our data will not line up in the real-world and if and when we do get a positional fix, our position will likely update quite abruptly to somewhere very different (hopefully the correct location).
Over time every INS will drift. This is inevitable. The better the INS, the less drift, and the more expensive and generally larger the INS will be. This is very important for mobile mapping and this is where GNSS plays a very important role yet again. Since the drift is a function of time, it is important to continually get GNSS positional updates to keep the INS on track. The updates may be quite fast (10Hz or more) but in most cases even 1Hz is sufficient. This is also why you will see discussion about GPS outages. We routinely encounter outages due to trees, tall buildings, terrain, tunnels, etc. It is very common in mobile mapping (unlike using a UAV or scanning on water).
There is a 3rd part to our INS we have yet to discuss – software. It’s one thing to have all of this GNSS and IMU input but how and what manages it and makes it useful? That would be the software. The software generally comes in two flavors as well: real-time and post processed. The software is merging, integrating, massaging, and filtering the input for position, orientation, and velocity from the GNSS and INS to produce a nice, smooth, useable trajectory. To do this in real-time is not trivial. There are a lot of parameters to consider in the real-time correction. While it might not be very difficult to process the GNSS alone in real-time, it is another matter to do a good job with all of the IMU data as well. As you might expect though, this becomes less and less of a problem with the passing of time as technology provides faster and faster processors.
The better software requires some user input to aid in the calculation. For instance, a conventional aerial solution can assume clear sky all of the time. Likewise, the flight lines are generally collected at speeds over 100 mph along nice straight lines with banking only at the ends of the lines. A helicopter would be much different. It can hover, turn in place, and generally doesn’t fly as fast. The vibration may also be a factor. On a boat initialization can be an issue but there are other factors as well such as heave. A multi-copter UAV would be similar to a helicopter but probably much slower. A fixed winged UAV would be similar to a plane but slower as well with much smaller banking. A car (or any vehicle on the street) could expect lots of outages, 90 to 360 degree turns, backing up, multiple point turns, etc. It is much different than an aerial vehicle. A pedestrian (backpack or cart) would be different still with a walking cadence. A rail vehicle would be constrained to a rail with long turns, long straight-aways, forward and backward motion only. All in all, the software plays a very critical role in processing the INS data to support our mapping.
In summary, the INS is comprised of three main components: GNSS, INS, and software. It is important to note that most INS packages rely upon GNSS input. It’s safe to say that this will continue indefinitely but that alternative solutions for positioning will become more commonplace over time. SLAM, indoor positioning, and a variety of other means of obtaining positional information will be added to the INS platforms allowing even more applications to utilize INS.
This ends our discourse on GNSS options available and opens our journey with INS. Until next time, check out our new UAV LiDAR solutions at www.lidarusa.com.