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. ```hint Distinguish acceptance from completion A robot can still occupy its station after the API has accepted a command to return to work. Decide which observation permits another robot to receive that station. ``` ```hint Remember the previous call Two consecutive invocations may read the same low battery level. What persistent state prevents them from dispatching the same robot twice? ``` ### What a Strong Answer Covers - A coherent state machine that preserves exclusive robot-to-station assignments across frequent calls. - Correct application of the below-50% and above-95% rules, including the hysteresis between them. - A concrete invocation sequence, bounded in-flight commands, waiting behavior, and failure reconciliation. - Clear dependency on API guarantees, plus time and space costs in terms of robots and stations. ### Follow-up Questions - How would the controller recover its assignments after restarting while robots are moving to or from stations? - If several controller processes can run at once, where must the exclusive station reservation be enforced? - How would delayed battery readings and delayed movement acknowledgments affect a waiting robot's assignment without making an occupied station appear free?