Cycle Time, Battery Life, and Traffic: The Operating Envelope Math

A vendor's spec sheet says: battery life 12–24 hours, speed 0.5–1.2 m/s, payload 40 kg.

These are ceiling numbers measured in controlled conditions. Your floor is not a controlled condition.

The practical throughput of a service robot — how many deliveries it actually completes per shift on your specific floor — is determined by three interacting variables that don't appear on spec sheets: cycle time under realistic conditions, battery performance in actual operation, and traffic density during peak hours.

Understanding how these variables interact is the difference between a robot that justifies its TCO and a robot that hits 60% of its projected utilization and never closes the ROI case.

Cycle Time: The Variable No One Shows You in a Demo

Cycle time is the elapsed time between the robot departing the loading point and returning to the loading point, ready for the next delivery. It includes:

1. Loading wait time at the pickup point
2. Travel time from pickup to destination (with obstacle avoidance)
3. Unloading wait time at the destination
4. Return travel time to the pickup point
5. Any queuing time if the robot is in a multi-robot fleet

In vendor demos, these times are minimized: the robot is already staged, staff load quickly, the destination is nearby, and there's no competing traffic on the floor. In production, every element takes longer.

The Components of Realistic Cycle Time

Loading time is controlled by staff behavior, not the robot. In a restaurant during a dinner rush, the expo station has 8 items plated and ready to run. The robot arrives. The server who loads it is mid-conversation with Table 4, plates two items, turns back to check on another table, and finishes loading 90 seconds later. This isn't inefficiency — it's normal restaurant floor operation. Budget 60–120 seconds of loading time per cycle in food service environments.

Travel time depends on three factors:

• Distance: The actual route from pickup to destination in your layout, not the straight-line distance. A restaurant where the kitchen pass is in the center of a rectangular floor and the robot serves 30 tables has dramatically shorter average travel times than one where the kitchen is in the back corner and the farthest tables are 60 feet away.

• Navigation speed: Spec-sheet top speed is achieved on straight, clear corridors. In a crowded restaurant at 7 PM, the robot's obstacle avoidance system is continuously activating — slowing to 0.3–0.5 m/s to route around chairs, guests, and other staff, pausing briefly when its safety sensor detects a moving obstacle. Effective floor speed in high-traffic conditions is typically 40–60% of rated top speed.

• Path efficiency: Every detour the robot makes around an obstacle adds distance and time. In a restaurant with irregular table spacing, a path that's 20 feet in a straight line may become 35 feet of actual robot travel.

Unloading time in food service is controlled by the guest, not the robot. The robot announces arrival with a chime and display prompt. The guest has to notice, set down what they're doing, and clear the tray. Average unloading time: 45–90 seconds. In senior care, where residents may have limited mobility, this can extend to 2–3 minutes.

Return travel time is typically faster than outbound because the robot doesn't need to maintain the same collision caution with an empty tray — but the floor traffic hasn't changed. Effective return cycle time is roughly 70–80% of outbound.

Calculating Realistic Cycle Time: A Worked Example

Scenario: casual dining restaurant, 60 covers, kitchen pass at center-rear, average table 40 feet from kitchen.

At a 1:55 cycle time, a robot running continuously could theoretically complete 37 deliveries per hour. At a 4:35 cycle time, it completes 13 deliveries per hour.

That difference — 37 vs. 13 — is the gap between a vendor projection and an operational reality. The robot is the same hardware. The floor makes the difference.

Battery Life: Ratings vs. Runtime

BellaBot is rated at 12–24 hours battery life. Servi Plus is rated at up to 12 hours. These are runtime figures, but they're not the number you should use for shift planning.

What Drains the Battery

Weight degrades efficiency. A robot running at 40 kg payload uses more power than the same robot at 10 kg. In food service, a robot loaded with a full tray of plates on every cycle runs closer to the low end of its rated range. In hotel delivery (lighter packages, lower frequency), it may hit the high end.

Navigation load. Obstacle avoidance is computationally intensive and draws power. A robot navigating a crowded dinner-rush floor is running its sensors and compute continuously. A robot rolling down an empty hotel corridor at 2 AM is not. High-traffic environments see battery drain 15–25% faster than low-traffic ones.

Ambient temperature. Lithium batteries perform below rated capacity in cold environments. A service robot deployed in a grocery store with heavy refrigerated sections — or operating near loading docks in winter — may see 10–20% range reduction.

Battery age. New lithium battery packs perform at or near rated capacity. After 18 months of daily full charge cycles, capacity degrades. Most service robot batteries hit 80% of original capacity at the 18–24 month mark, which means a robot rated for 12-hour runtime will deliver roughly 9.5 hours at that age. Battery replacement at 24–36 months is a maintenance cost that should be in your TCO model.

Planning for Actual Runtime

