The demo convinced everyone. Now the robot has to work every day, on every unit, after every update, without a PhD next to it. That is a different engineering discipline - and it is ours.
A working prototype proves the robot can do the job. Turning it into a product means making that success repeatable across units, customer sites and software releases. Three foundations make that possible:
The software needs room to evolve. Clear component boundaries and controlled dependencies help the team manage change. The architecture must also fit the production compute, operating system and licensing constraints.
Deployment needs to be routine. Reproducible installation, controlled updates and a recovery path let the team manage a fleet with confidence. Manual steps and dependence on one development laptop become harder to sustain with each new robot.
Every release needs evidence. Repeatable tests and useful field diagnostics help the team assess changes and support customers. A week of walking behind robots for every release limits how quickly the product can improve.
That is an opportunity to grow the fleet while reducing the engineering effort needed to deploy, update and support each additional robot.
02 / HOW WE SOLVE IT
We have shipped this before - on the ground, in the air, in space
Since 2010 we have taken robot software into production for mass-market cleaning robots, retail fleets, drones, and mission-critical space systems. We bring that playbook to your product:
Production architecture review. We map your current system and design the target: clear component boundaries, hardware abstraction, an explicit data model for maps/calibrations/parameters, centralised error handling and recovery, and a runtime that degrades gracefully. You get a roadmap with milestones and effort per item, not a rewrite.
Embedded platform and middleware. We size and validate the production compute (CPU/RAM budgets measured with the real stack), port hot paths from Python to C++ where needed, and define the operating-system strategy: minimal Linux (Yocto-based) images, A/B partitioning for safe updates, real-time kernel where required, licensing and cybersecurity considerations. We benchmark and select the ROS 2 middleware and its configuration for your deployment (multi-container, real-time, low-bandwidth sites) so known weaknesses of ROS 2 never disturb the functional design.
Build, package, deploy. Reproducible builds, containerised or image-based runtime (Docker on Jetson/ARM), signed over-the-air updates with rollback, provisioning of a new robot in under an hour, and a factory acceptance test with two outcomes: "ships" or "rework".
Observability and automated testing. Structured logging, metrics, health aggregation and remote diagnostics so support engineers, not developers, handle the field. Unit → integration → simulation with fault injection → hardware-in-the-loop, wired into CI so each release is proven before it leaves the building.
Hand-over. Documentation, coding standards, review process, and time embedded with your team. We are done when you no longer need us.
The goal is software your team can deploy, update and support across a growing fleet - with the tests, documentation and tooling to carry it forward.
03 / IN PRACTICE
In practice: from POC reliability to industry-grade numbers - solar-panel cleaning robots (France)
Situation. A young company had an autonomous cleaning robot working as a proof of concept and a first fleet of customer units to deliver within months.
What we did. We reviewed the architecture and the production-hardening plan, brought the reliability of their software stack to industry-grade performance figures, and designed and implemented how their software is built, tested and deployed onto robots in the field using modern standards: a minimal Linux image with A/B partitioning on the production system-on-module, resource validation of the full stack on that module, watchdogs and health monitoring, and a validation test set.
Outcome. With a small team at the customer, the delays were worked away and robots reached real customers.
Also: Porting the heaviest nodes from Python to C++ cut their CPU load by ~80%.
In practice: a ROS 2 base layer for a large German AGV builder
Situation. A large team of robot-software developers needed a common foundation to build interoperable modules on.
What we did. We created the ROS 2 base layer and target platform, benchmarked and selected the right ROS 2 middleware, and designed the deployment architecture and fleet-provisioning strategy so that known weaknesses of ROS 2 do not disturb the functional design.
Outcome. Standardised tooling across a large organisation, and new hires productive quickly thanks to the popular, easy-to-use ROS 2 APIs.
Also: The middleware work included an in-depth study of inter-container communication.
04 / WHAT YOU GET
What you get
Production architecture and a migration roadmap with effort estimates per item.
Embedded platform decision backed by measurements: compute, OS image, update strategy, licensing.
Build & deployment pipeline: reproducible images, OTA updates with rollback, one-hour provisioning, factory acceptance test.
Middleware configuration validated for your deployment.
Observability and test infrastructure integrated into your CI.
A team that can carry it: documentation, standards and coaching.
Creating a mobile robot for indoor transportation can be a challenging task, especially when it comes to overcoming hardware and software issues. This guide will provide a high level overview of the various hardware and software challenges involved in creating a mobile robot, as well as the best solutions for overcoming them.