CASEFlagship project

Autonomous mobile manipulator —
designed and built by one engineer

A ROS2 robot for retail environments: Symovo AGV base, igus lift and a UFactory xArm 6 with a custom gripper — taken from concept to a robot operating among people in 18 months, by a single engineer.

1 engineer, end to end 18 months: concept → operation ROS2 · Docker · WebRTC In production use
50–70 msteleoperation control response over WebRTC
70–120 msend-to-end depth-camera video latency
18 mofrom first concept to operation
1engineer: mechanics, electronics, software, ops

The problem

Retail and warehouse work is full of tasks that are too varied for classic fixed automation, but too repetitive for people: picking items, moving stock, working shelves. The goal was a mobile robot that can both drive and manipulate — and that a remote operator can take over at any moment when autonomy runs out.

Constraints that shaped everything: the robot works among people, so behavior must be predictable and observable; the arm moves constantly, so fragile cabling along the arm was not acceptable; and teleoperation had to feel immediate — anything above ~100 ms control delay is unusable for precise work.

What was built

  • A mobile manipulation platform: Symovo AGV base + igus lift + UFactory xArm 6 with a custom gripper.
  • An onboard Linux computer running per-device services orchestrated with Docker — each hardware unit has its own isolated service with health checks.
  • Real-time WebRTC teleoperation: joystick input streamed with 50–70 ms response; the robot also runs tasks autonomously and semi-autonomously.
  • Cable-free vision: a RealSense depth camera on the gripper streams color + depth over WebRTC to the onboard CPU — no cabling along the arm — with double-NAT traversal to an external WebRTC server.
  • Monitoring, logging and remote diagnostics as first-class services — the robot is operable and debuggable remotely.

System architecture

MobilitySymovo AGV base — navigation and positioning in retail aisles
Vertical axisigus lift on a dryve D1 motion controller (Modbus/TCP, CiA 402) — driven by our own open-source driver
ManipulationUFactory xArm 6 + custom gripper
VisionIntel RealSense depth camera mounted on the gripper, streamed over WebRTC (color + depth)
Onboard softwareROS2 nodes + per-device services in Docker on embedded Linux; health checks and watchdogs per service
TeleoperationWebRTC control channel, 50–70 ms response; browser-based operator station; double-NAT traversal via external WebRTC server
OperationsLogging, monitoring, remote access and diagnostics services — designed for production, not for the lab

Hard problems worth mentioning

  • No public driver existed for the igus dryve D1 lift controller — so we wrote one and open-sourced it (Modbus/TCP, CiA 402). It is now used by other integrators.
  • Latency budget: keeping the full control loop at 50–70 ms and video at 70–120 ms across WebRTC with double-NAT traversal required careful pipeline design — not just "use WebRTC".
  • Reliability engineering: per-device Docker services with health checks mean a failed camera or controller restarts in isolation — the robot degrades gracefully instead of falling over.

What this proves

We can take a multi-vendor hardware stack (AGV + lift + arm + camera) and make it behave as one predictable system.

We can deliver production-grade reliability — watchdogs, health checks, remote diagnostics — not just a demo that works once.

When the ecosystem has a gap (a missing driver, a missing tool), we build it and publish it instead of working around it.

Open source from this project

  • GitHub dryve-d1 → — async Python driver for igus dryve D1 motion controllers (Modbus/TCP, CiA 402), with simulator and tests.
  • GitHub janus-camera-stack → — WebRTC camera streaming stack for robots and edge devices: layered control plane, gateway-driven recovery, dependency-free browser player.

Have a machine, device or robot that needs this level of engineering?

Most projects start with a fixed-price Feasibility & Architecture Sprint (1–2 weeks) or a Hardware-to-Software Integration Sprint (~10 days).

Get in touch How projects start