M8-T6 — Docking, Charging and Fleet Operations

Learning objectives

After this lesson, you should be able to:

• Describe how a robot docks: approach, alignment with a marker or beacon, final creep and a check that charging started.
• Set a charge threshold and size the number of chargers from the work and charge times.
• Use utilization, Little’s law and a one-server queue to estimate waiting at a shared dock or lift.
• Choose fleet metrics (throughput, wait, on-time rate, utilization) and say what each one hides.

The intuition

A fleet is like a shift of nurses with one rest room. Everyone works, then goes to rest. If everyone needs the rest room at the same time, a queue forms, and the people waiting are not working. If there are too many rest rooms, they stand empty and the hospital paid for nothing. The right number follows from how long people work, how long they rest, and how many there are.

Charging is that rest room. A robot works until its battery is low, drives to a charger, docks, charges, and goes back to work. The chargers are shared resources like the lanes of the last lesson: there are few of them, they take time, and a robot cannot do anything else while it uses one.

Docking is the small, precise manoeuvre at the end. A navigation stack that is good to a few centimetres in a corridor must be good to a few millimetres at a charger, because the contacts are small. It usually switches mode for this: the global planner brings the robot to a pre-dock pose in front of the charger, and a special docking controller takes over and creeps in, guided by a marker or beacon on the dock rather than by the map.

The mathematics

Docking

A robust dock sequence has stages, each with its own check:

1. Pre-dock: navigate with the normal stack to a pose a metre or so in front of the dock, with a tolerance of a few centimetres and an angle of a few degrees.
2. Detect: find the dock with a sensor that sees a marker, a reflective pattern or an infra-red beacon; check that its pose is consistent with the map.
3. Approach: a slow controller drives along the dock’s axis, correcting lateral and angle error at the speed that the contacts or funnel can tolerate.
4. Confirm: contact is made when the charging current or voltage appears; if not, back out and retry a fixed number of times.
5. Undock: reverse out along the same axis before the planner takes over again.

Docking failures are among the most common causes of a stranded robot: a marker in glare, a pose that is slightly off, a dock with something in front of it. Plan for retries, for an alternative dock and for an operator alert when the batteries are low and docking has failed.

Charge policy

E

battery energy (Wh)

P_work, P_chg

average power used while working, and charging power (W)

s_hi, s_lo

charge level at which the robot stops charging, and at which it goes to charge (fractions of E)

Batteries do not charge linearly: constant current until a threshold, then a tapering current (the “constant-voltage” phase), so the last 10 to 20 percent take disproportionately long. A common policy is to charge to about 80 or 90 percent in normal operation and only to 100 percent at the end of the day, and to go to charge not at the last moment but at a level that leaves enough energy to reach the farthest dock plus a reserve (the s_lo). Opportunity charging, topping up while a robot waits anyway, shifts work between robots.

Queues and Little’s law

Little’s law (1961) holds for any stable queueing system: the average number of items in the system equals the arrival rate times the average time each spends in it.

Real service times are not exponential, and arrivals come in bursts (shift changes, meal trays at 07:30), so treat the M/M/1 numbers as a first estimate. The shape is what matters: waiting time rises slowly until utilization reaches about 70 percent and then climbs steeply, and at 100 percent the queue grows without bound.

Fleet metrics

A worked example

How many chargers? Scout’s battery is 24 V × 20 Ah = 480 Wh. Driving and carrying use 80 W on average. The fleet policy is to stop charging at 90 percent and go to charge at 15 percent, so each cycle uses 0.75 × 480 = 360 Wh.

One charger is clearly too few (1.68 demanded). Two are enough on average, but at 84 percent utilization queues are common: the robots do not arrive at random, they run down together after a busy morning. A third charger makes the average utilization 0.56 and the queues short, at the cost of one more unit that sits idle at night. Charge taper makes the real charging time longer, which pushes the load up, so measure it rather than trust the 300 W.

