Inertial Plugin

The Inertial Plugin serves as a factory for inertials. Each inertial is responsible for providing INS solutions as well as specific forces and rotation rates. Most implementations will provide a range of solutions by buffering and interpolating.

There are two types of inertials: the StandardInertialMechanization and the ExternalInertial. The StandardInertialMechanization is a superset of the functionality of the ExternalInertial, so we’ll talk about the ExternalInertial first.

ExternalInertial

This type of inertial assumes an external system is mechanizing an IMU and providing INS solutions to the pntOS-Python implementation. It buffers the PVAs coming in the from INS, interpolating between then and using them to calculate forces and rates.

This inertial provides a couple methods to supply the user with metadata about the types of data it supports:

• request_solution_message_type(): can be used to programmatically determine which type of message the inertial provides as its solution, usually a PVA.

• request_process_pntos_message_types(): can be used to programmatically determine which types of messages the inertial consumes. For the ExternalInertial, this is usually a PVA. For the StandardInertialMechanization, this is usually an IMU message.

Before requesting a solution, it is generally good practice to verify that the desired solution time(s) are supported by the inertial. The following methods provide information about which times are valid:

• request_earliest_time()

• request_latest_time()

• is_time_in_range(time)

The range of buffered solutions can generally be increased (or at least advanced in time) by providing additional measurements from the external INS via process_pntos_message().

Then, solutions can also be request in a variety of ways:

• request_current_solution()

• request_solution(time)

• request_solutions(times, solution_type)

Note

In a multithreaded or multiprocessing environment, users will need to check the returned solution even if they’ve verified they requested a valid time due to Time Of Check, Time Of Use (TOCTOU) issues.

The last function of this inertial is to provide the user with forces and rates. These are often required by inertial state blocks like the Pinson15NedBlock during propagation. These are provided via two methods:

• request_forces_and_rates(time)

• request_average_forces_and_rates(time1, time2)

StandardInertialMechanization

This type of inertial assumes an initial inertial alignment (often provided by a InertialInitializationStrategy) and stream of IMU data. It then mechanizes the inertial data to provide the system with a series of INS solutions.

This type of inertial contains all the same methods as a ExternalInertial. However, this type of inertial provides a few additional methods for managing the internal state of the inertial mechanization. In particular, a free-running inertial will experience exponential error growth over time, requiring feedback from the filter to maintain a useable level of error.

request_reset_message_types() allows the user to query for the types of messages that are supported by the implementation for feedback, usually a PVA. Then, reset_solution(message) can be used to reset the inertial solution to the filter-estimated solution.

The inertial also maintains a set of estimated inertial errors, which are applied during mechanization to reduce the error drift. These can be managed via:

• correct_sensor_errors(time, errors)

• request_sensor_errors(time)

Cobra StandardInertialPlugin

Cobra includes the StandardInertialPlugin, which provides a StandardInertialMechanization that mechanizes IMU measurements to produce PVA solutions.