Integrating an IMU: interfaces and drivers

Start with the bus

An IMU is only useful if your system can read it fast enough and reliably enough, over a bus you already run.

RS-422 is a differential serial standard built for electrically noisy environments and long cable runs. It is the workhorse for vehicle-mounted sensors for good reason.

CAN-FD is the modern automotive and machine bus, and the right answer when the sensor has to share a bus with everything else on the vehicle.

Both are on every unit in the MK2 family, at output rates up to 500 Hz, on a 12 to 34 V supply.

What is not there matters too. Ethernet is not available on current units, and MAVLink is not supported. If your architecture assumes either, find out early. We would rather tell you now than at integration.

Rate, latency and timing

Output rate has to suit your control loop. A navigation-grade sensor at 10 Hz cannot stabilise a fast airframe, and 500 Hz is not automatically better if your estimator runs at 50.

Latency and jitter matter more than people expect. An inertial measurement is only as useful as your knowledge of when it was taken. If you are fusing IMU data with anything else, the relative timing between them sets a floor on your accuracy that no amount of sensor quality will lift.

Ask any supplier how measurements are timestamped and what the worst-case jitter is.

Drivers and software

This is where integration time is actually spent, and it is worth checking before you choose a part.

ROS2 driver. Open sourced August 2026. If your stack is ROS2, this is the shortest path from box to data.

ArduPilot driver. Available since July 2026, for autopilot integrations.

C SDK, with a development guide and worked examples, for embedded targets and custom stacks.

Python examples ship with every unit, which is usually how the first data set gets logged.

Documentation lives at docs.oscp.com.

Evaluating before you commit

The gap between “this datasheet looks right” and “this works in my system” is where programmes lose weeks.

The InertialGate board exists to close it. It is a 57 x 66 mm evaluation and gateway board that connects an MK2 IMU to whatever you already have:

• To a computer, over USB-C, presenting the RS-422 link as a virtual COM port
• To a Raspberry Pi, over RS-422 or CAN-FD, HAT+ compatible
• To an autopilot such as a Pixhawk, or any generic system, through the development headers

The point is a first data set on your bench in an afternoon, without building an interface board first.

Calibration: what is done for you, and what is not

Done at the factory. Offset, scale factor and misalignment are calibrated on every unit, plus gyro non-linearity on the MK2E2 and soft and hard iron correction for the magnetometer.

Done by you in the field. Gyro offset is re-run at startup once the unit has stabilised, and the magnetometer should be recalibrated after each re-installation, because the magnetic environment belongs to your vehicle rather than to the sensor. There is no fixed recalibration interval.

Shipped with the unit. Every unit comes with its own outgoing static test report, so you have measured data for your specific serial number rather than a family specification.

Mounting and mechanical integration

Alignment matters more than most people plan for. A misalignment between the sensor axes and the vehicle axes is a systematic error that no filter removes for you, because it looks exactly like real motion. Decide early how you will reference the sensor to the vehicle frame, and how you will measure the residual.

Rigidity matters too. An IMU mounted on anything compliant measures the mount as well as the vehicle. Mount it to structure, not to a panel.

Then check the environment. Vibration, shock, temperature and EMI all find weak sensors. Our units passed vibration at 2, 4 and 8 g and shock at 20 g and 40 g to DO-160 style profiles, along with Class A emissions and ESD testing. Mounting and power details are in the user manuals.

A short checklist before you commit

• Does it speak a bus I already run, at a rate my estimator can use?
• Is there a driver for my stack, or am I writing one?
• How are measurements timestamped, and what is the jitter?
• What is calibrated at the factory, and what do I have to do in the field?
• Can I get an evaluation unit onto my bench before I design it in?
• What is the ingress and temperature rating for the specific model, not the family?
• Can I actually export the system I build around it?

Frequently asked questions

Do you support MAVLink?

No. Current units speak RS-422 and CAN-FD, with ROS2 and ArduPilot drivers, a C SDK and Python examples. If MAVLink is a hard requirement, tell us early.

Is there an Ethernet option?

Not on current units.

How quickly can I get data flowing?

With an InertialGate board and the Python examples, an afternoon is realistic for a first logged data set. Integrating into a live control stack is a longer job, and the driver you start from decides how much longer.

Do I need to recalibrate the unit periodically?

There is no fixed interval. Re-run gyro offset at startup, and recalibrate the magnetometer whenever the unit is re-installed or the magnetic environment around it changes.