Software, fleets and safety

A robot that works in a lab still has to ride a lift, share a corridor with another brand's robot, take a software update without bricking, survive a hacker in Bluetooth range and pass a safety review. That plumbing decides whether a deployment lives or dies, and in 2026 most of it is owned by the robot maker, not the customer. Anyone running robots in buildings works in this layer every day.

The stack in six layers

Every commercial robot runs two software worlds stacked on each other. The bottom world is classic engineering: small chips that switch motor current tens of thousands of times a second, a real-time operating system that never misses a deadline, and a message bus that moves sensor readings around the robot. The top world is learned and connected: navigation, planning, the vision-language-action model that turns camera pixels and a sentence into movement, and the fleet cloud that talks to the customer's building. The research behind this primer puts the motor current loop at 10 to 40 kHz and the learned policy at 50 to 200 Hz verified Sep 2026.

Who controls each layer decides where outside firms can build. Firmware and the real-time layer belong to the maker and rarely change after launch. The autonomy layer is where the robot foundation models live, and in 2026 it is eating downward: Figure's Helix 02 replaced 109,504 lines of hand-written C++ balance code with a 10 million parameter network running at 1 kHz verified Jan 2026. The fleet cloud and the customer integrations are where buildings, venues and service firms meet the robot, and where most commercial friction sits.

ROS 2, the message bus

ROS 2 (Robot Operating System 2) is middleware, despite its name. It gives you a way to split a robot's software into small programs called nodes (a camera driver, a map builder, a motor controller) written by different people, and three ways for them to talk. It runs on top of DDS, an industrial publish and subscribe standard with quality-of-service settings; eProsima Fast DDS, Eclipse Cyclone DDS and RTI Connext are the common implementations, and Zenoh is the newer transport unverified.

The ROS 2 toolbox integrators name most often:

• Nav2: mobile robot navigation. Maps, costmaps, planners and controllers, orchestrated by behaviour trees unverified.
• MoveIt 2: collision-aware motion planning, inverse kinematics and grasp pipelines for arms unverified.
• ros2_control: the standard socket between software and motors. A controller manager runs a real-time read, update, write loop, and each driver exposes its joints as command and state interfaces verified.
• micro-ROS: a ROS 2 client for microcontrollers running FreeRTOS, Zephyr or NuttX unverified.

Lyrical adds an events-based executor that uses 10 to 15% less CPU than the older single and multi-threaded executors verified. Who runs ROS 2 inside a production humanoid is mostly not public. The research treats it as the research standard that also ships in products "with care": universities, integrators and many wheeled robot makers build on it, while the vertically integrated humanoid labs publish little about their internal plumbing.

Simulation and digital twins

A simulation platform is a physics video game for robots. You use it to train learned controllers, to test software before it reaches a customer, and to generate synthetic data. A digital twin is a simulation of one specific site or machine kept in step with the real one, so you can rehearse a change (a new route, a new shelf layout) before you make it.

Scale is the point. Figure trained the whole-body controller in Helix 02 across more than 200,000 parallel simulated environments verified. A rule of thumb in the research is that about 8 simulated samples are worth one teleoperated sample estimate. The catch that every engineer in Shenzhen will confirm: vision and motion simulate well, contact and friction do not, so sim-to-real transfer still needs real robots.

Fleet management: many robots, one building

One robot is a gadget. Twenty robots from three brands in a hospital is a traffic problem. A fleet management system holds the maps, assigns tasks, plans routes so robots do not meet head-on in a doorway, calls lifts and opens doors, pushes updates and reports uptime. Multi-robot dispatch is the task-assignment part: which robot takes which job.

Every maker ships its own cloud platform. Pudu runs separate web platforms for its distributors, for venues and for authorised service partners, plus two apps verified Apr 2025. Gausium and Avidbots run their own fleet clouds. Brain Corp's BrainOS says it runs on 50,000+ robots vendor claim. Each of these is a walled garden: it manages its own brand well and nothing else.

Two open standards try to connect the gardens:

Why Singapore matters here