A practical rule: budget 70% of the rated battery figure for shift planning. A 12-hour-rated robot should be planned for an 8.5-hour operational shift before recharge is needed.

For businesses that run longer than that — 24-hour senior care facilities, hotels that need overnight service, restaurants with split lunch/dinner shifts — quick-release battery systems (Pudu offers these on select models) enable battery swaps instead of the 4.5-hour full charge cycle. Budget 5 minutes of staff time per battery swap plus a charged spare battery in your capital cost.

Traffic Density: The Variable That Changes Everything

Of the three operating envelope variables, traffic density has the largest impact on realized throughput and is the most difficult to assess from a vendor demo.

How Traffic Affects Robot Performance

Direct route blockage. When the robot's planned path is occupied — a server standing at a table, a guest in the aisle, a laundry cart in the hotel corridor — the robot halts and waits. After a timeout (typically 5–15 seconds depending on vendor configuration), it attempts a detour. In some layouts, no detour is available and the robot must wait for the obstruction to clear. During a dinner rush, a robot can spend 20–30% of its operating time in wait states.

Cascading navigation failures. In multi-robot environments (two or three units on the same floor), robots can block each other. Fleet management software coordinates paths, but in tight spaces it sometimes results in one robot waiting while another completes a maneuver. The efficiency gains of a second robot are partially offset by the coordination overhead.

Staff behavioral adaptation. Staff who understand the robot learn to stage the floor in ways that reduce blockage: pushing chairs in slightly before service, keeping aisles clear of standing clusters during peak periods. This takes 4–6 weeks to develop as a habit. Before it does, traffic interference costs are higher.

Traffic Density by Sector

The senior care numbers deserve attention. Wheelchairs, walkers, IV poles, and mobility equipment create irregular, slow-moving obstacles that current robot obstacle avoidance handles less elegantly than chairs and stationary objects. A robot navigating a skilled nursing hallway during morning rounds may require more staff interventions per hour than one running a restaurant during dinner service.

Putting It Together: The Utilization Model

Once you have realistic cycle time, battery runtime, and traffic-adjusted throughput estimates, you can calculate actual deliveries per shift — the number that validates or kills the TCO model.

Formula:

Deliveries per shift = (Operational hours × 60 min) ÷ Realistic cycle time (minutes)
× Traffic efficiency factor

Example: Restaurant, dinner shift (5 hours peak)

• Operational hours: 5 (robot is needed during 5-hour dinner window)
• Realistic cycle time: 4.5 minutes
• Traffic efficiency: 60% (high dinner-rush traffic)

(5 × 60) ÷ 4.5 × 0.60 = 40 deliveries per peak shift

If your restaurant runs 300 covers in that window and each cover requires an average of 0.4 robot-deliverable runs (not every plate movement is robot-appropriate), you need 120 deliveries — and a single robot at 40 deliveries/peak-shift doesn't cover it. You're either supplementing with staff or evaluating a two-robot fleet.

This is the calculation that determines whether a single unit is the right purchase or whether you need to budget for two.

What to Ask Before You Sign

The operating envelope math gives you leverage in vendor conversations. Before committing to a deployment, ask the vendor:

1. "Can you share cycle time data from a reference site that matches my property type — similar floor area, similar traffic density, similar delivery pattern?"

A vendor that can produce actual cycle time logs from a comparable deployment is operating transparently. One that can only show demo footage should be pressed further.

2. "What is the battery runtime we should plan for at full payload, including an aging factor for 18-month-old hardware?"

A vendor that acknowledges battery aging in their answer understands their product's real-world lifecycle.

3. "What percentage of deliveries at your high-traffic restaurant deployments require staff intervention — either because the robot is blocked or because it fails to complete the delivery autonomously?"

Intervention rate is the metric that determines how much staff time the robot is actually saving vs. consuming. An acceptable intervention rate in a well-tuned deployment is under 5%. Above 10%, the labor savings case weakens substantially.

4. "At what traffic density does your routing algorithm start queuing the robot instead of navigating through?"

This tells you whether the robot's behavior under congestion is graceful (wait and route around) or disruptive (block the path until staff clear it).

The Practical Floor Audit

Before the vendor's demo, spend 30 minutes walking your floor with a stopwatch during your peak traffic period and measure:

• Average aisle width in the busiest section (must be at least 90 cm, preferably 120+ cm, for current-gen service robots)
• Time to walk your typical delivery route (robot travel time will be 1.5–2.5× this)
• Number of path obstructions per 10-minute walk (chairs pulled out, staff crossing, carts, equipment)
• Dead-end corridors or tight turns that would require robot reversing

This data, combined with the vendor's spec sheet, gives you the inputs for the utilization model before the demo rather than after.

The next article covers vendor comparison — specifically how to differentiate Pudu, Bear Robotics, Keenon, and OrionStar across this operating envelope, and what the long-tail vendors offer that the majors don't.