Plan AMR charging around the work, not the battery headline

The buyer question is about replenishment

A robot can have enough battery capacity for an attractive demonstration and still lack a workable charging schedule for production. The question is not simply how long it runs. It is whether each robot can replenish the energy used by the planned work, within the available time, without taking essential transport capacity away when operations need it.

RobotAtom recommends two separate planning checks: a shared charger-time budget and a per-robot time budget. They expose different problems. Additional chargers cannot rescue a robot whose own work, charging and docking already exceed the operating window. Conversely, individually feasible robots can compete for too little shared charging capacity. Neither check replaces a time-resolved fleet simulation or a site trial.

Keep manufacturer values attached to their conditions

MiR's current MiR250 specification distinguishes active operation with maximum payload from no-payload operation and standby. It also qualifies its charging ratio as an upper-bound claim and warns that local conditions and application setup can change specifications. A headline runtime is therefore not a universal productive-time assumption. Record the exact configuration and operating conditions supplied for your project.

OTTO's charging explanation, published on 15 December 2025, describes its fleet manager sending robots to charge between jobs. Its stated charging times use a 10-to-90-percent band and differ by model. Those are manufacturer descriptions, not RobotAtom performance measurements. Do not combine a runtime from one battery band with a charging duration from another and treat the result as a proven duty cycle.

Write down one comparable set of inputs

For an initial budget, group robots with comparable duties and batteries. Define the repeated daily operating window, required productive hours per robot, productive runtime between the agreed charge limits, recharge time for that same interval, off-task travel and docking, compatible charger count and usable hours per charger. Keep battery reserve inside the agreed runtime assumption rather than applying an unexplained percentage twice.

Ask where each number comes from: a measured route, a provider estimate, a specification or an illustrative assumption. Preserve that distinction in the project brief. If charging access is restricted during a cleaning window or an area closure, reduce the available charger window. If the demand has a sharp peak, keep its timing separately; daily averages do not show whether a robot is available at that peak.

Compare the stated charge bands first — added 15 October 2026

Runtime and recharge duration need a shared interval before they can become a replenishment assumption. Record the lower and upper state-of-charge endpoints covered by each estimate. A runtime figure measured across one interval and a charge duration across another leave an input gap, even if both figures came from reputable manufacturers.

The MiR250 public specification page, checked 15 October 2026, distinguishes payload, no-payload and standby operation and qualifies its charging-to-runtime ratio. The reviewed public page does not state the starting and ending charge percentages for those figures; its detailed specification portal requires sign-in. Treat the endpoints as unknown unless the applicable project evidence supplies them. Do not infer a full-discharge test from a headline operating time.

OTTO’s charging article, published 15 December 2025 and checked 15 October 2026, explicitly gives a 10–90% band for its model-specific charging times. It does not supply a paired runtime over that same interval under the buyer’s conditions. That source answers one part of the question, not the whole duty cycle. An OTTO charge band also cannot qualify a MiR runtime figure.

For a hypothetical comparison, a runtime estimate covering 20–80% and a charge estimate covering 10–90% describe different intervals. Even two ranges with the same span, such as 10–80% and 20–90%, are different bands. Do not convert one duration into another by multiplying by the ratio of percentage points: the reviewed sources do not establish a linear battery or charge curve.

The planner now has a separate endpoint check. Enter the runtime band in ascending order and the charging band in ascending order; discharge and recharge run in opposite directions through those bands. Missing, out-of-range or reversed entries withhold comparison. Different endpoints stay flagged. Equal endpoints establish only a match between the stated intervals; they do not validate either duration.

Keep model, battery, charger, payload, duty cycle, temperature, source date and reserve policy with the supporting estimate in your controlled brief. Ask the provider for a matched pair and the conditions behind it. A matching band cannot compensate for a different battery condition or application. The local comparison does not fetch documents, change the budget above or simulate state of charge.

Export the comparison, including unknowns, before using a runtime/recharge pair in fleet planning. Then return to charger-hours, robot availability and the busiest work window. This added check is RobotAtom’s input-review method, not a manufacturer-approved battery model, charging instruction or operating permission.

Run the two arithmetic checks

Our charging-window calculator uses a steady-state budget. Multiply fleet size by productive hours per robot, then divide by productive runtime per recharge interval. This gives average recharge equivalents. Multiply by the matching charge duration to obtain charger-hours required. Compare that with compatible chargers multiplied by usable hours per charger. The rounded-up charger count is only an arithmetic lower bound.

Then calculate time per robot: productive hours plus its recharge equivalents multiplied by charging time and off-task docking time. Compare that total with the robot's operating window. This second check matters because charger capacity and robot availability are not interchangeable. Fractional recharge equivalents are an average across repeated days; the model does not claim to schedule partial visits or simulate battery state.

Check the busiest window before accepting the daily average

