Robot Anatomy, Power, and Compute

Opening challenge: A rover's object detector becomes twice as fast—but the battery now sags, the computer throttles, and the motors miss a control deadline. Did the robot improve?

Not necessarily. A robot is a physical system with shared limits. Better software helps only when the whole machine can supply the mass, electrical power, cooling, computation, communication, and time that the software requires.

The Six-Part Anatomy

The arrows matter more than the boxes. Sensors require power and bandwidth. Compute produces heat. Actuators can draw large current. Added batteries and payload increase mass, which can raise required motor effort. A robot architecture is therefore a network of coupled budgets.

Five Shared Budgets

1. Mass and geometry

Every component must be carried and physically fit. Payload changes acceleration, stopping distance, traction, stability, and energy use. Mounting location also matters: a heavy device high above the ground can make a rover easier to tip.

Clearpath's official Jackal manual makes this concrete. It lists a maximum payload of 20 kg, a 270 Wh lithium battery, user-power limits, and different runtimes for basic and heavy use. Those numbers are product-specific, but the engineering lesson generalizes: payload, electrical loads, and duty cycle cannot be chosen independently.

2. Energy and peak power

Energy answers “how long?” Power answers “how fast is energy being used now?”

• Energy is commonly expressed in watt-hours (Wh).
• Power is measured in watts (W).
• A first estimate is runtime ≈ usable energy ÷ average power.

Suppose a robot has 240 Wh of usable battery energy and averages 60 W:

240 Wh ÷ 60 W = 4 h

That is only a planning estimate. Motor starts, slopes, cold batteries, conversion losses, aging, and safety reserves reduce usable runtime. A system can also fail even with energy remaining if a short current surge drops voltage below the computer's operating limit. NVIDIA's Jetson Nano guide, for example, states that its board shuts down if supply voltage falls below its documented threshold; it also provides distinct 5 W and 10 W compute modes. More compute performance therefore has an electrical cost.

3. Heat

Most consumed electrical power eventually becomes heat. When heat cannot leave quickly enough, processors may reduce clock speed, motor drivers may protect themselves, and batteries may move outside their allowed temperature range. Thermal design—heatsinks, airflow, conduction paths, enclosure design, and operating temperature—is part of robot behavior, not cosmetic packaging.

NVIDIA's official Jetson guidance explicitly links power modes, device temperature, and thermal throttling. A model that meets its frame-rate target on a cool desk may miss deadlines inside a sealed rover after twenty minutes.

4. Compute and memory

“Can this computer run the model?” is incomplete. Ask:

• At what input rate and resolution?
• Alongside which other processes?
• With what worst-case latency and memory use?
• Under the selected power and thermal mode?
• What happens when a result is late?

Average speed can hide dangerous pauses. ROS 2's real-time guidance frames correctness around update deadlines and bounded jitter: a controller that is occasionally very late may fail even if its average computation time looks good.

5. Time and communication

A measurement has an age. A command has a deadline. A network has finite bandwidth. ROS 2 Quality of Service distinguishes concepts such as deadline, lifespan, reliability, and liveliness because a delivered message can still be too late to use.

For a moving robot, the evidence chain is:

capture → transmit → estimate → decide → command → actuator response

End-to-end latency is the sum of these stages. Reducing only model inference time may not fix a slow camera, congested bus, or sluggish actuator.

Worked Example: Add a Second Camera?

A warehouse rover currently averages 45 W and has 180 Wh usable energy. Its mission requires 3 hours.

1. Baseline estimate: 180 ÷ 45 = 4 h.
2. A second camera plus processor load adds an estimated 15 W.
3. New estimate: 180 ÷ 60 = 3 h.
4. With no reserve, the design is fragile; slopes, aging, or extra stops can end the mission early.
5. More image data may also increase bandwidth, memory, and heat.

The correct question is not “Is a second camera better?” It is “Does the added evidence improve mission performance enough to justify its effects on every relevant budget?” Possible revisions include lowering frame rate, processing only when needed, choosing a lower-power sensor, adding battery capacity while rechecking mass, or redefining the mission.

Misconception Checks

“A faster AI computer always makes the robot smarter.” A faster processor may consume more power or throttle when hot. Intelligence is useful only when decisions arrive within the system's physical deadlines.

“Battery capacity determines everything.” Capacity estimates duration; peak current, voltage regulation, wiring, fusing, and conversion losses determine whether components remain powered during demanding moments.

“Payload is just a weight limit.” Payload location and motion affect stability, traction, stopping, energy, and structural stress.

“The simulator ran, so hardware will run.” Simulation often omits supply sag, thermal throttling, electromagnetic interference, network contention, wear, and uncertain friction.

Retrieval Pause

Without looking back, name the six subsystems and five shared budgets. Then answer:

1. Which budget connects a heavier payload to shorter runtime?
2. Why can an average frame rate hide a control risk?
3. What evidence would show that a late decision came from sensing, communication, compute, or actuation?

Architecture Review Checklist

• Define mission duration, terrain, payload, speed, and environmental limits.
• Draw every energy source, converter, protection device, and load.
• Estimate average energy use and worst-case peak power.
• Record component mass, mounting position, and mechanical interface.
• Budget sensor rate, bandwidth, memory, and worst-case latency.
• Identify heat sources and cooling paths.
• Define safe behavior for low voltage, high temperature, stale data, lost communication, and missed deadlines.
• Measure the integrated robot; do not approve subsystems only in isolation.

Summary

A robot is not software attached to wheels. It is a coupled physical system. Structure carries loads, power supplies energy, sensors create measurements, compute transforms evidence into decisions, communication moves information, and actuators create motion. Every design choice spends from shared mass, power, heat, compute, and time budgets. World-class robot engineering makes those budgets visible, measures them under realistic workloads, and defines safe behavior when a limit is reached.

Sources and Further Learning

• Clearpath Robotics, Jackal User Manual, official system specifications and integration guidance; retrieved 2026-08-17. Link and cite; product images were not reused.
• NVIDIA, Jetson Nano 2GB Developer Kit User Guide, official power-input and power-mode guidance; retrieved 2026-08-17. Link and cite.
• NVIDIA, Power Optimization with NVIDIA Jetson, official power/thermal monitoring and throttling guidance; retrieved 2026-08-17. Link and cite.
• Open Robotics, ROS 2 real-time programming, official deadline and jitter explanation; retrieved 2026-08-17. The cited page is an EOL-version tutorial used only for stable conceptual guidance, not installation steps.
• Open Robotics, ROS 2 Quality of Service settings, official deadline, lifespan, reliability, and liveliness concepts; retrieved 2026-08-17.
• NASA, Technical Requirements Definition, official systems-engineering guidance on mechanical, electrical, thermal, functional, and human interfaces; retrieved 2026-08-17. U.S. government source; cited and paraphrased.