| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Posted by @Achllle:
I opened an issue in the multirobotbook repo to suggest adding in a comparison with VDA5050. Given the dedicated repo and discussion board here I figured it’d be a good idea to open a discussion topic here.
Curious what people’s and maintainers’ thoughts are on the differences and (to me) striking similarities and if we can take some of the good parts and include those or even work on compatibility. Not trying to hint in any way that one is better than the other.
Posted by @mxgrey:
Thanks for bringing this to our attention. It’s always valuable to see what other organizations are doing in this space, especially for open specifications. I agree that there’s a great deal of alignment in the motives and some aspects of the high-level design of RMF and VDA5050.
But before any casual observers get the impression that RMF is redundant with VDA5050, I think it would be good to highlight what I consider to be the most crucial differences between the two, especially pertaining to their scopes:
Overall, I see the scope and supported features of VDA5050 as being a subset of the scope and supported features of RMF. That’s not to suggest that RMF completely obsoletes VDA5050. I think there’s value in having a more narrow specification for use cases where the more narrow scope is applicable. Instead I think it would be an interesting exercise to create an adaptation layer that would allow any VDA5050-compliant systems to be compatible with an RMF system. Based on what I’ve read so far of the VDA5050 specification, it should be able to fit into an RMF system quite nicely.
Edited by @mxgrey at 2021-04-05T03:28:55Z
Posted by @gbiggs:
My skimming of the VDA5050 document makes me think it might be relatively easy to write a fleet adapter for it.
Posted by @mxgrey:
I agree. We would simply write a fleet adapter that acts as the “master control” of a VDA5050 system. It should fit very nicely into the “Traffic Light” category of fleet adapter.
Posted by @txlei:
RMF instead allows individual fleets to determine the paths for their own AGVs/AMRs
Do you mean the fleet’s fleet adapter?
Posted by @mxgrey:
Do you mean the fleet’s fleet adapter?
Either one.
In the case of “Traffic Light” or “Read Only” fleet categories, the fleet manager itself always decides the paths, and the fleet adapter simply needs to cope with the fleet manager’s decision.
It’s also possible for a fleet manager to incorporate the traffic scheduling and negotiation pipelines directly into itself, bypassing the need for a fleet adapter altogether. Of course that doesn’t exist yet, but I expect a future version of our “free fleet” package will do exactly that.
But for now, any robot fleets that fulfill the “Full Control” criteria would be encouraged to allow their fleet adapter to determine their paths for them.
Posted by @Achllle:
It appears to make the assumption that these vehicles can manage themselves well enough that there is negligible concern about traffic conflicts between them
I do not think this is the case. The broker will communicate a base path + horizon to each mobile robot. The base path cannot be changed because there is no guarantee that messages will arrive, but the horizon can be changed on the fly, allowing for traffic avoidance. VDA5050 explicitly supports mobile robots of all kinds (AMRs, VGVs, AGVs, line and way-point following robots, you name it) including carts (see loads>boundingBoxReference and loadDimensions fields)
VDA5050 assumes that there is a centralized master control. RMF does not make this assumption
I might be misunderstanding here how rmf_core works then. If rmf_core goes down, traffic control and task dispatching won’t work anymore either, correct? I think an interesting difference is that VDA5050 asks OEMs to comply with their standard (but still allows for interaction with a fleet server API through some kind of proxy) whereas RMF seems to assume that OEMs are not likely to ‘natively’ support RMF.
VDA5050 also seems to have interesting concepts like communicating only the relevant parts of the navigation graph, assigning actions/tasks to vertices and lanes (nodes and edges in VDA5050 speak), and dealing with different levels of control not by putting them in separate buckets, but instead by including optional fields. (not suggesting this is better)
A big difference that I see is that RMF not only is suggesting a standard (in the form of message definitions, it’s also putting forth an implementation, which VDA5050 does not seem to do. I’m tempted to say however that 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. RMF being an open-source system that implements an already accepted standard is worth considering for a moment IMHO.
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:
I’ll address each one separately:
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.
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:
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.
Posted by @mrceki:
Hi @mxgrey
I am currently working on developing a full control fleet adapter (for non-free AGVs) that is compatible with VDA5050. My main challenge revolves around traffic management and how to effectively utilize waypoints (nodes and edges) as described in the VDA5050 specification.
At present, my approach involves sending individual targets for each node. However, I am considering whether it would be more efficient and in line with VDA5050 standards to leverage the concept of waypoints.
Any insights, suggestions, or experiences shared would be greatly appreciated.
Posted by @mxgrey:
I plan on providing first-class support for VDA 5050 as one of the top priorities of the “next generation” rewrite that we’re working on. I think trying to adopt the current RMF API to fit the needs of VDA 5050 may require a significant amount of housekeeping, whereas in the next generation work we’ll have an opportunity to do a deeper integration. I expect this work to begin in November, but I can’t offer a firm timeline.
Nevertheless, if you’re still interested in developing a VDA 5050 adapter on top of the current API, I’m happy to offer some pointers.
My main challenge revolves around traffic management and how to effectively utilize waypoints (nodes and edges) as described in the VDA5050 specification.
I think the concept of nodes and edges maps pretty nicely to the concepts of waypoints and lanes in RMF. The main challenge is to create a useful mapping between the two. I think I recall that VDA 5050 expects a unique string name for each of its nodes. You can assign those same unique names to the RMF waypoints, and then your adapter can cross-reference those names against the VDA 5050 nodes.
I believe VDA 5050 supports multiple edges between the same two nodes, and theoretically RMF supports multiple lanes between the same two waypoints, but in the current generation of RMF there isn’t a way to give lanes a unique string label. If you care about supporting multiple edges between the same nodes, it might be necessary to add support for lane labels into RMF.
Edited by @mxgrey at 2024-07-08T14:33:53Z
Posted by @mrceki:
I tried a shortcut for the situation you mentioned, and it seems to be working for now. I would appreciate it if you could take a look at the adapter and provide some advice.