Service robot programming

What we do for the client

We take your service platform — a robot for delivery, disinfection or reception — and write the working software and behavior scenarios for it. Service robot programming in our delivery means deploying the stack on the onboard computer, setting up the lidar, camera and wheelbase drivers, building the room map and the route logic. We don't manufacture the chassis itself and don't print the body — the client's equipment does the hauling and disinfecting, and we prepare the control layer that makes it do this predictably. The work includes integration with your systems: calling an elevator, opening doors, dispensing an order, passing statuses to an accounting system via an API. In the end you get not a demo but a tuned machine that performs the set tasks in your building.

How it really works

The robot continuously builds and refines a map of the space from lidar and odometry data, and then localizes itself on that map in real time. On top of localization works the planner: it lays a global path to the goal and immediately recomputes the local trajectory, avoiding people, carts and temporary obstacles. Each applied action — enter a ward, stand at the counter, go around a queue — is described by a separate scenario with conditions and reactions to failure. We tune the speed thresholds, the safety zones and the behavior on loss of the goal, so the machine stops rather than rams into an obstacle. This whole combination of navigation and scenarios is what turns the client's hardware into a working service robot.

Where service robotics came from

The starting point is generally considered to be the robot Shakey, developed at the Stanford Research Institute (SRI) from 1966 to 1972. It was the first general-purpose mobile robot capable of reasoning about its own actions: it perceived the surroundings, built a plan, broke a command into steps and recovered after an error. Commercial service robotics started later: Joseph Engelberger founded Transitions Research Corporation in 1984, and in 1988 he supplied the first hospital robot, HelpMate, to a hospital in Danbury (Connecticut). HelpMate delivered medications and samples across the floors on its own, and within a decade such machines were already working in more than a hundred hospitals. It's precisely this line — from the research Shakey to the production HelpMate — that set the logic of navigation and scenarios on which all of today's service machinery stands.

Why the software part is critical

In a service robot the physics of the chassis is secondary — the outcome is determined by the precision of localization and the quality of the scenarios. A positioning error of ten centimeters means the machine won't fit through a doorway or will stop short of the dispensing counter; a mismatch between the map and reality leads to getting stuck in a corridor. That's why tuning the planner parameters, filtering sensor noise and calibrating the safety zones affect the result more than the characteristics of the motors. The robot drives and disinfects with its own hardware, but the software guides it, and it's precisely on the software that whether it gets there without collisions and operator intervention depends. Competent service robot programming isn't an extra option to the platform but the condition without which it remains a motionless set of components.

What stack we work on

The base tool is ROS2, an open robotics framework: on it the node architecture, the message exchange between sensors and control, and the launch and diagnostics of modules are built. We implement navigation on the Nav2 stack — the standard solution for ROS2, responsible for building the map, localization, global and local path planning and behavior trees. The combination of ROS2 and Nav2 covers the robot's whole route: from receiving the lidar's point cloud to a specific command to a drive. The applied logic — the order of tasks, reactions to events, integration with elevators and accounting systems — we write on top of this stack for the client's specific facility. The stack is open and maintained, so the solution isn't tied to a single vendor and develops along with the ecosystem.

When the key tools appeared

ROS (Robot Operating System) itself appeared at the company Willow Garage: the project's repository was created on 7 November 2007, and version 1.0 came out in 2010 and quickly became the industry standard for research and development. The first generation had architectural limitations for serial and multi-robot tasks, so it was rewritten: the first ROS2 distribution under the name Ardent Apalone came out on 8 December 2017. Nav2 developed as the successor to the old ROS navigation stack, reworked for ROS2 using approaches from autonomous transport. These dates matter in practice: we work on the current second generation, designed for industrial operation, rather than on an outdated branch. The stack is proven by time and the community, which lowers the risks during the long operation of your platform.

Why you can trust this to us

Behind the development stands a team with combined experience in IT of more than 45 years, and for us a robot is first and foremost an engineering rather than a marketing task. We don't promise miracles from your hardware: we soberly assess what the platform is capable of and bring the software up to that limit. Every scenario goes through checks in simulation and on a bench before the robot drives out into a work area with people — the production launch happens only after a run-through of off-nominal situations. We're responsible for the control layer: navigation, scenarios, integrations and the setup of the client's equipment, leaving the manufacture of the hardware to its maker. This divided approach gives a clear area of responsibility and a result that's reproducible rather than just looking good in a single demo.