Precision Docking for Wireless Charging
An autonomous robot can map a warehouse, dodge forklifts, and carry parts across a building. But all of it is useless if it can’t reliably do one simple-sounding thing: park itself on its charger, every time, with no human nearby.
This is the docking problem. On the OpenAMRobot platform we wanted to solve it for wireless charging — no plugs, no contacts, just the robot driving up to a pad and starting to charge. Here’s what makes it harder than it looks, the approach we settled on, and how we plan to prove it works. The full open-source work lives in the openamrobot_docking ROS 2 package, inside the platform software repository.
↑ The robot approaching the dock in simulation — the three AprilTags on the wall are the bundle the camera locks onto.
Why docking is harder than navigation
Navigating a building is a “centimeters-to-meters” problem — being half a meter off in a corridor is fine. Docking for wireless charging is a “millimeters” problem. If the robot’s receiver coil isn’t lined up closely enough with the charger’s transmitter coil, power transfer drops or never starts.
We studied four commercial wireless chargers to learn how precise we actually need to be. The answer was both reassuring and tricky:
| Charger | Accepted position tolerance | Published yaw tolerance |
|---|---|---|
| TZBOT | ±20–30 mm | not published |
| WiBotic | ±40–50 mm | tilt only (round coil) |
| Wiferion | ±30 mm | not published |
| Xnergy | ±50 mm | not published |
| Our target | ±10 mm | ±2° |
Position tolerance is how far the robot’s coil can sit off-center from the charger’s coil and still charge at full power — beyond it, power transfer drops or never starts. Yaw tolerance is the equivalent for the robot’s rotation. The values above come from public datasheets; notably, almost no manufacturer publishes a yaw tolerance at all, which is a real gap across the whole industry.
Our target
±10 mm of position and ±2° of angle — repeatable under any normal operating condition.
The ±10 mm beats the tightest charger spec by 2×; the ±2° is a safe default for the angle nobody publishes.
The real challenge: robustness, not accuracy
Here’s the part that surprised us most. Hitting millimeter accuracy in a clean lab, in good light, is easy — almost any sensing method does it. The hard engineering problem is hitting that same accuracy every single time: under glare from a window, in a dim corridor, with motion blur, with dirt on the markers, or when a person briefly blocks the robot’s view.
That shift in mindset — from “how accurate can it be?” to “how reliably can it repeat?” — shaped every decision that followed.
The approach: a camera and a set of printed tags
After comparing the options (cameras, LiDAR, reflective markers, sensor fusion), we chose the simplest stack that meets the target: a single forward-facing camera reading a bundle of printed AprilTags mounted on the dock. AprilTags are like sturdy, robotics-grade QR codes — the camera detects them and computes exactly where the dock is.
Why this combination?
- ▸It’s the industry default. Fetch Robotics, the open-source Nav2 docking stack, and many mainstream AMRs all dock this way.
- ▸It’s the cheapest, lowest-infrastructure option. No extra sensors, no instrumented floor — just a camera the robot already has and a printed pattern on the dock.
- ▸It solves the hard axis the right way. A single tag is wobbly on angle. A bundle of two or three tags spread apart gives a wide baseline, locking down the angle far more reliably.
One refinement we found useful: making the outer tags larger and the center tag smaller. The big outer tags are easy to read from two meters away during approach; the small center tag stays inside the camera’s field of view in the final few centimeters, when a large tag would be too close to see fully. Together they keep the dock crisply in view across the whole approach.
The docking sequence, step by step
The robot doesn’t do this in one motion. It moves through a short sequence of phases, slowing down as it gets closer — and if the charger reports the alignment isn’t good enough, it backs off and retries:
The six-phase docking sequence. The robot slows from full navigation speed to a 5 cm/s crawl, with the charger’s confirmation acting as a final gate before charging begins.
The two camera-driven phases (4 and 5) are where the precision is won. In the final alignment, the robot steers purely on the live camera image — not on its map — which makes it immune to map drift or wheel slip.
↑ Final alignment — the green line marks the approach axis the robot follows straight into the dock during image-based servoing.
Throughout, brief moments where the camera loses the tags (a flash of glare, a single blurry frame) are bridged by the robot’s wheel encoders and motion sensor for a fraction of a second — just long enough to stay on track until the camera recovers.
How we’ll prove it works
A target is only meaningful if you can measure it. The plan is a bench setup with a mock dock and a ground-truth measurement system that records exactly where the robot ends up on every attempt. We then run the docking many times under the hardest conditions on purpose — low light, partially blocked tags, off-angle approaches — and check whether the spread of results stays inside ±10 mm and ±2°.
The key metric isn’t the average result; it’s the consistency. A system that’s perfectly centered on average but occasionally 25 mm off is not acceptable. One that’s always within a few millimeters is exactly what we want.
Why open source
Every AMR maker faces this same docking problem, and most solve it privately, from scratch. OpenAMRobot exists to make building blocks like this one freely available to SMEs, students, and engineers who shouldn’t have to reinvent the foundations.
The docking research, the ROS 2 code, and the decisions behind them are all open:
→ OpenAMRobot on GitHub
The open-source, modular autonomous mobile robot for affordable manufacturing and logistics.
→ openamr-platform-sw
The ROS 2 software repository — including the openamrobot_docking AprilTag autodocking package described in this article.
→ openamr (main repo)
The platform’s main repository and community entry point.
→ Autodocking & wireless charging discussion
Where this work is being planned and reviewed in the open.
Contributions, questions, and ideas are all welcome. If you’re building an AMR and tackling docking yourself, come compare notes.
This work is part of the OpenAMRobot project, developed by a robotics team at the Mechatronics Lab, BHT University (Berlin), and supported by Botshare. Thanks to Alex Reznichenko and Raj for the reviews and guidance along the way.
