Open-RMF Charger Schedules: Check Midnight, Timezones and Conflicts
Published 2026-11-02 21:12:34 -05:00 (America/New_York). Sources checked 2 November 2026.
Scheduling is not an electrical acceptance test
The Open-RMF Jazzy charging-schedule README describes a node that reads a YAML schedule and publishes commands changing robot charger assignments. It explicitly places responsibility on the schedule author to avoid assigning the same charger to multiple robots at once. This makes schedule validation a project responsibility rather than an assumption supplied by the existence of the node.
Treat this as software resource-allocation review. It does not assess battery compatibility, charger electrical safety, docking mechanics or the robot manufacturer’s approved charging procedure. Those need separate qualified validation. Record the installed package version and confirm its behaviour against the branch reference checked on the stated date.
Make resource ownership explicit
Build a register of robot names, charger names and any designated parking locations. Check that names in the schedule match the deployed fleet configuration exactly. Define the owner who approves changes and the procedure for taking a charger out of service. A schedule can be syntactically valid while assigning a robot to an unavailable or incorrectly named resource.
Review the complete daily sequence for overlapping charger ownership. The README describes a repeating daily schedule and updates that affect explicitly listed robots, so inspect the effective assignments between entries rather than only comparing lines at identical timestamps. Record the intended baseline and the assumptions used to reconstruct it.
Test clock and startup behaviour
The source distinguishes simulation time from local-machine time and describes a timezone option. Choose the intended clock interpretation with the fleet operator and record it explicitly. A server configured for another region should not silently shift a site’s charging plan. Include daylight-saving and date-boundary questions where they are relevant to the chosen timezone and operations.
Use an isolated test scenario to start the scheduler at different points in the daily sequence. Observe the initial assignments it publishes and compare them with the approved effective schedule. Check the midnight baseline and the distinction between parking and charging points. Retain the configuration, clock context and observed messages as one reproducible test record.
Handover an auditable allocation plan
The operator needs a readable view of intended assignments and a procedure for an unavailable charger. Define who resolves a conflict and how the fleet application shows an assignment that cannot be fulfilled. Do not infer that a scheduled resource was physically reached or that a battery is charging merely because a command was published.
Acceptance should include schedule review, startup reconstruction and a supplier-approved unavailable-resource scenario before supervised hardware use. Keep the resource register with the schedule revision. The result is evidence that the tested software assignments match the approved plan. It is not a guarantee of fleet availability or charging performance, and it does not replace the physical installation’s electrical, battery and access-control requirements.
Preserve the effective assignment table alongside the YAML file. That readable view helps operations detect an unintended carry-over assignment that is difficult to spot in a partial-update schedule.
Source: Open-RMF charging-schedule README (Open-RMF rmf_ros2 Jazzy branch, checked 2026-11-02). The acceptance proposals above are editorial guidance, not reported project results. Compare robot models and manufacturer profiles, or discuss the integration requirements.