Yesterday We Handed Over Anku: What It Took to Make a Medical Robot Move on Its Own

By Praveen Pandiyan, Founder & CEO, Evolve Robot Lab · 10 min read

Yesterday, we completed the autonomy-feature handoff for Anku and delivered the medical mobile robot system to its next stage of field use. I am proud of that sentence—but I also want to be precise. What we handed over was a real supervised autonomy capability: LiDAR mapping, localisation, ROS 2/Nav2 navigation, a delivery compartment, safety stops, diagnostics and a client workflow. It was not a staged video in which every unknown was edited out.

The brief sounded easy when we first said it

Move a medical package through an indoor facility. Reach Reception. Open the delivery compartment. Wait. Close it. Return Home.

Then the real questions arrived. What if a person crosses the corridor? What if the LiDAR stream pauses? What if the map is slightly wrong? What if the door says it is closed when it is not? What if the laptop disappears from the network? What if the robot has enough battery to move, but not enough stable power to move safely?

That is the point where a mobile robot stops being a student project and becomes an engineering responsibility.

What we actually built

Anku is a compact differential-drive mobile platform designed for structured indoor movement. The platform baseline gives us a 10 kg payload zone, an 8+ hour runtime target, ROS 2 Humble, 2D LiDAR SLAM and a Jetson Nano compute layer. For this medical project, the robot also needed a delivery compartment, camera, joystick fallback, watchdogs and a control panel that an operator could understand.

The robot-side Raspberry Pi owns the physical world: the Mega motor controller, LiDAR, camera, door servo, joystick and command deadline. The client laptop runs the heavier map, localisation and Nav2 work. If the laptop disappears, the robot does not keep obeying an old velocity command. The Pi and motor watchdog bring it to a stop.

The mission became our definition of done

We did not want “autonomy” to mean a robot that drives randomly around a room. We defined a route: Home → Reception → open the delivery door → wait 60 seconds → close and acknowledge → return Home.

That route gave us honest checkpoints. Did localisation hold? Did the planner see a clear path? Did the robot arrive with the right heading? Did the door open only after navigation succeeded? Did the system stop when data was stale? Could we recover without pretending the failure had not happened?

The part nobody sees in a launch photo

The hardest work was not writing “go to Reception.” It was tuning a small machine to behave predictably in a real corridor. We checked wheel feedback, corrected turning behaviour, verified the robot footprint, saved a known Home pose and tested the low-speed controller. One bounded floor run reached approximately 0.0785 m/s over the test pulse, close to the 0.08 m/s diagnostic target.

That number mattered because it came from the floor. It also had a boundary: it was a speed check, not proof that the complete medical mission was ready to run unattended.

What went wrong—and why we kept the stops

One moving run stopped early because fresh LiDAR scans were unavailable. A later read-only probe showed the sensor stream healthy again, but the mission was right to stop at the time. A robot should not say “probably fine” when its eyes have gone quiet.

We also saw intermittent undervoltage flags during diagnostics. We kept that as a real gate. We worked through turning and progress-checker behaviour. We treated an unknown delivery-door state as a reason not to depart. We kept the hall map labelled draft until the physical checks are signed off.

What we handed over yesterday

On 26 October, we packaged the client handoff: source code, saved map and waypoints, calibration, the Humble Nav2 profile, verified V7 firmware and source, test results, wiring instructions and the supervised field-demo workflow. The autonomy feature was no longer a concept in a presentation. It was a system another team can inspect, start, stop, test and improve.

I am deliberately calling it a supervised low-speed autonomy handoff. The final end-to-end Home-to-Reception-to-door-to-Home run still needs stable power, a signed-off map and a clean physical validation session. That honesty is not a weakness. It is how we protect the people who will work near the robot—and how we build the next version from evidence.

Why this one matters to me

Anku is not the largest robot we have built. It is not the loudest demo. But it forced us to bring hardware, firmware, ROS 2, maps, network behaviour, human controls and operational discipline into one real handoff.

Medical environments make that standard visible. A robot carrying a package is still carrying responsibility. It has to be useful without becoming unpredictable, autonomous without becoming unaccountable, and impressive without hiding the conditions under which it works.

That is the kind of robotics we want to build at Evolve Robot Lab: made here, tested on real floors, and honest about the distance between a prototype and a dependable system.

What we do next

1. Revalidate stable power with the Pi, LiDAR, Mega and door load together.
2. Complete map, footprint and clearance checks at the client site.
3. Run and record the supervised end-to-end mission with known door state.
4. Let the client team maintain site maps and destinations without our private development setup.
5. Use the field data to improve Anku and the next medical delivery robot.