Control Robot Charging with Repeated Polling and Exclusive Station Assignments

A fleet contains multiple robots and a limited number of charging stations. A robot whose battery level is below 50% should be sent to an available charging station. A robot charging above 95% may leave the station and return to work.

Implement or describe a controller function that checks which robots need charging and which have finished. The function is called several times per second. Battery-reading and robot-control APIs already exist; concentrate on how the controller uses them and tracks assignments across calls.

Constraints & Assumptions

• The thresholds are strict: exactly 50% does not newly qualify a robot for charging, and exactly 95% does not qualify a charging robot for release.
• A station can be assigned to at most one robot, and a robot can hold at most one station assignment.
• Repeated calls must not repeatedly send an already assigned robot to charge, assign the same station twice, or repeatedly issue a return-to-work command.
• The source does not supply API names, return types, movement timing, or failure semantics. Define a small API contract as a practice assumption before describing the controller; do not assume a dispatch command instantly moves a robot.
• Practice concurrency assumption: one logical controller owns assignments. If calls can overlap, assignment changes are serialized. Discuss what stronger coordination would be needed for several independent controller processes.
• Robots that need charging may wait when no station is available. State a selection policy; the source supplies no priority or fairness rule.

Clarifying Questions to Ask

• Which APIs report station occupancy and robot arrival or departure, in addition to battery level?
• Does a successful command mean “accepted” or “completed,” and can its status be queried after a timeout?
• Can retries carry a stable operation ID, or are movement commands otherwise idempotent?
• Can a robot or station become unavailable while an assignment is pending, and who reports that condition?
• Is the controller expected to survive process restarts without losing in-progress assignments?

Part 1 — Represent Assignments and Eligibility

Describe the robot and station states needed across controller invocations. Explain when a robot becomes eligible for charging or release and how unavailable stations and waiting robots are represented.

What This Part Should Cover

• Battery thresholds separated from the state of an existing assignment.
• Reservation of a station before dispatch and preservation of ownership until departure is confirmed.
• A waiting policy that does not create duplicate queue entries on every invocation.

Part 2 — Process One Controller Invocation

Walk through status reconciliation, completion detection, and new assignments. Specify when state is changed relative to issuing API commands, including the case where a robot finishes charging while others are waiting.

What This Part Should Cover

• Detecting completed departure before advertising a station as available.
• At most one active charge assignment and one in-progress movement command of each kind for a robot.
• Allocation when demand exceeds station capacity and the treatment of exact threshold values.

Part 3 — Handle Repeated Calls and Uncertain Outcomes

Explain how the design behaves when calls overlap, telemetry is missing, or a command times out after possibly being accepted. Analyze the work performed by each invocation and the retained controller state.

What This Part Should Cover

• Atomic reservation and state transitions, with network calls kept outside a long-held assignment lock where possible.
• Safe handling of accepted-but-unacknowledged commands and stale status responses.
• Recovery or reconciliation rather than treating every unknown station as free.