RobotAtom decision tool · Experimental

Can your charging windows cover the work?

Compare charger-hours, robot time and the number of robots left for a named peak work window. No account or contact details required.

Illustrative inputs, not any manufacturer’s specification. Replace these with your own operating evidence. Values stay in page memory and clear on refresh; they are not sent to RobotAtom.

Use one group with comparable duty and batteries.

The repeated daily horizon, at most 24 hours.

Exclude charging and travel to the charger.

Use a measured or provider-agreed value for your load and reserve policy.

Match the same battery charge band as the runtime, not a different full-charge rating.

Robot time only; exclude charging time already entered above.

An integer. Zero is allowed to expose the missing infrastructure.

Within the daily operating window, after planned closures. Do not assume every idle minute is accessible.

Your charging-time budget

16.0 charger-hours required against 32.0 available.

1 chargers is the arithmetic lower bound for these assumptions—not a purchase recommendation.

Per robot: 14.3 hours of work, charging and docking against 16 hours available.

No average charger-time deficit in these inputs. No average robot-time deficit in these inputs.

Even when both budgets fit, simultaneous charging, blocked access or a failed charger can make the schedule infeasible. Check time-stamped demand and charging events with your provider.

Unavailable charging scenario

Subtract one additional unavailable period from the usable charger time above. Do not subtract closures already included there. This is a charger-hour comparison, not a timed charging schedule.

0.0 charger-hours removed; 32.0 remain. 0.0 charger-hour deficit against the same demand. This does not establish when robots can charge.

Scenario context incomplete: record the period, evidence or assumption, and responsible owner before using it in a decision.

Different or overlapping outages require a separate time-resolved plan. Do not add their durations here or change battery limits to make the arithmetic fit.

Peak-window availability check

Use one named busy period. This counts robots that could be available, not the missions they can complete. The example counts are invented teaching inputs, not a supplier estimate.

Scenario A

5 of 8 robots remain available: a 1-robot count gap against the stated requirement.

Scenario B

6 of 8 robots remain available. No simple count gap in these assumptions; the timed schedule and mission demand remain unverified.

Ask the provider to test charging start and finish times, charger access, queues, battery state and missed missions in the real peak. Do not treat a passing count as fleet, electrical or safety approval.

Check the state-of-charge bands before using the estimates

Added 15 October 2026. Enter the lower and upper battery percentages covered by the runtime estimate, then the charging estimate. Runtime uses this band in the discharge direction; charging uses it in the recharge direction. Leave unknown endpoints blank. This comparison does not change the budget above.

Comparison withheld: enter four percentages from 0 to 100, with each lower endpoint below its upper endpoint.

Equal percentage spans are not equal bands. This tool models no battery curve, degradation, temperature, load or reserve policy and gives no permission to operate or charge equipment. Follow the applicable manufacturer instructions and qualified site review.

Source context checked 15 October 2026: MiR250 public specifications (undated; charge endpoints not stated on reviewed page) and OTTO charging guidance (15 December 2025; 10–90% charging times, no paired runtime established). The endpoint check is RobotAtom’s method, not a battery model.

Which mission window supports this estimate?

Keep the observation separate from the charging calculation. Record references, not operational logs. A quiet-period result does not establish peak-window throughput.

6 missing mission-window references. Completeness does not verify throughput.

Entries stay in this tab. The local download preserves gaps and exceptions; aggregate tool-use events contain no entries. No logs are imported or checked.

Read the mission-window evidence method

What the calculation does—and leaves out

This is a steady-state, repeated-day budget for one homogeneous robot group. Recharge equivalents = robots × productive hours ÷ productive runtime per interval. Charger demand = recharge equivalents × charging hours. Available charger time = chargers × usable hours. Robot time = productive hours + per-robot recharge equivalents × (charging hours + docking minutes ÷ 60).

Fractional recharge equivalents represent average replenishment across repeated days. The model does not spend an initially full battery to make a single shift appear feasible. The separate peak check counts unavailable robots in two editable scenarios; it does not schedule charge events, model battery state, charge curves, queues, mission throughput, maintenance, electricity supply or safe installation. No arithmetic deficit is a validated schedule.

Adopters get a visible infrastructure gap. Providers get consistent workload and charge-band assumptions for engineering a complete solution. RobotAtom owns this tool and uses defined requirements to shape real-world deployments; it does not certify a fleet through this calculator.

Read the charging-window guide and primary sources

Discuss your AMR operating requirements