Skip to content

Build1 publisher3 min readPublished

OSCP open-sources MIT-licensed ROS 2 driver for its MK2 inertial sensors

The MIT-licensed packages read an MK2 unit over RS-422 or CAN-FD and publish standard sensor_msgs topics. OSCP's 5.7-metre endpoint figure comes from one 21-minute Montreal drive that still took speed from recorded GNSS.

The Engineer · Build desk

Photograph accompanying OSCP open-sources MIT-licensed ROS 2 driver for its MK2 inertial sensors
Photo: runtimewire.com

What happened

  • OSCP released an MIT-licensed ROS 2 driver for its MK2 inertial sensors on September 22nd, timed to ROSCon Global in Toronto, where the Montreal company is exhibiting.
  • The packages target ROS 2 Humble and Jazzy on Ubuntu 22.04 and 24.04, read an MK2 over RS-422 or CAN-FD, and publish standard sensor_msgs topics for IMU, magnetic field and temperature.
  • Three packages split the job between a ROS node, a decoding and frame library, and OSCP-specific messages that carry device timestamps, named oscp_imu_ros2, oscp_libraries and oscp_msgs.
  • Transport, device path, output frames, operating mode and sensor settings are specified in YAML, and ROS services handle configuration queries and calibration.
  • OSCP says that in a 21-minute drive on January 9th, 2026, the MK2E2 finished 5.7 metres from the recorded position while the MEMS-only MK2M2 finished 20.5 metres away.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost The evaluation work moves from firmware to the vehicle. OSCP now carries the parser and the message definitions; the customer pays for routes, mounting and the estimator that turns samples into a pose.
  • decision Because the ROS interface does not change between the MEMS-only unit and the optical-heading unit, choosing the optical Z axis becomes a mass, power and price decision on the platform instead of a software port.
  • constraint An MIT licence lets an integrator patch timing or frame behaviour instead of filing a feature request, and whoever patches it then carries that fork forward across OSCP's future driver releases.
  • exposure A drift advantage measured on one company route is now cheap for a customer to test independently, and OSCP is the party exposed if the endpoint gap narrows on someone else's vehicle.

At the documented medium operating mode the output rate is 500 Hz, and OSCP cautions that enabling too many frames at that rate may overrun the sensor controller [10]. So the first tuning choice an integrator makes is how many frames they can afford at full rate, and the failure mode is already written down. Thibaut Gravey, identified in the release as OSCP's vice president of product, framed the decision to open the source around the changes integrators actually make: timing, published frames and calibration [13]. Zandi said in the announcement that OSCP wrote the driver to keep integration from becoming a separate project [14].

The January road test isolates the heading axis, and OSCP says so in its own material. Both units rode in the same vehicle and supplied heading to the same calculation [21]. Satellite position was withheld from that calculation, but its one-hertz speed input came from the recorded GNSS data [22]. OSCP describes the run as a controlled comparison using shared speed data, not a demonstration of a vehicle navigating with no satellite-derived input, and calls the endpoint figures its own measurements from one route [23]. Dividing the two endpoints gives a 3.6-to-1 advantage to the optical axis [1], which over 21 minutes averages about 0.27 metres per minute against 0.98 [2]. Those are averages across the whole run; the report gives endpoint distances.

The ratio transfers to another platform only if that platform supplies a speed estimate at least as good as one-hertz recorded GNSS, its route stresses heading the way a 21-minute Montreal drive does, and its estimator is no worse than the calculation OSCP used, which the company says was simpler than sensor fusion [25]. The driver delivers measurements into the robot's software and does not itself turn them into a complete positioning system [24].

The MEMS-only MK2M2 measures 40 by 40 by 25 millimetres, weighs 75 grams and draws 1.2 watts [15]. The MK2E2 keeps MEMS sensors on two axes and puts an optical gyroscope on the Z axis, the one that measures heading changes important to a vehicle's course [16]. OSCP says customers can move between the two without changing the ROS interface [17]. The higher-precision MK2Z is still a prototype, at 475 grams and 4.5 watts [18], which is 6.3 times the mass and 3.75 times the power of the MK2M2 [3]. OSCP notes that shared software does not make the devices physically interchangeable [19].

OSCP credits robotics engineering intern Rayan Raad with writing the driver [12]. Zandi worked on integrated-optics inertial sensors during his engineering-physics doctorate at Polytechnique Montreal, and later worked in process engineering at C2MI and optoelectronics at Defence Research and Development Canada [26]. In a 2021 interview with the accelerator Luminate, he described OSCP as a continuation of that doctoral work: shrinking optical motion sensing enough to make it useful on autonomous vehicles [27].

What to watch

  • Whether a customer or independent lab publishes an MK2E2 drift comparison on its own route, and whether it withholds GNSS speed as well as position.
  • Whether the MK2Z leaves prototype status, and at what mass and power once it does.
  • Whether outside contributions to timing, frame publication and calibration land in the MIT repository or stay in private forks.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories