A fair amount of iterative testing goes into developing interconnected guidance, navigation, and control systems. While nothing can replace the insight that comes from testing the interconnected system, actual algorithm development for each sub-system is better done in isolation.

For navigation system design, this means simply ignoring other subsystems (guidance, control, propulsion, etc...) and simply focusing on two things:

1. inputs: sensor measurements of the environment (e.g. magnetic-field)
2. outputs: navigation state (e.g. heading)

Inputs: Sensor Measurements

With data being widely available, or easily acquired, it would seem gathering inputs or sensor measurements is trivial. True, only if one enjoys learning about the many quirks and unique properties of many data sets. Time spent removing NANs, flipping signs, ignoring spikes, aligning signals, and determining units is time not spent developing and testing the navigation system.

A similar issue exists with simulated data, though to a lesser extent. With simulated data it is important to understand what assumptions went into the simulation. With a wide range of possible assumptions, it is undesirable to understand them all.

Outputs: Navigation State

It is the job of the navigation algorithm to estimate the navigation state. Hence, quantifying the performance is best done knowing the true navigation state. The true state is often easily available via simulated scenarios. After all, most simulators begin with the true state and then simulate the associated sensor measurements.

Determining the truth when working with real measurements will require some ingenuity. This was discussed in the article: Truth System - What Really Happened?.

Combined Reference Data

A data set with both navigation sensor measurements and known navigation states can be used to design and test navigation system algorithms. Once such data sets are well understood, documented, and purged of data logging artifacts, there is no reason not to reuse them. The effort to go from raw data to reference data is considerable. Therefore it makes sense to leverage that initial effort for the future benefit. Not all raw data will make the cut either. One more reason to revisit the data which has proved its worth.

A package of such reference data serves as standard test cases that can be used across projects and time.

The birth of onavdata

At Organic Navigation we use reference data sets often. Some was collected internally and others leverages the efforts of other people. The contribution we are making is to make the data accessible through a Python package named onavdata.