Posted by @mxgrey:
I think you may be overestimating the degree to which VDA5050 integrates with AMRs or underestimating the degree to which RMF is able to. From the Scope section:
For the purpose of a sustainable solution, an interface is described below which can be expanded in its structure. This should enable a complete coverage of the master control for vehicles that are guided. Vehicles that are free navigating can be integrated into the expandable structure; a detailed specification required for this is not part of this recommendation.
From the Definition section:
Free navigation AGVs:
Vehicles that use a map to plan their own path.
The master control sends only start and destination coordinates.
The vehicle sends its path to the master control.
When the communication to the master control is broken off, the vehicle is able to continue its journey.
Free-navigation vehicles may be allowed to bypass local obstacles.
My interpretation of this is that AMRs (or “Free navigation AGVs”, in the terms of VDA5050) are expected to find their own way and are not managed by the master control. The base path and horizon that you’re talking about is mentioned here and only applies to the non-free AGVs. It makes no mention of being able to reroute AMRs or deal with any unanticipated traffic conflicts that may arise between AMRs, e.g. if two AMRs are trying to move in opposite directions at a bottleneck, VDA5050 does not prescribe any way to resolve the conflict, and in my experience AMRs are not likely to be intelligent enough on their own to come up with a desirable solution.
In RMF terminology, their treatment of “Free nagivation AGVs” would fall under our “Read Only” category, which is actually the least desirable category because it gives the least amount of flexibility in responding to conflicts.
In RMF terminology, their treatment of the more general “AGV” would fall under our “Traffic Light” category, which is much better than “Read Only”, but still not as good as the “Full Control” category, which allows for a robot to be completely rerouted at any time.
VDA5050 does not appear to have a “Full Control” equivalent, which is why I describe it as having a subset of RMF features, at least in terms of its traffic management features.
If rmf_core goes down, traffic control and task dispatching won’t work anymore either, correct?
I think this question is conflating two different concerns:
- Single point of failure
- Traffic control strategy
I’ll address each one separately:
Single point of failure
With the introduction of this change we are very close to achieving robust failover in the traffic scheduling system. There are a few small redesign steps remaining, but I fully expect that system to have seamless failover well before anyone is getting ready to deploy an RMF-based system. In the interest of preventing race conditions there would still only be one schedule node active at a time, but you could have other schedule nodes on standby, listening to the traffic topics, and ready to spin themselves up if the active one falls off.
We will need to do some redesign on the task dispatching system as well to achieve robust failover for that, although that system has significantly less state to it, so I don’t anticipate that will be too difficult.
Traffic control strategy
I think it’s very important for me to emphasize as clearly as possible: The traffic schedule node which I mentioned above as currently being a single point of failure does NOT prescribe paths to any of the robots, whether they are AMRs or AGVs or anything else. It simply aggregates their own predictions of where they will be into the future, and then checks for conflicts between those predictions.
When a conflict is detected, the schedule node will send out a notice about the predicted conflict, and then the fleets / AMRs / AGVs will open up a peer-to-peer negotiation to resolve that conflict. There is never a “master control” that dictates where any traffic participant should go. This distributed control strategy means two things:
- Each fleet or traffic participant can take full advantage of its own knowledge of its own capabilities to come up with the best possible plan for itself.
- The overall traffic management system is not limited by a priori assumptions about the capabilities of the traffic participants that are part of its system. If an entirely new category of robot is developed that we did not anticipate when designing or deploying this system, it will still be able to integrate into the traffic management system because we are not constraining it to behave according to our own assumptions.
VDA5050 also seems to have interesting concepts like communicating only the relevant parts of the navigation graph
This concept is already captured in our “Traffic Light” category of control. Robots that are not able to reroute will communicate with the blockade moderator to guarantee that they never deadlock with each other. The blockade moderator will block off certain spaces for the exclusive use of one participant at a time, and it will not permit any other participants to enter that space until the one using it reports that it has exited.
there’s a good chance that VDA5050 will see adoption by OEMs, in which case it might be better for the community to have a these two very similar standards merge into one as opposed to having a translation layer in the form of a fleet adapter. … Standardization within the mobile robot space is what we’re all after, and so I’d suggest considering if RMF can comply with the VDA5050 standard (or vice versa) as opposed to saying one is better or a subset.
In an ideal world, I do agree with the general gist of what you’re saying here. However I genuinely believe the differences that I’ve highlighted above provide a very strong value proposition for using RMF instead of VDA5050, and because VDA5050 has a narrower scope, there is no way for RMF to merge into VDA5050 without dramatically revising VDA5050.
I also wouldn’t necessarily prescribe that anyone currently choosing to use VDA5050 should abandon it in favor of RMF. The truth is that VDA5050 is a much simpler specification, and there can be value in that kind of simplicity, as long as the scope of the specification covers all of your needs.
I do honestly believe that all VDA5050 systems could be trivially adapted into an RMF system by developing a single VDA5050 ↔ RMF fleet adapter. In some sense you could view that fleet adapter as merely being a VDA5050-flavored API for integrating into RMF. Then any OEM that chooses to adopt VDA5050 will automatically be supported by RMF as well.