Posted by @mxgrey:
So in other words, the fleet_adapter does not say to rmf “hey, robotX is paused, take that into account”, instead it says “hey, robotX has Y seconds of delay, take that into account”
Yes, this is exactly correct. Unfortunately the prediction of future intentional “delays” (or intentional pauses) isn’t something currently offered by the high-level APIs. The underlying traffic management framework can support it, but I think adding it as a stable part of the high-level public API would be tricky. At least it’s not immediately obvious to me how to make a clean and clear API for it.
Also what happens if the max delay threshold is crossed ?
When the max delay threshold is reached, it simply triggers a fresh replanning, taking into account the latest schedule predictions of all the other robots. The assumption is that delays may be accumulating because the initial plan is no longer a good one due to unanticipated changes in the other robots’ itineraries, so we should just try to make a completely fresh plan. I intend to get rid of this behavior in the future by having each agent more intelligently monitor the other itineraries that are constraining it, but that’s a future improvement with no immediate timeline.
But since I’m writing my own fleet adapter – and I guess this might be useful for other developers --, it would be very helpful to understand what the scheduler is expecting from the fleet adapter and vice versa, and how those classes come into play.
When you say you’re writing your own fleet adapter, do you mean you’re writing it independently of the rmf_fleet_adapter library? That may be more challenging than you’re anticipating, especially if you want to have a system with multiple robots and quick responses to a highly dynamic traffic schedule.
I recognize that the public APIs for rmf_fleet_adapter are quite narrow at the moment. That’s an intentional design choice because we have users who wish for very strong API and ABI stability even while we develop new features and overhaul the implementation. If we expose too much from the rmf_fleet_adapter library then it’s likely that we’ll need to break the API too often.
If you can describe the kind of features/behaviors that you need, then maybe we can work out a way to tweak the rmf_fleet_adapter API to accommodate it. Or if you’re open to experimentation, you could always fork rmf_fleet_adapter and modify it with the changes that you need, then get back to us about what changes we could make to improve usability.
All that being said, I have a feeling what you really want is the command intervention pipeline idea that’s mentioned here. The idea for that feature is it would allow a workflow for operators or fleet managers to intervene with the currently scheduled task of the robot while still keeping the traffic schedule up to date and allowing the scheduled task to resume once the intervention is finished.
If that sounds like it would fit your needs, we’d always appreciate input on the issue ticket, including details like API design recommendations and suggestions for the scope, constraints, and requirements of the feature.
Edited by @mxgrey at 2021-07-13T06:07:50Z