Open-RMF was born in Singapore. The National Robotics Programme co-launched the framework in 2018 with Changi General Hospital, the Centre for Healthcare Assistive and Robotics Technology (CHART), Synapxe (then IHiS), HOPE Technik and the Open Source Robotics Foundation verified. The health minister announced RoMi-H, the hospital version, in Jul 2018 verified. Since 2024 the Open Source Robotics Alliance governs it verified. Changi General Hospital now runs a RoMi-H Empanelment Programme for vendors whose robots integrate with its middleware verified 2025: a local procurement gate you can plug into.

Singapore also has a national standard for how robots talk to buildings. SS 713:2025 covers robot-to-infrastructure communication for lifts and doors, promoted from the earlier technical reference TR 93 verified. Lift integration and access control integration are the two jobs every delivery robot deployment needs and every building owner worries about. Local firms already sit in that path: Botsync sells vendor-agnostic AMR orchestration and reports 1M+ production trips in 2025 verified Jan 2026, and QuikBot signed lift agreements with Mitsubishi Elevator Singapore and Hitachi High-Tech Singapore in Sep 2026, logging every robot action for building owners and an insurance partner verified Sep 2026.

APIs, SDKs and the access tier

An API is the menu of commands a maker's cloud or robot accepts from outside software: "send robot 7 to table 12", "report battery". An SDK is the kit of libraries and documents that lets your engineers use that menu. Secondary development is the Chinese industry phrase for building your own application on someone else's robot.

Access comes in tiers. Unitree sells a base humanoid and an EDU version that opens the developer SDK and low-level joint control (see Chinese robots for prices). The warranty then pushes back: Unitree excludes "damage in developer mode from custom programs" verified Sep 2026. The owner reports in the reliability chapter show why: learned controllers written by labs overheat ankles and break wrist gears. The maker gives you the keys and makes you pay for the crashes.

Updates, telemetry and remote help

An OTA update (over the air) pushes new software to a robot through the network. The standard design keeps two copies of the system (A and B partitions) so a bad update rolls back to the old one unverified, and model weights now ship like app updates. Telemetry flows the other way: pose, battery, faults and logs stream to the maker's cloud. Pudu's privacy policy says its robots send operation logs and "dirty data" images to servers in China to train its algorithms verified Apr 2025.

Remote operations and maintenance is the service built on that link: a technician in another city sees the robot's state, clears a fault, or takes over by teleoperation when autonomy fails. 1X sells this openly as "Expert Mode" for its home robot. Gausium says it solves 40% of problems remotely verified 2022. The same link that makes remote help possible is the main attack surface, which is the next section.

Cybersecurity: the Unitree record

Cybersecurity for robots means keeping strangers from taking control of a machine that moves, and data security means keeping its cameras, maps and logs from leaking. The best-documented case is Unitree, the maker whose robots fill labs, universities and some police departments.

• Mar 2025Go1 remote-access backdoor, CVE-2025-2894

  Researcher Andreas Makris found a vendor tunnelling service that let outsiders reach Go1 quadrupeds. verified

• 20 Sep 2025UniPwn

  Hard-coded encryption keys and command injection in the Bluetooth Wi-Fi setup gave root access to Go2, B2, G1 and H1. It was wormable: an infected robot could infect others in Bluetooth range. Unitree said on 29 Sep 2025 it had "completed the majority of the fixes". verified

• Sep 2025G1 telemetry to China

  Alias Robotics showed a G1 connecting to servers in China within seconds of power-up, then about every 5 minutes, with potential audio, video and spatial data. Their advice: use Wi-Fi only and turn Bluetooth off. verified

• 27 Aug 2026UniBLEed and a second G1 EDU root flaw

  An unauthenticated 1,050-byte Bluetooth write overflows a 500-byte buffer to get root, and a path traversal reaches root on the locomotion computer, tested on firmware V1.5.2. Bluetooth issues were unresolved at disclosure. verified