The two daily budgets can pass while the operation is short of robots at 11:00. Name the start and end of the busiest window, the task or route that matters, and the minimum number of robots that must be available at the same time. Keep movement demand separate from robot count: six available robots are not proof of six completed moves. Record who owns a missed movement and how long the operation can tolerate it.

Ask the provider how its proposed charging policy overlaps that same window. Count robots actually on charge, travelling to a charger, waiting for access, unavailable for another reason and held in reserve. Do not double-count a robot across those states. A daily charger-hour surplus says little about the overlap. OTTO's fleet-estimation guidance explicitly asks facilities to tell the vendor about peak periods; its separate charging guidance describes between-job charging for OTTO robots. Neither source guarantees a feasible peak schedule for a different configuration or site.

As an invented screening example, suppose an eight-robot fleet has two robots planned to charge and one otherwise unavailable during a named two-hour peak. Five remain physically available. If operations needs six concurrently, the simple count has a one-robot gap before route timing, endpoint capacity, battery reserve or traffic are tested. Shift one charge visit to another hour in a second scenario and check the count again—but do not assume that the battery can safely or practically sustain the move.

Use the planner to export both scenarios and the assumptions behind them. A scenario without a count gap still needs a time-resolved provider schedule or simulation and a representative site trial. Retain timestamped missions, state of charge, charging starts and finishes, waits for a charger, interruptions, late tasks and decisions to restart. Compare those records with the agreed peak requirement and the exact robot, payload, battery, charger and software configuration. This is an availability screen, not a throughput calculation or an electrical or safety design.

An illustrative calculation—not a fleet recommendation

Suppose eight robots each need 12 productive hours in a 16-hour window. Assume six productive hours between recharge intervals, one hour to replenish that interval and ten minutes of off-task travel and docking. The fleet needs 16 average recharge equivalents and 16 charger-hours. Two chargers available for 16 hours provide 32 charger-hours. Each robot uses about 14.3 hours for work, charging and docking.

Those invented teaching inputs show no average time deficit, but do not prove the fleet can meet a real schedule. If both chargers become inaccessible together, or robots require replenishment during the same demand peak, the averages hide the constraint. The calculator deliberately reports open scheduling questions instead of a green deployment-ready score. Change the inputs to see which assumption creates the deficit.

Test the hours that disappear

A usable charging window is not the same as the time printed on the shift roster. A station may be compatible with the robot but unreachable during cleaning, isolated for maintenance or behind an access restriction. Start with the hours genuinely available to every charger in the base budget. Then keep an additional unavailable period separate so operations can see what changes when that assumption fails. Do not subtract the same closure twice.

The planner now compares one additional unavailable period with the unchanged work demand. Enter how many chargers are unavailable together and for how long, within the base usable window. It removes their lost charger-hours from the shared capacity; it does not reduce the work requirement or silently change the battery reserve. Different durations or overlapping outages need a time-resolved plan rather than being added into this simple scenario.

For an invented example, keep the eight-robot workload above: 16 charger-hours required. If two chargers each have ten usable hours, capacity is 20 charger-hours. Make one charger unavailable for five of those hours and only 15 remain, leaving a one-charger-hour deficit. Extra robots do not restore those lost charger-hours. Nor does a zero deficit prove that a robot with a low battery can wait until a station becomes available. These are arithmetic observations, not a fleet recommendation.

Attach a period and reason, an evidence or assumption reference, and an owner to the scenario. A maintenance schedule, an observed blocked approach and a hypothetical outage are different kinds of evidence. The download retains the entries and flags missing context; it does not turn an assumption into a measured result. Ask the owner when access resumes, which tasks are affected and what operating evidence would justify the proposed response.

This is RobotAtom's planning method, not a manufacturer outage guarantee. OTTO's charging guidance describes between-job charging for its own fleet, while its fleet-estimation guidance asks buyers to disclose peaks and access restrictions. The practical question for your provider is whether the configured robots can replenish within the remaining windows under the actual work and reserve policy. Retain battery state, charging events, waits and missed tasks in the representative trial. Specialist electrical and safety decisions remain outside this calculator.

Turn the budget into an acceptance conversation

The next step is a time-stamped operating test with the responsible provider: representative loads, the intended charge band, the busiest work window and the actual route to the charger. Record work demand, charging starts and finishes, docking delays, queue time and unmet tasks. Agree beforehand what happens when a charger is unavailable and who reviews the resulting capacity shortfall. Do not alter safety functions to achieve a timetable.

For adopters, this makes infrastructure and scheduling assumptions visible before rollout. For providers, it replaces an open-ended battery question with a workload they can engineer against. RobotAtom brings the work, constraints and acceptance evidence into the complete solution. Use the free calculator to export your assumptions, then discuss the result with your operations and delivery team. Electrical design, safe installation and final fleet sizing remain specialist engineering decisions.