Robot stops after running for several hours

1. Symptoms

• The robot works for the first hours of a shift and then stops, resets or refuses commands.
• Performance degrades gradually (slower, jerky, localization lost) before the stop.
• The stop time varies with load or ambient temperature.

2. Possible causes

• Battery: capacity lower than estimated, or the pack voltage sags under load until a converter or the BMS cuts out.
• Thermal limiting: motors, drivers, converters or the computer reach a limit and throttle or shut down.
• Memory or disk growth: a leak or growing log, bag or map until the process is killed or the disk is full.
• Drift: localization or odometry error accumulates until the planner fails.
• Network or time: a Wi-Fi or DDS discovery problem, or a clock jump, after a long run.
• Watchdog or safety trip: a counter or timeout that is reached only after long operation.

3. Measurements to collect

• Pack voltage, current and percentage over the whole run (sensor_msgs/BatteryState), with the time of the stop.
• Motor, driver, converter and computer temperatures over time.
• Per-process memory and disk usage over time.
• Localization covariance or the difference between odometry and a reference over time.
• System log and ROS 2 log lines in the minutes before the stop.

4. Diagnostic commands

Commands are not executed by the site’s automated tests (they need a ROS 2 Jazzy installation or the robot).

Typical checks on the robot: ros2 topic echo /battery_state (or your battery topic), ros2 bag record of the relevant topics for a full run, free -m and df -h repeated every minute into a log, journalctl -b -1 for the previous boot, and the motor driver’s own temperature telemetry.

5. Step-by-step investigation

1. Record a full run with the battery, temperatures, memory and disk logged at a steady rate.
2. Read the last minutes before the stop: did voltage drop, a temperature plateau, memory reach the limit, or a log line name a cause?
3. If voltage dropped, compare the energy used with the power budget and the usable capacity at that discharge rate and temperature (power budget guide); check the cut-off of the BMS and the converter minimum input.
4. If a temperature saturated, find the hottest part and compare with its datasheet limit (motor overheating).
5. If memory or disk grew, find the process and fix the leak or add rotation to the logs.
6. If error drifted, check localization sources and loop closure over the run.
7. Repeat after each change with a run at least as long as the longest mission.

6. Corrective actions

• Re-size the battery or reduce the load; add margin for aging and temperature.
• Improve cooling or reduce duty cycle; add thermal derating instead of a hard stop.
• Fix leaks and rotate or cap logs, bags and maps.
• Add drift correction or periodic re-localization.
• Add a defined, safe low-battery behaviour (return to the charger) before the cut-off.

7. Validation after the fix

• A test as long as the longest mission completes with margin on every logged resource.
• Battery percentage at the end matches the prediction within the stated margin.
• No log line reports a limit or a restart.
• The result repeats on a second unit and at the hottest ambient in the ODD.

References

• sensor_msgs/BatteryState (Jazzy): docs.ros.org.