hello@dothex.net

+44 (0) 20 3290 3080

London, UK

FREE CONSULTATION

Embedded Systems & Product Development Consultancy · London, UK

Robotics and autonomous systems with ROS 2

A robot is only as good as the embedded layer under its software stack. We build the ROS 2 nodes, the micro-ROS firmware on the microcontrollers, the motor control and the sensor interfaces that turn a navigation stack into a machine that moves safely and predictably.

Talk to an engineer Edge AI for robots

The gap between the ROS graph and the motors

ROS 2 makes it quick to get a robot moving in simulation. The hard part is everything between the ROS graph and the hardware.

  • Timing that looks fine in simulation but jitters on the real computer, so control loops drift.
  • Microcontrollers talking to the main computer over improvised serial protocols that drop messages.
  • Motor and sensor drivers written in a hurry for the first demo, now carrying the robot.
  • No safe state when the main computer crashes, the link drops or the battery sags.
  • Camera, IMU, lidar and wheel odometry stamped on different clocks, so fusion never lines up.
  • DDS discovery and QoS settings that start to fail as the robot gains nodes and network traffic.

We work on that layer: real-time, close to the hardware and built to fail safely.

What we build for robots

  1. ROS 2 nodes and packages. Hardware drivers, ros2_control interfaces and launch configurations in C++ and Python.
  2. micro-ROS on microcontrollers. Real-time firmware on Zephyr or FreeRTOS that joins the ROS 2 graph over serial, CAN or Ethernet. →
  3. Motor control. BLDC, stepper and servo control with encoders, current sensing and closed loops tuned on the real mechanism.
  4. Sensor integration and fusion. IMUs, cameras, lidar, ultrasonic sensors and wheel odometry, time-synchronised and fused. →
  5. Safety and supervision. Watchdogs, emergency-stop paths, heartbeats between processors and defined safe states. →
  6. Perception on the robot. Vision and detection models running on the robot’s own processors, not in the cloud. →

From prototype robot to reliable machine

  1. Map the system. Which loops run where (main computer, microcontrollers, motor drivers) and the timing each one needs.
  2. Define the interfaces. ROS 2 messages, QoS profiles and the link to each microcontroller, with timestamps and heartbeats from the start.
  3. Build the real-time layer. Motor control and safety loops on microcontrollers, so they keep running whatever the main computer is doing.
  4. Test with hardware in the loop. On the bench first, then on the robot, recording with rosbag2 and replaying to reproduce faults.
  5. Harden for the field. Start-up and shutdown sequences, fault handling, diagnostics and safe software updates.

Platforms and tools

ROS: ROS 2 Humble and Jazzy, micro-ROS, ros2_control, Nav2, rosbag2, RViz, Gazebo

Compute: NVIDIA Jetson, Raspberry Pi, NXP i.MX 8 with Yocto or Ubuntu; STM32, ESP32, Nordic and Microchip microcontrollers

Real-time and buses: Zephyr, FreeRTOS, PREEMPT_RT Linux, CAN, RS-485, Ethernet, USB

Motion and sensing: BLDC and stepper drivers, encoders, IMUs, cameras, lidar

Motion and sensing in practice

Client names stay private. The engineering doesn’t.

Detection algorithms and safety-critical firmware for a device built at over a million units

View case studies

A low-power wearable medical device, from concept to pre-production

Read the case study

More robotics work

A USB-controlled three-axis gimbal test platform with BLDC and stepper motor control, and recent ROS 2 work we can talk through under NDA.

Ask about this work

Frequently asked robotics questions

Do you work on the ROS 2 side or the embedded side?

Both, and especially where they meet: the drivers, the microcontroller firmware and the timing between them. We can work alongside your autonomy or navigation team, or build the whole lower stack.

What is micro-ROS, and do we need it?

micro-ROS lets a microcontroller take part in the ROS 2 graph directly, with real topics and services. It suits sensor and actuator boards that need to stay in sync with the rest of the robot; a simple custom link can be enough for a single motor controller. We’ll recommend the one that fits.

Can the robot stay safe if the main computer fails?

Yes. We keep motor and safety loops on microcontrollers, add a hardware emergency-stop path that doesn’t depend on software, and monitor heartbeats so every part goes to a safe state on its own. Formal machinery safety assessment is a separate process; we design for it and support it.

Can you migrate our robot from ROS 1 to ROS 2?

Yes. ROS 1 reached the end of its support in 2025. We port the drivers and nodes, set up DDS and QoS, and keep the robot working during the move.

Do you use simulation?

Yes, for development and regression tests with Gazebo and RViz, but we move to real hardware as early as possible, because that’s where timing and sensor problems show up.

Can you build the robot computer’s operating system?

Yes. Yocto or Ubuntu images for the main computer, with a real-time kernel where the control loops need it.

Building a robot or an autonomous machine?

Tell us what it has to do, what it runs on and where it’s getting stuck.

An engineer will read it and reply within one business day.

Talk to an engineer

Latest from the blog