A queue at the dock. Suppose robots arrive at a single docking bay at λ = 5 per hour, and each takes 8 minutes (μ = 7.5 per hour). Utilization is ρ = 5 / 7.5 = 0.67, and the M/M/1 estimate of the mean wait before service is Wq = 5 / (7.5 × 2.5) = 0.267 h = 16 minutes, with a mean queue of Lq = 5 × 0.267 = 1.3 robots. If arrivals rise to 6.5 per hour (ρ = 0.87) the formula gives Wq = 6.5 / (7.5 × 1) = 0.87 h, about 52 minutes. Thirty percent more load, more than three times as long a wait: that is the steep part of the curve.

Little’s law on the whole fleet. If the fleet completes 18 jobs per hour and a job spends 10 minutes in the system from request to delivery, there are on average 18 × (10 / 60) = 3 jobs in progress at any moment. If the dashboard shows 6 and the arrival rate has not changed, jobs have started to take 20 minutes: a queue is building somewhere.

Engineering implications and limitations

Charge before you must

The charge threshold has to cover the distance to the dock from anywhere the robot may be sent, with a reserve for battery ageing, cold, and a detour around a closed corridor. Compute it from the worst case: energy per metre from the logs, times the longest route to a charger, times 1.5 as a first margin. A robot below its reserve refuses new jobs and goes to the nearest free dock, even in the middle of a mission queue.

Put the chargers off the main route

A dock in a through-corridor lets a waiting robot block everyone. Place docks in alcoves, give each a waiting place that is not on the route, and treat the dock and its waiting place as resources in the traffic rules of the last lesson (reserve, lease, capacity).

Assign jobs with charge in mind

A job scheduler that ignores the battery sends the robot with the highest charge to every urgent job and runs it flat. Include the energy needed for the job plus the trip to a dock in the assignment, and rotate work so that charging is spread out in time instead of synchronised.

Measure in percentiles

Average waiting time looks fine long after patients have noticed. Report the median and the 95th percentile of the time from request to delivery, the time spent queued for lifts and docks, and the number of jobs that missed their window. Log every docking attempt and every operator rescue with a reason, and review them weekly: the failures cluster, and they are cheap to fix once seen.

Test the failure

Run a drill: take one charger out, or a lift, and see what the fleet does. A robot docking at a dead charger and waiting there for ever is a design flaw, and so is a fleet that starts every morning with all batteries at 20 percent because the night shift never charged.

Common misconceptions

Engineering takeaways

1. Docking is a separate mode: navigate to a pre-dock pose, then a slow marker-guided approach with a confirmation that charging started.
2. Chargers needed follow from work and charge time: N × t_chg / (t_work + t_chg), plus a margin for taper and bunching.
3. Charge before the reserve is gone; the threshold must cover the longest route to a dock.
4. Waiting grows steeply as utilization of a shared resource approaches one; Little’s law (L = λW) links queue size, rate and time.
5. Report throughput, on-time rate, wait percentiles, utilization and rescues together; each one alone hides something.

References and further reading

The queueing result used above and the description of a large warehouse fleet; Nav2’s documentation covers its docking server.

• J. D. C. Little, “A proof for the queuing formula: L = λW”, Operations Research 9(3), 1961.
• P. R. Wurman, R. D’Andrea and M. Mountz, “Coordinating hundreds of cooperative, autonomous vehicles in warehouses”, AI Magazine 29(1), 2008.
• Nav2 documentation, “Docking Server” (opennav_docking), docs.nav2.org.

Knowledge check

Three conceptual questions. Write an answer, then reveal the explanation. Your answers stay in your browser.

What’s next

That completes the module. Next: running navigation on real systems, starting with how Nav2 is built.

Related content

Nothing below is required to finish this lesson.

• Before
  M8-T5: Traffic Management, Deadlock and Livelock

  Recognise deadlock and livelock, and use reservations, one-way lanes and priority to prevent them.