Two quotes from the researchers, via IEEE Spectrum, frame the problem: "Robots are only safe if secure" (Víctor Mayoral-Vilches) and "There will never be a 100 percent secure system" (Andreas Makris) verified. The standards now agree. ISO 10218:2025 requires you to consider cybersecurity wherever it could defeat a safety function, and the EU Machinery Regulation adds cyber-safety for safety software and data verified.

What a venue's IT team will ask you: which network the robot joins (a guest Wi-Fi next to payment terminals is a bad answer), whether Bluetooth is on, where data goes and how often, and who can push updates. Personal data in Singapore falls under the PDPA unverified scope; no robot-specific data-access law turned up in Singapore or ASEAN. Some makers design for this: Pudu says its cleaning robots carry no microphones and keep camera frames in runtime memory only unverified. A firmware version check, a Bluetooth exposure test and an outbound traffic capture are a sellable audit line.

Safety: what stops a robot hurting someone

Functional safety is the engineering discipline that proves a machine's safety functions work when something fails: a sensor dies, a wire breaks, software hangs. Two standards set the grades. IEC 61508 grades electronic safety systems by safety integrity level, SIL 1 to SIL 4. ISO 13849 grades the safety parts of machinery by performance level, PL a to PL e verified. A safety certification is a test lab's statement that a product meets such a standard.

The safety functions you will see on a spec sheet:

• Emergency stop: the red button. Cuts motion immediately. On a Pudu robot, a pressed or damaged e-stop is a listed reason the robot will not power on verified.
• Protective stop: the controller halts the robot when a safety input trips, such as a light curtain or a door switch.
• Speed and separation monitoring: sensors track how close a person is, and the robot slows, then stops, as the gap shrinks.
• Power and force limiting: the robot may touch you, but only below force limits set per body region, from tens of newtons to about 150 N quasi-static verified. Collision detection through motor current or torque sensors is how it notices contact.

Why a legged robot has no safe state

Most machine safety rests on one idea: when in doubt, cut the power. A wheeled robot or an arm with brakes stops where it is. A humanoid that loses power falls over, and a heavy metal body falling beside a person is the hazard. That is why no published safety standard yet covers an actively balancing humanoid in a factory. ISO 25785-1, for "dynamically stable industrial mobile robots", is the first ISO work item for robots that fall when power is cut; it was a committee draft in 2026 with publication expected 2026 to 2027, and the US delegation includes A3, Agility Robotics and Boston Dynamics verified. Until then, deployments rely on risk assessments under ISO 10218, ISO 13849 and IEC 61508, fenced or zoned operation, and customer sign-off. At BMW, the lessons from Figure's humanoid pilot included revised safety concepts with extra barriers and partitions verified.

The standards list, status Sep 2026

Incidents and lawsuits: the sources behind this chapter hold no court ruling on a robot injury. The closest public data point is financial. China's first embodied-robot insurance claim, in Apr 2026, paid ¥5,976.87 after a robot tipped over at work and damaged its camera and parts verified. Insurers are writing cover with almost no loss history, which matters for the next chapter.

Singapore rules for robots at work and in public

Singapore's National Robotics Programme lists the standards that apply locally: SS 713:2025 for robot-to-infrastructure communication, SS ISO 13482:2017 for personal care robots, SS ISO 10218-1 and -2 for industrial robot safety, SS ISO 18646-1:2017 for wheeled service robot performance, TR ISO/TS 15066 for cobots, and SS ISO 8373 and 19649 for vocabulary verified. TÜV SÜD PSB and SGS run robot safety testing in the region, covering electrical, mechanical, functional safety, cybersecurity, EMC and performance, and SGS issues ISO 13482 certificates for service robots verified. Audit prices are not public.

What is missing matters as much. Lifts in Singapore have a periodic in-service inspection regime; the research found none for service robots unverified. Certification is type testing before sale, done once per model. No rule found requires robots anywhere, and no licence regime for robots in public spaces turned up. In practice the gatekeepers are the building owner (lift and door access), the venue's IT team (network and data), the hospital's procurement list (RoMi-H empanelment) and the insurer.

Terms in this chapter