Robot Economics Calculator

fade = clamp(1 - 0.20 * (cycles / rated_cycles), 0.60, 1.00)

A straight line to 80 percent of original capacity at the rated cycle count, which is how cycle life is defined, floored at 60 percent because a pack that far gone is normally retired. Rated cycles: LFP 4,000, NMC 1,800, high rate drone pack 300.

usable_Wh = pack_Wh * (dod / 100) * fade

duty_factor = (duty/100) + (1 - duty/100) * (idle_share/100)
effective_W = datasheet_avg_W * derate[form][ambient] * duty_factor

The derate multiplier turns a favourable benchmark figure into a real world draw: heat costs cooling and forces throttling, cold raises pack internal resistance and adds heater load, and real duty cycles are choppier than benchmark cycles. Every one of these multipliers is our engineering estimate. No manufacturer publishes an ambient derating curve for average power on a mobile robot. If you have telemetry from your own fleet, type that number in instead.

runtime_h  = usable_Wh / effective_W

no spare packs:   downtime_h = full_recharge_min / 60
S spare packs:    downtime_h = max(swap_min / 60, (full_recharge_min / 60) / S - runtime_h)

With spares, the robot pays only the swap while the spent pack charges in the background. That works only if the charger keeps up: a pack has S cycles of wall clock time to refill, so the robot waits whenever S * (runtime + downtime) is shorter than the recharge time. The second term is that constraint solved for downtime.

u                = runtime_h / (runtime_h + downtime_h)
working_min_hr   = 60 * u
robots_1_shift   = ceil(2000 / (u * annual_hours))
robots_24_7      = ceil(8760 / (u * annual_hours))
energy_per_shift = effective_W * 8 * u / 1000 / charge_efficiency   (kWh)

A single shift position is 2,000 hours of coverage a year (eight hours a day, five days a week). Round the clock cover is 8,760 hours. Each robot supplies u times its annual operating hours of productive work, so the fleet size is the coverage divided by that. Charge efficiency is taken as 0.90 for a battery robot and 1.00 for a mains powered one. A mains powered machine has no charge cycle at all, so u is 1 and runtime is continuous.

r   = rate / 100
CRF = r * (1+r)^n / ((1+r)^n - 1)        capital recovery factor
SFF = r / ((1+r)^n - 1)                  sinking fund factor
when r = 0:  CRF = 1/n,  SFF = 1/n

capital_annual     = capex * CRF - residual_value * SFF
integration_annual = integration * CRF

Standard capital recovery with salvage. Residual value is a percentage of capex and is credited back through the sinking fund factor, which is the annual amount that compounds to the residual by the end of the life. Integration carries no residual because a commissioning bill has no resale value.

capital      = capital_annual / H
integration  = integration_annual / H
maintenance  = capex * (maint_pct / 100) / H
battery      = pack_cost * (1 + spare_packs) / battery_years / H
energy       = (effective_W / 1000) * elec_price / charge_efficiency
teleop       = supervisor_cost / robots_per_supervisor
software     = software_year / H
insurance    = insurance_year / H

total = capital + integration + maintenance + battery
        + energy + teleop + software + insurance

H is annual operating hours. Six of the eight are fixed annual costs spread over however many hours you run, which is why utilisation moves the total so hard. Energy and teleoperation are the only two that are genuinely per hour, and they set the floor no amount of extra running can get below. Maintenance as a percentage of capex assumes post warranty operation. Year one is usually near zero because it is covered, which is exactly why three year TCO models flatter robot economics.

cycles_per_year   = H / runtime_h
computed_years    = rated_cycles / cycles_per_year

One discharge to the usable depth counts as one cycle. This is what the "use computed" button fills in. Budget a pack replacement as a step change rather than smearing it into the maintenance percentage, and note that a drone flying daily replaces packs every year.

human_equivalent_cost = total / p             p = humans replaced per robot
parity_wage           = total / p             robot wins when human wage > parity
annual_saving         = (human_cost * p - total) * H

opex_per_hour   = total - capital - integration
upfront         = capex + integration
annual_net_cash = (human_cost * p - opex_per_hour) * H
payback_months  = 12 * upfront / annual_net_cash      only when annual_net_cash > 0

fixed_annual    = capital_annual + integration_annual + maintenance_annual
                  + battery_annual + software + insurance
variable_hourly = energy + teleop
break_even_H    = fixed_annual / (human_cost * p - variable_hourly)

Simple payback compares the upfront cash to the cash the robot saves each year, so the capital recovery components come out of the running cost first. There is no discounting in the payback figure, which is the convention and which flatters long paybacks. Break even utilisation is the annual hours where fixed cost is exactly covered by the hourly margin. When the variable cost per hour already exceeds what a human costs for the same output, there is no break even at any utilisation, and the calculator says so rather than printing a large number.

for each input x:
    low  = cost_per_hour(x * 0.70)
    high = cost_per_hour(x * 1.30)
    swing = |high - low|
sort by swing, longest first

One input at a time, everything else held at the current value. This is a one-at-a-time sensitivity, so it does not capture interactions: moving annual hours changes battery cycles per year as well as the divisor, and the tornado shows only the net. Service life is varied in whole years and clamped to at least one. Inputs that are currently zero cannot move, so they show a zero length bar.