Robot can silently drain battery at home without notifying operators

[aeshub]

Describe the improvement you would like to see

When the robot is in Home, Recharging, or RechargingWithMission and its battery is draining instead of charging, ISAR has no way to notice. The robot silently discharges until it powers off, with no operator alert.

The problem

The state machine only reacts to two battery thresholds while parked: Home -> Recharging below ROBOT_MISSION_BATTERY_START_THRESHOLD (25%), and Recharging -> Home above ROBOT_BATTERY_RECHARGE_THRESHOLD (80%). Neither checks whether charging is actually happening, so a failed charger results in a monotonic discharge with no transition out.

Possible causes

• Robot not physically docked correctly (misalignment, dirty contacts).
• Charger / cable / dock / contactor hardware failure.
• Power cut at the docking station.
• Robot reports Home but never engages charging mode.
• Parasitic load exceeds charge current.

In all cases the robot's self-reported status stays Home, so existing status-based handlers do not fire.

Why detection is non-trivial

• Battery readings are noisy between polls.
• Brief drops right after docking can be normal.
• Charge rate varies per robot, so any rate-based check must tolerate slow chargers without missing real failures.
• The signal must work across all robot packages via RobotInterface.get_battery_level.

Desired outcome

Transition to InterventionNeeded with a clear reason so the existing TOPIC_ISAR_INTERVENTION_NEEDED MQTT alert reaches operators before the battery is depleted.

Possible implementation paths

• Rate-of-change over a window.

Related: #910 (recovery side of the same scenario).

How will this improvement affect the current Threat Model?

Leave blank for maintainers to fill out if you are uncertain about this.

[andchiind]

In this case I would argue the underlying bug that it is not charging is something that should be detected by the ISAR implementation, not ISAR itself. The state machine should not be polling, and ideally should not make assumptions about the underlying system. If we detect a battery reduction of 0,5 then it is impossible to know if that is expected fluctuation for that robot or the sign of an issue. I agree though that we can create an event that let's the ISAR implementation notify the state machine if an issue has occured though, so that it can transition to intervention needed.

So in practise this would either mean a dedicated event specifically for this which we can check for in the same thread we check the battery in the robot service, or potentially we could make a generic eventhandler/telemetry thread which checks for errors in the isar implementation. This was we can always transition to intervention needed when the robot reports issues.

Besides this it is worth mentioning that we also already have a report of the charging status being sent as a telemetry.

[andchiind]

If the robot is not charging because it is not docked then this is also just a bug in the ISAR implementation, since then it must have reported a successful dock mission when it in fact was not successful. This should not be assumed in ISAR.

[andchiind]

In short: to close this issue I suggest we add some sort of general error event that can be send from the isar instance telemetry threads to the robot service, which then transitions the state machine from home to intervention needed. We could potentially reuse the battery thread in the robot service to check for this event.