ROS 2 integration for a documented device.
We connect your device—such as a motor controller, actuator or robot mechanism—to ROS 2 through a documented ros2_control interface. Your customers receive a tested driver they can integrate with compatible controllers and tools.
A documented interface with agreed tests.
The deliverable is a ros2_control hardware interface with named command and state interfaces. The quote specifies compatible controllers and tooling.
Our motor-controller interface runs on our rover and drives its motors through ROS 2, with velocity commands, wheel feedback and fault reporting. Explore the project →
ros2_controlhardware interface plugin- Transport layer over your SDK, Modbus, CAN or Ethernet
- Control loop with measured timing at a stated rate, read and write separated
- Telemetry and diagnostics published as standard messages
- Command limits, command validation and a communications watchdog
- Unit tests, plus a simulated device so the tests run without hardware
- Documentation covering interfaces, parameters, units and fault behaviour
- Automated builds and tests for the versions named in the quote
The proposed package includes these items; see how we scope the work.
What we need before the driver can be written.
The call settles what exists and what does not, before a price is written.
The interface documentation
An SDK, register map, protocol specification or CAN database. Identify any undocumented behaviour so discovery work can be scoped.
A unit to drive
A unit we can command on our bench or at your site, for integration and fault testing.
Fault and limit behaviour
The response to communication loss, operating limits and recoverable faults. These define the driver’s command checks and fault handling.
Your licensing position
Whether the driver will be public, shared with customers or internal, and what redistribution your SDK licence permits.
Define the interface and acceptance tests.
Start with one documented device and a unit available for testing. The proposal identifies supported commands, diagnostics, software versions and test conditions. Undocumented behaviour, additional variants and timing requirements need a separate assessment.
- Simulation-ready asset package — the same interfaces, driving a model
- Hardware-validated twin — how closely that model matches the unit
Before we discuss your project.
Our SDK is closed and under agreement. Does that rule this out?
No. We check your SDK licence and distribution requirements during scoping. It may be linked or loaded at runtime where permitted; restricted SDK files are not redistributed.
There is no SDK — only a register manual.
A register manual can be enough. We scope any bench work needed to confirm behaviour that the documentation leaves unclear.
Which distros?
We agree the ROS 2 distribution and test environment during scoping. Existing development targets Jazzy; other versions need compatibility assessment. The quote defines the versions tested at delivery.
Can you test it without our hardware?
A simulated device supports automated tests without hardware. Delivery also includes testing against your physical unit.
What about safety certification?
The driver checks commands and handles communication loss. It is not a certified safety function; any required safety-rated stop must be provided by your machine’s safety system.
Tell us about the interface.
Start with a free twenty-minute scoping call. We’ll review the task and available information, then propose a scope and price. If a paid assessment is needed first, we’ll agree that with you before proceeding.
Or email hello@drimkoe.com
For procurement: the capability statement — competencies, past performance, scope and engagement terms in a printable document.