Navigation System Basics
Last updated
Last updated
The navigation system on the lidar system is an Inertial Navigation System (INS), as it employs at its core the use of an Inertial Measurement Unit (IMU) to determine its position, orientation, and velocity. An IMU is a sensor that contains accelerometers and gyroscopes, which provide data about acceleration and rotational movement. In our context, GNSS data is also an important component of the INS.
Most of the information below refers to the INS as a piece of hardware, operating in real-time, however the same concepts also apply to post-processing software, which themselves are basically navigation systems operating on previously-acquired data.
Technically, you can navigate exclusively with an IMU, using just its acceleration and rotation data to determine your change in position, velocity, and attitude. IMUs are known to drift, however, so GNSS data is used to correct the trajectory and provide position updates. So, you can think of the navigation system, and trajectory processing more broadly, as the process of determining a consensus between several sensors (IMU and GNSS) on the vehicle's position, velocity, and attitude.
IMUs and GNSS Receivers, as sensory input into an INS, are generalized and contrasted in the table below:
IMU
acceleration and rotation information
100 Hz - 400 Hz
low
GNSS Receiver
position updates only
1 Hz - 10 Hz
High
From the table you can see that while IMUs have a much higher data rate than GNSS receivers, they have lower accuracy. So, you can think about the process of determining a vehicle's position using an INS as the GNSS receiver occasionally correcting an IMU-determined position:
IMU data is relative to the IMU's own coordinate system (specified by the manufacturer), so to get IMU data in vehicle frame, we must know how the IMU is oriented in respect to the vehicle. Once we know how the IMU is oriented, we can associate IMU data with a vehicle direction (e.g. if the IMU's Y-axis points vehicle-forward, and the IMU's Y-axis accelerometer outputs a large value, we know that the vehicle moved forward).
The rotation required to rotate the IMU axes into the vehicle axes is referred to as the Vehicle Body Rotation (VBR):
You can configure the lidar system's VBR in the rover settings Navigation menu.
Vehicle axes are somewhat arbitrary. In NavLab and InertialExplorer, they are defined as X-right, Y-forward, and Z-up (shown in diagram above). The real-time navigation system uses the same convention. Ultimately the purpose of vehicle axes are to define what constitutes a forward motion, a movement up, or a movement to the right, i.e. to provide a frame of reference.
GNSS positions are recorded at the GNSS antenna, however the center of the INS is the IMU center of navigation (specified by the manufacturer - all IMU data is in respect to this point). Thus it is necessary to specify offsets from antenna to IMU, so that the INS can adjust GNSS positions accordingly when comparing them to IMU measurements. Antenna lever arms are also specified in the rover's navigation system menu.
We've discussed how IMU and GNSS data can be combined to create a unified solution about the vehicle's position, but what about attitude and velocity?
As for velocity, we won't give it much attention, as it's not absolutely necessary to build a pointcloud, however computing velocity is very similar to position, where an IMU-determined velocity is combined with a GNSS-determined velocity (GNSS L1 doppler velocity).
Attitude information is absolutely necessary for building a pointcloud. Here attitude is essentially synonymous with "orientation" or "vehicle orientation". Attitude is represented in vehicle frame as roll, pitch, and yaw. Assuming a correct VBR has been input, roll and pitch can be directly observed by the IMU, as the force of gravity constantly informs the INS about whether it is rolling (leaning left or right) or pitching (leaning up or down). Determining the vehicle's yaw, sometimes referred to as "heading" or "azimuth", is more difficult, as gravity does not differentially pull on the IMU when it is looking north, or east, or south, etc., thus the IMU must be initially aligned.
IMU alignment is the process of determining an initial heading or yaw for the vehicle. In other words, IMU alignment is the process of aligning the IMU axes with a world coordinate system (north, south, etc.) so that we can effectively compare IMU positions to GNSS positions.
Refer to the example earlier, where we have an IMU trajectory that is corrected using GNSS positions:
The IMU to vehicle rotation (VBR) is known and input into the INS, so we know which IMU axes correspond with which vehicle axes (forward, right, up), however GNSS does not provide positions in vehicle frame. GNSS positions are provided referencing some global coordinate system, such as WGS84, so it is necessary to determine not only how the IMU axes correspond to the vehicle frame, but also how they correspond to the world frame (north, east, up).
With most lidar systems, an initial yaw is determined at the beginning of the data set, and from there on out the IMU maintains this initial yaw using it's gyroscope data. This initial yaw determination is referred to as the Kinematic Alignment:
During a kinematic alignment, the vehicle moves in a straight line. GNSS positions recorded on this straight line form a course over ground, which itself is a direction of travel in world space (south, southeast, etc.). Thus, during the kinematic alignment the IMU's initial heading is initialized as this course over ground.
The term "static alignment" is often misused. Only fiberoptic-gyroscope IMUs can determine their initial heading statically. It is true that all IMUs, and all INS systems, require some static time at the beginning and end of a data acquisition. This static time is used to initialize biases associated with the IMU data. This static period should not be confused with a static alignment.
You can see on the example flight plan a figure eight maneuver. These figure eights are often mistaken as an "alignment". This is not true. Figure eights are a highly dynamic movement, as the vehicle must frequently turn to fly in the shape of an eight, thus figure eights would constitute a poor kinematic alignment, which is ideally flown in a constant direction.
Figure eight maneuvers are used to stabilize the INS solution after alignment. Once the kinematic alignment has been completed, flying figure eights provides the navigation system with highly dynamic data and helps solidify the consensus between the IMU and GNSS data. More on this here.
So, we have defined essential components of an INS, namely an IMU and a GNSS receiver. We've also defined that an INS can be a physical piece of hardware, operating in real-time, or it can be in the form of software, post-processing data after the fact. The most important inputs for initializing an INS are the IMU vehicle body rotation (VBR), which specifies the orientation of the IMU axes in respect to the vehicle axes, and the antenna lever arm values, which specify the offset between the IMU center of navigation and GNSS antenna.
Considering that all lidar data is post processed, a basic flight plan can be defined as:
Static period
Kinematic alignment
Figure eights
Mapping mission
Figure eights
Kinematic alignment
Static period.
If a kinematic alignment is an initial heading/yaw determination, why is an additional kinematic alignment required at the end of the flight? Similarly, why do figure eights need to be flown after the mapping mission? More on this in the next section.
Some high-end, fiberoptic-gyroscope IMUs can feel the earth rotate, and from this information they can align motionlessly, so long as they have good GNSS data. With these systems, simply waiting statically for about 5 minutes will suffice as an alignment, and then you can begin your mapping mission. Most operators still perform a kinematic alignment, just in case the static alignment results in a poor heading. More about this .
