OSCP opens its ROS 2 driver to get photonic sensors into robots

Why it matters

OSCP is reducing the work required to test its photonic sensors in ROS 2 robots. Its road-test advantage is company-measured, so builders still need to validate drift on their own routes.

Kazem Zandi has opened a new route into robotics for OSCP's inertial sensors: on September 22nd, his Montreal company released an MIT-licensed ROS 2 driver for its MK2 hardware. The release coincides with ROSCon Global in Toronto, where OSCP is exhibiting. The immediate pitch is practical. A robot builder can feed measurements from an OSCP sensor into familiar ROS message types instead of writing a parser for its serial protocol.

Zandi's interest in that integration problem reaches back to his engineering-physics doctorate at Polytechnique Montreal, where he worked on integrated-optics inertial sensors. He later worked in process engineering at C2MI and optoelectronics at Defence Research and Development Canada. In a 2021 interview with accelerator Luminate, he described OSCP as a continuation of his doctoral work: shrinking optical motion sensing enough to make it useful on autonomous vehicles. The driver addresses a different obstacle to the same goal. Smaller hardware has limited value if adopting it becomes a software project.

The integration work OSCP is taking off the customer's desk

The driver and its installation instructions target ROS 2 Humble and Jazzy on Ubuntu 22.04 and 24.04. OSCP says it connects an MK2 unit over RS-422 or CAN-FD, decodes the sensor's data and publishes standard sensor_msgs topics. Three packages divide the work among a ROS node, a decoding and frame library, and OSCP-specific messages carrying device timestamps. The published build instructions name oscp_msgs, oscp_libraries and oscp_imu_ros2; OSCP also links the MIT-licensed repository from its announcement.

The configuration documentation shows what an integrator can control without changing code: transport, device path, output frames, operating mode and sensor settings are specified in YAML. Standard ROS output includes IMU, magnetic-field and temperature messages. At the documented medium operating mode, the output rate is 500 Hz; OSCP cautions that enabling too many frames at that rate may overrun the sensor controller. ROS services cover configuration queries and calibration. These details make the release more useful than a compatibility badge, while leaving deployment and testing with the builder.

OSCP credits robotics engineering intern Rayan Raad with writing the driver. Thibaut Gravey, identified in the release as OSCP's vice president of product, framed the open-source decision around the changes integrators actually make: timing, published frames and calibration. Zandi said in the announcement that OSCP wrote the driver to keep integration from becoming a separate project.

One interface, different heading sensors

The driver serves two production models and a prototype. OSCP describes the MK2M2 as a MEMS-only inertial measurement unit measuring 40 by 40 by 25 millimeters, weighing 75 grams and drawing 1.2 watts. The MK2E2 keeps MEMS sensors on two axes and uses an optical gyroscope on the Z axis, which measures heading changes important to a vehicle's course. OSCP says customers can move between them without changing the ROS interface. Its higher-precision MK2Z remains a prototype; the stated trade-off is a 475-gram unit drawing 4.5 watts. Shared software does not make the devices physically interchangeable.

OSCP's Montreal road-test report offers evidence for choosing the optical axis, with an important boundary around the result. In a January 9th, 2026 drive lasting 21 minutes, OSCP says the MK2E2 finished 5.7 meters from the recorded position, against 20.5 meters for the MK2M2. Both sensors rode in the same vehicle and supplied heading to the same calculation. Satellite position was withheld from that calculation, but its one-hertz speed input came from the recorded GNSS data. This was a controlled comparison using shared speed data, not a demonstration of a vehicle navigating with no satellite-derived input. The endpoint figures are OSCP's measurements from one route, not an independently reproduced performance guarantee.

That distinction matters to a warehouse or tunnel operator. The driver delivers measurements to a robot's software; it does not itself turn those measurements into a complete positioning system. OSCP's published road test also used a simpler calculation than the sensor fusion a production robot would run. The result gives an integrator a reason to test the photonic model under its own vibration, route and correction conditions, rather than treating 5.7 meters as a specification for every deployment.

A distribution bet with established rivals

Open-source ROS integration is already part of this market. SBG Systems documents an open-source ROS 2 driver across its inertial-sensor lines, including products that publish broader navigation outputs. OSCP's opening is therefore specific: offer builders a common path into its MEMS and photonic hardware, then compete on whether that hardware earns its place in a robot's error budget. In a neighboring part of the GPS-denied navigation market, Anello Photonics reported an additional $25 million financing in May to increase production of its optical-gyroscope-based systems. Easier integration lowers one barrier to evaluating OSCP; it does not settle the sensor comparison.

Zandi has had backing for the hardware work. In a previous company announcement, OSCP named 7percent Ventures and 2050 Capital as investors in a $1.2 million seed round. The Canadian government announced a $3.2 million investment through Sustainable Development Technology Canada in November 2021. Those historical amounts should not be added together as a current funding total: they come from different announcements describing different forms of backing.

For OSCP, the September 22nd release puts software adoption alongside the optical-sensor thesis Zandi has pursued since his doctoral research. Builders can inspect and adapt the interface before committing a sensor to a navigation stack. Whether they keep that sensor aboard will depend on performance in the routes and operating conditions their own robots encounter.