Technology
ROS 2 Development
ROS 2 is the middleware behind most of the robotics we ship - because the ecosystem, the simulation tooling, and the modular architecture save months of foundation work. We build production autonomy stacks on Humble and Jazzy, integrate with real sensors and real actuators, and take them to platforms operating outside the lab.
What it is
What ROS 2 is and when it fits.
ROS 2 is the second-generation Robot Operating System - a middleware, a set of libraries, and a large ecosystem of packages for perception, navigation, motion planning and behaviour. It replaces ROS 1’s ROS Master with a DDS-based transport (making it multi-machine and real-time capable), and adds security and QoS features suitable for production robotics.
We reach for ROS 2 as the default for any robotics program - mobile, arm-based, or hybrid - unless a hard constraint (safety certification path, ultra-tight resource envelope, existing non-ROS stack) rules it out. The Long-Term Support releases (Humble, Jazzy) are stable enough for production and the community support is worth the ecosystem tax.
Where we use it
ROS 2 Development in shipped programs.
- Autonomous zero-turn mower - Nav2 for outdoor navigation, custom controllers for the mechanical platform, hard safety interlocks
- AMR integration in warehouse workflows - Nav2 with fleet coordination and OT-side handshakes
- Arm-based inspection cells - MoveIt 2 for motion planning with vision-driven pick targets
Patterns and gotchas
Patterns that pay off, and ones that surprise first-timers.
Simulate first, always. Gazebo (or NVIDIA Isaac Sim for Jetson-class targets) is not optional. Every scenario the robot must handle gets a sim test before it gets a physical test - the physical hardware time is where you catch the sim-to-real gap, not the algorithm bugs.
Use micro-ROS for the MCU side. Modern robotics often has ROS 2 nodes on Linux compute and micro-ROS nodes on MCUs (motor drivers, safety monitors). Zenoh middleware bridges cleanly. The alternative - custom protocols between subsystems - always regresses.
Safety is architectural, not additive. Redundant emergency stops, monitored speed, guarded zones - these are designed into the stack from day one. Bolting them on after the autonomy demo works produces autonomy that cannot be certified. See our robotics practice for the safety approach.
Related
How this fits our practices.
ROS 2 Development is a lens on our robotics development practice. Adjacent tools and services: edge AI, computer vision, embedded Linux, STM32 development.
Tell us what you’re building.
Send the constraint that worries you most - a latency budget, a power budget, a certification date. We’ll tell you straight whether we’re the right team.