question on using fleet adapter

[imdalaf]

I have downloaded the office demo project and from the code inside the rmf_core/rmf_fleet_adapter/src/full_control/rmf_fleet_adapter/agv/Node.hpp, i observe that there are definition of models (dispenser and ingestor) that seems to be specific to that project. This makes me wonder if it is expected for us to modify the codes inside the rmf_core library for our own project if there are any specific custom model which we have created. I would thought that rmf_core library is generic enough and we should use it as framework without any need to modify the code inside and build my solution around that framework. Am I right?

Another reason why I asked this question is because I wasn't very clear of what are the work that are needed on the fleet adapter if my project involves a AMR/AGV fleet. Am i right to expect that there is no work that is needed on the implementation of the fleet adapter because it is already provided in the rmf_core library? The only work that is needed is the integration of the fleet manager to the fleet adapter which the work is to be done on the fleet manager side?

[mxgrey]

This makes me wonder if it is expected for us to modify the codes inside the rmf_core library for our own project if there are any specific custom model which we have created.

Under the Apache License 2.0 that governs this project, you are certainly allowed to fork the source code and modify it to fit your needs.

However, a foundational goal of the RMF project is to have the interfaces be as generic and reusable as possible. We wouldn't encourage forking and modifying the core interfaces, because then there will be added work if you ever need to make your systems interoperable with other RMF-based systems that didn't build on your forked version.

Instead, if the existing RMF interfaces do not meet the needs of your system, we would recommend opening a discussion about it in a GitHub Issue and/or opening a Pull Request with the changes that are needed for you to integrate your system with RMF.

Many of the design choices that underlie the existing interfaces were based on the specific proof-of-concept use-cases that have been driving the research and development effort behind RMF. It's very likely that we have not made the interfaces sufficiently generic yet, and getting feedback from users (or prospective users) would be extremely valuable in refining those interfaces. The sooner we can get that feedback the easier it will be to incorporate the necessary changes into the design.

[mxgrey]

Am i right to expect that there is no work that is needed on the implementation of the fleet adapter because it is already provided in the rmf_core library? The only work that is needed is the integration of the fleet manager to the fleet adapter which the work is to be done on the fleet manager side?

The answer to this question depends somewhat on how you want to draw the boundaries between what is the "fleet adapter" and what is the "fleet manager".

This rmf_core repository provides the rmf_fleet_adapter package, which contains a library called rmf_fleet_adapter. That library contains a few different APIs that can be used to develop your own fleet adapter.

For a "Full Control" category of fleet adapter, you would want to use the APIs defined in these headers:

• FleetUpdateHandle
• RobotCommandHandle
• RobotUpdateHandle

For a "Traffic Light" category of fleet adapter, you would want to use the APIs defined in this header:

• TrafficLight

The purpose of these APIs is to make it as easy as possible for you to plug your fleet's API into RMF. The expectation is that users will create a single executable that combines the rmf_fleet_adapter library with whatever API they can use to talk to their fleet. In most cases we expect the fleet will use a REST API, and for that we recommend using the Python bindings to create a Python script that ties the fleet's REST API into the Python bindings for the rmf_fleet_adapter API.

You may also choose to modify your fleet manager to use the rmf_fleet_adapter library directly. We expect most users will not take this approach for various reasons (most likely to keep any dependency on RMF separate from their fleet manager), but it is a perfectly valid option if it's desired.

[imdalaf]

thanks alot for the reply. Since the Full Control category of the fleet adapter has already been implemented in the rmf core library, does that mean that we do not need to implement fleet adapter anymore and could just use it if the project needed a fleet adapter for full control of the robot?

for the traffic light control level of the fleet adapter, if the project needs it, the project team will then need to create a package to implement a node for traffic light level adapter node which make use of the TrafficLight class that you mentioned in your reply. Am I right?

[imdalaf]

i am wondering what are the area of work that is involved in a project that uses rmf to control multiple robots to make deliveries and perform conflict prevention and resolution. The expected level of control for the robot is at traffic light level and gazebo will be used to simulate the environment.

Based on that, I understand that for:

• the execution of the task or job, a GUI interface module will need to be implemented to accept the job and send it to the fleet manager. It is from the fleet manager that it sends the routing command of the robot via the FleetState msg.
• the conflict function, the project will need to develop its own third party judge to select the best proposed itinerary.
• the simulation, the project will need to create the modelling of the environment and use the traffic editor to create the route for the robot to know where to traverse.
• the controlling of the fleet in the simulation, an implementation of the fleet manager into the gazebo plugin (.so object) is needed.
• ultimately for the controlling of the robot after we are done with the simulation, the fleet manager has to be able to send and receive ROS 2 topics (route pub from fleet adapter (only for full control), mode pub from fleet adapter, state update pub to fleet adapter)

i am still in the stage of understanding RMF and understand how operations such as door control and lift control is to be triggered and what are the work involved on for the developer to make the robot be able to control door and lift.

besides what I have pointed out, can you advice what are the work that are involved and that I can proceed to look into them to understand the implementation effort? Also, is my understanding of the work involved correct so far?

[mxgrey]

Since the Full Control category of the fleet adapter has already been implemented in the rmf core library, does that mean that we do not need to implement fleet adapter anymore and could just use it if the project needed a fleet adapter for full control of the robot?

To be clear about terminology, you can use the rmf_fleet_adapter API to develop a "fleet adapter". The thing referred to as a "fleet adapter" will usually be an executable that combines the rmf_fleet_adapter API with a fleet manager's API. See this diagram for reference:

The three puzzle pieces in the middle combine together to form the so-called "fleet adapter" executable. The top piece comes from this repo. The bottom piece need to be provided by the fleet manager. The "Integration" piece only needs to be made once per Fleet Manager API as long as the implementation is shared by whoever does it. So far an "Integration" piece only exists for the MiR100 robot API and for ROS1 robots that use the standard navigation stack. If you are working with a different type of robot or fleet manager, then you will need to make the "Integration" piece.

for the traffic light control level of the fleet adapter, if the project needs it, the project team will then need to create a package to implement a node for traffic light level adapter node which make use of the TrafficLight class that you mentioned in your reply. Am I right?

Yes, this is accurate. The overall idea is the same as what's shown in the above diagram, but the rmf_fleet_adapter API block refers specifically to the rmf_fleet_adapter::agv::TrafficLight API.

the execution of the task or job, a GUI interface module will need to be implemented to accept the job and send it to the fleet manager.

For traffic light controllers, it will be the responsibility of the "Integration" piece to listen for the task requests (this is not provided by the rmf_fleet_adapter API) and forward them to the fleet manager API. So yes, this is accurate.

It is from the fleet manager that it sends the routing command of the robot via the FleetState msg.

The FleetState message is used by the Dashboard to visualize the robot locations and provide information to human operators, but it is not what the traffic schedule or traffic negotiation systems use. It's a good idea to publish the fleet states if you want to use the Dashboard, but you will still need to use the TrafficLight API for the traffic management to work.

the conflict function, the project will need to develop its own third party judge to select the best proposed itinerary.

This is up to you. A judge is already provided in the rmf_traffic_ros2::schedule::Node implementation. If you decide that you need to customize the judge, let us know and we can refactor this schedule node implementation so that it's easier for you to replace this judge.

the simulation, the project will need to create the modelling of the environment and use the traffic editor to create the route for the robot to know where to traverse.

The traffic-editor can also generate a simulation world for you, but you're welcome to create your own if you prefer.

the controlling of the fleet in the simulation, an implementation of the fleet manager into the gazebo plugin (.so object) is needed.

This is one option. Another option is to write a plugin that gets loaded to control each robot, and have the fleet manager talk to the robots over the per-robot API as if they were the actual robots.

ultimately for the controlling of the robot after we are done with the simulation, the fleet manager has to be able to send and receive ROS 2 topics (route pub from fleet adapter (only for full control), mode pub from fleet adapter, state update pub to fleet adapter)

In the current phase of RMF, being fully integrated does require some use of ROS2 topics. We're trying to improve the rmf_fleet_adapter APIs so that system integrators don't need to worry about any ROS2 topics, but we haven't reached that stage yet. If you are using the Traffic Light API, here are the categories of topics to look out for:

• FleetState messages (publish)
• Task request messages (subscribe)
• Task summary messages
• Emergency alarm

In the current phase, these need to be handled in addition to using the Traffic Light API. In a future phase of RMF, we expect that these will get wrapped up by an API similar to the rmf_fleet_adapter APIs.

i am still in the stage of understanding RMF and understand how operations such as door control and lift control is to be triggered and what are the work involved on for the developer to make the robot be able to control door and lift.

For lifts, you should send a LiftRequest message over the adapter_lift_request topic. This will create a session with the lift that will allow your fleet manager to control where the lift is going. Just make sure to watch the session_id field of the LiftState to make sure that it's your session which is active.

Doors are somewhat similar. You send a DoorRequest message over the adapter_door_requests topic to create a session. Then listen to the door_supervisor_heartbeat topic to see whether your session is active. Asking a door to open will begin the session while asking the door to close will end the session. Unlike the lifts, multiple sessions can be active for a door at once, and the door will remain open for as long as one or more sessions are active.

We have plans to provide a more advanced Traffic Light API that can automatically take care of this infrastructure interaction, but it hasn't bubbled to the top of our priority list yet.

[imdalaf]

In the current phase of RMF, being fully integrated does require some use of ROS2 topics. We're trying to improve the rmf_fleet_adapter APIs so that system integrators don't need to worry about any ROS2 topics, but we haven't reached that stage yet. If you are using the Traffic Light API, here are the categories of topics to look out for:

FleetState messages (publish) Task request messages (subscribe) Task summary messages Emergency alarm

Thanks very much for the reply. Would like to check on the last two messages on how are they used and how do i subscribe to them. For Task summary messages, i can find the topic name but I don't know how to use it. For Emergency alarm, I couldn't find the topic name not know how to use it. I have found something related to emergency which is the emergency notice under the lift and it is a bool msg.

Also, I would thought that the the rmf_fleet_msgs/ModeRequest msg will be needed to pause and resume the robot as I am expecting the robot to work at the Traffic Light control level.

When I look at the FleetDriverRobotCommandHandle and RobotCommandHandle code from the full control example, it looks like the primary functions are:

• follow new path
• stop
• dock Is is that for full control, the robot is not expected to receive pause and resume command?

[mxgrey]

For Task summary messages, i can find the topic name but I don't know how to use it.

This is the message definition that's used on that topic. There aren't strict conventions yet for how to fill out that message, and I expect the definition to undergo some significant changes before we reach deployment, so feel free to take liberties when using it.

For Emergency alarm, I couldn't find the topic name not know how to use it. I have found something related to emergency which is the emergency notice under the lift and it is a bool msg.

This is the topic name, and indeed it uses a std_msgs::msg::Bool. The bool will have a true value when an emergency is active, and it will have a false value when there is no emergency active.

Also, I would thought that the the rmf_fleet_msgs/ModeRequest msg will be needed to pause and resume the robot

No, that message definition is deprecated. It's part of an older API that is no longer recommended but still temporarily supported. Instead you should use the TrafficLight API. With that API, you pass in a path that your robot will follow and you get back "departure times" for each waypoint along the path. That means if your robot reaches a waypoint before the departure time that you were given for that waypoint, then you must pause your robot or else it may find itself in a traffic conflict.

By design, you will not receive explicit pause/resume commands from RMF because that kind of scheme is too fragile:

• You would need to hammer RMF with state updates from your robot in order for RMF to issue the pause command at the exact right time
• Any kind of network latency might result in a pause command being received too late

So instead we give you the timing information that you're expected to follow, and then you can decide how to issue the correct pause/resume commands to your own system. You will be issued a new batch of timing information whenever schedule changes or delays change the timing that your robot needs to follow.

Is is that for full control, the robot is not expected to receive pause and resume command?

Correct, pause and resume commands are not needed for full control, because the full control scheme gives timing information when issuing the path that the robot is supposed to follow. If the robot needs to pause, it will simply receive a new path command where it will be required to wait at one of the waypoints. Whenever a new path command is issued, the robot is required to immediately discard its current path and follow the new one.

[imdalaf]

thanks very much for the reply.

would like to find out if there is a module inside rmf_core that handles the synchronization of control of the fleet navigation and the lift control. Imagine that we have a use case that we want to implement function to control robot to move from point to point at two different level via lift. Is this handling of the synchronization of task execution of moving the robot to the lift -> then call for the lift -> move the robot into the lift -> command the lift to move to destination floor -> move the robot out of the lift to the destination typically implemented by the fleet adapter or there is a module within RMF that handles it?

also, we are planning to come up with a module to detect static and moving obstacles. The information of the obstacles will be published to the RMF ROS2 channel. We are thinking of the possibility of creating a participant to represent the obstacle and making use of the conflict functionality in RMF traffic to perform the conflict prevention and resolution. Note that the real robot is expected to be in the traffic light control category. Would like to ask, in your view:

• is the plan to create participant and making use of conflict function in RMF to do obstacle avoidance an ideal approach? If not, why and do you have alternate suggestion?
• if there any references, classes and modules that you can advice us to look into?

[mxgrey]

Is this handling of the synchronization of task execution of moving the robot to the lift [...] typically implemented by the fleet adapter or there is a module within RMF that handles it?

For the "full control" type of fleet adapter, yes, this is all taken care of automatically by the rmf_fleet_adapter API. Your fleet adapter wouldn't need to worry about these details.

For the current "traffic light" type of fleet adapter, this is not taken care of automatically by the rmf_fleet_adapter API, so your custom portion of the fleet adapter will need to take care of that. It was intentionally designed like this to be backwards-compatible with existing fleets that already have their own building integration. We have plans to create an alternative "traffic light" API that will also take care of automatically interacting with building infrastructure (i.e. doors and lifts), but there isn't a hard timeline set for that yet.

is the plan to create participant and making use of conflict function in RMF to do obstacle avoidance an ideal approach?

This can be a reasonable way to begin prototyping the problem, although I might suggest iterating on this approach for a few reasons:

• Traffic participants are usually expected to participate in "negotiation". The "read-only" fleets are an exception to this at the moment, and perhaps we should reconsider whether those are really "participants" if we're going to be developing a system that accommodates non-compliant obstacles.
• When it comes to external obstacles, the individual robots are expected to use their onboard sensors to route themselves around the obstacles instead of relying on the fleet adapter to make plans to get around the obstacles. Perhaps instead of representing the obstacles as occupied volume that the robots need to avoid, we could instead pass the obstacles information through some kind of machine learning algorithm that could estimate the delays that the robot would experience due to the obstacles. Then the fleet adapter planner can make a higher level decision about rerouting based on expected delays. You can think of this as the difference between Google Maps recommending an alternative route due to high traffic congestion versus drivers using their eyeballs to weave themselves through the traffic around them.

if there any references, classes and modules that you can advice us to look into?

If you want to start the prototyping by just having the static obstacles be traffic schedule participants, then you'll want to look at rmf_traffic::schedule::Participant for the API that lets you push trajectory information to the schedule. The rmf_traffic_ros2::schedule::Writer will help with creating a Participant instance that you can create in your own ROS2 node and have it write to the global schedule database.

For the later stages after prototyping, if you want to use the obstacle approach, the most relevant class would be the rmf_traffic::agv::RouteValidator interface. You can create a custom RouteValidator implementation that will reject any trajectory that collides with a static obstacle. Just make sure to have a way to combine it with the implementation of rmf_traffic::agv::ScheduleRouteValidator so that plans that conflict with the schedule will also be rejected. Maybe there can be an AggregateRouteValidator implementation of RouteValidator that can aggregate multiple RouteValidator implementations into one.

If you're interested in adding weights to lanes based on the presence of obstacles, you would want to look at rmf_traffic::agv::Planner (the meat of its implementation can be found here). You'd probably want to add a field to the Planner::Options class to specify a weight map for each lane, representing the delays that a robot would experience if trying to go down that lane.

[imdalaf]

Thanks for the reply.

It seems to me that the full control type of fleet adapter would requires less handling of work as a lot of the work for synchronization of task execution has already been handled by the existing rmf libraries as compared to traffic light control type of fleet adapter.

I have previously imagined that traffic light control type of the fleet adapter would requires less work because there is limited control over the fleet (i.e.: only pause and resume). So, in that sense, maybe the interfacing of to the rmf_traffic library will be lesser when it comes to using conflict prevention and resolution functionality.

But then, because the full control fleet adapter currently has a working example api provided (rmf_core/rmf_fleet_adapter/src/full_control/), in terms of difficulty in implementing a fleet adapter, the full control version will be easier because there is a working example to reference to.

So, all in all, it will be easier to implement a full control type of fleet adapter. But of course, having said that, the freedom to choose depends on how much control we can have over vendor's fleet manager. In the event that we can freely control level which the robot's fleet manager has to provide, integrating a solution using full control level control of the fleet adapter will be easier than traffic light level of control. Am I right?

[imdalaf]

When it comes to external obstacles, the individual robots are expected to use their onboard sensors to route themselves around the obstacles instead of relying on the fleet adapter to make plans to get around the obstacles.

For the expectation for obstacle avoidance lies on the sensor of the robot and the robot itself, if the scenario is that the pathway is broad and the obstacle is a small one which the robot can easily moves slightly to the left or right to get by the obstacle, then there is no issue at all. But if it is the case that if the robot were to travel along a narrow pathway which the obstacle is blocking the whole pathway, then in this case, the obstacle avoidance meant that the robot will have to do re-routing. In this case, if the re-routing work is to be perform separately from the conflict function provided by the RMF, then there is significant complexity added to the solution. If we can tap on the conflict function of the RMF to perform obstacle avoidance re-routing, then that would save a lot of un-necessary work.

[mxgrey]

In the event that we can freely control level which the robot's fleet manager has to provide, integrating a solution using full control level control of the fleet adapter will be easier than traffic light level of control. Am I right?

Right, "full control" is the gold standard and always the recommendation for what kind of fleet adapter to make. The only reason the "traffic light" exists is to accommodate platforms that aren't (at least yet) compatible with a "full control" approach.

If we can tap on the conflict function of the RMF to perform obstacle avoidance re-routing, then that would save a lot of un-necessary work.

This is a very tricky issue when you start to dig into it. If we choose to eliminate routes that contain enough obstacles to create a complete blockage, then what if all the routes have that kind of blockage? The planner will fail to find any path, and then the robot should do what? Abandon its task? Sit where it is, and set a timer to try again later?

In the production systems that I'm familiar with, robots that find their way completely blocked will usually just start to make sad noises until someone moves the obstacles out of their way. Maybe they'll flash red lights, maybe they'll make R2D2 noises, maybe they'll have some kind of voice notification, but essentially they'll ask nearby humans for help. I think this is the preferable strategy when it comes to temporary obstacles that aren't supposed to be present.

Imagine if the robot needs to choose between a route that will take it 1 minute to get to its destination or a route that will take 15 minutes to get to its destination. Should it disregard the 1-minute route just because some when it was making its plan there happened to be some temporary obstacles blocking its path? It may end up taking the 15 minute path even though it would've only taken 20 seconds for the robot to get some assistance from nearby humans to remove the obstacles.

That's why instead of treating clutter as rigid obstacles, I think it may be better to come up with some model (perhaps a model learned from data) of how patterns of temporary clutter add delays. Those delay predictions can be added to the routes as weights so that low-clutter routes are given preference over high-clutter routes, but in a way that's weighed to the expected outcomes of the clutter.

[imdalaf]

thanks for the reply.

Right, I can see the distinct preference for the full control approach and understands the rationale too. Looks like my project should go for full control adapter instead of traffic light control adapter.

Yup, I also sense that things will get significantly more complex and complicated when we attempt to achieve obstacle avoidance through re-routing. But if one day, we want to achieve full automation without human or very minimum human in the system, then this ability of performing re-routing on its own will be essential. The operating hours may be during late night and wee hours and the time isn't too much of an issue to the operation.

That's why instead of treating clutter as rigid obstacles, I think it may be better to come up with some model (perhaps a model learned from data) of how patterns of temporary clutter add delays. Those delay predictions can be added to the routes as weights so that low-clutter routes are given preference over high-clutter routes, but in a way that's weighed to the expected outcomes of the clutter.

feels that this approach is significantly more complex because it involves more than software engineering domain and the time needed to do modelling and training make takes a longer time as well. Also, the approach to use delay prediction and re-routing using the RMF traffic are both doing re-routing.

The difference is that for the delay prediction approach, it allows the system to consider which route to choose based on the time needed to completes the route, factoring the delay into consideration. For the re-routing using the RMF conflict function, i am not sure if it is able to choose another route which is the most efficient. So far i have seem the robot (A) in the demo app doing minor adjustment to the route by moving out of the way of the conflicting area, once the other robot (B) has moved passed robot (A), robot (A) will move back to continue the moving along the original path. But based on my understanding this far, it could have taken another route if another route is more efficient that what I have seen.

[mxgrey]

But based on my understanding this far, it could have taken another route if another route is more efficient that what I have seen.

That's right. Most of the time the robot will simply move aside temporarily and then resume its course, because that's usually the most efficient way to deal with a conflict. But depending on the overall schedule, a robot may choose to completely reroute itself to avoid conflicts with other robots. If we just add delays onto the choice to go down certain lanes, the planning system will trivially take that into account and avoid routes with excessive delays.

The operating hours may be during late night and wee hours and the time isn't too much of an issue to the operation.

This still neglects the concern that the robot is unable to find any obstacle-free route. If we use obstacles as "hard" constraints (i.e. we eliminate any choice that collides with the obstacle) then we need a way to deal with the possibility that the planner will not be able to produce a viable solution. We wouldn't have to worry about that if the obstacles are "soft" constraints (i.e. we add a cost based on obstacles but do not eliminate choices that collide with them), although we would still need a way to alert human operators that an obstacle needs to be moved.

Another factor that needs to be accounted for here is that treating obstacles as hard constraints will require freespace motion planning to be used within the traffic planner. Right now the planner is using A* on predetermined routes which is extremely fast. We can add a freespace planning element into a RouteValidator implementation, but it may slow down the planning time considerably, depending on how it's implemented. The best case scenario maybe we can leverage convex shapes to generate paths quickly, but that's not a trivial effort.

There's also the issue that if we're talking about dynamic/moving obstacles, then the plan that gets generated by the traffic planner might be out of date by the time the robot arrives at the obstacles. This is another reason I'd rather let the robot's onboard local planner deal with navigating around obstacles and just have the traffic planner focus on efficiency/delay predictions rather than precise motion planning.

But none of this should be taken as discouragement. These are just concerns that come to mind based on my experiences with task and motion planning. I fully support experimenting with different ideas for obstacle avoidance and motion planning. I think whatever approach you want to experiment with, we should be able to expand the traffic planner API to accommodate it.

[imdalaf]

thanks for the reply.

I am looking at tracing the execution flow of execution of Delivery task. RMF core FleetUpdateHandle code handles the perform delivery function and is specifically tied to the Delivery msg defined in the rmf_task_msg::msg::Delivery. Which means that if my project has a different delivery job which doesn't involve ingestor and dispenser, then there will be a problem.

Example: void FleetUpdateHandle::Implementation::perform_delivery( const rmf_task_msgs::msg::Delivery& request, const DeliveryEstimate& estimate) in https://github.com/osrf/rmf_core/blob/master/rmf_fleet_adapter/src/rmf_fleet_adapter/agv/FleetUpdateHandle.cpp

Due to my limited experience working on opensource projects, I have the impression that to use RMF framework, we do not need edit the code inside the framework and to change the behavior, we should extend the classes in the library to produce our own custom version to run the custom behavior.

But now I am forming a different picture in my mind and it seems that the approach is to edit the code of rmf_core directly to tweet the behavior that my project requires. Am I understanding it correctly?

[imdalaf]

Hi @mxgrey

Thanks again for your clarification to my question on Sep 14.

I refer to your reply on Sep 14 and have have the following questions: 1)

The FleetState message is used by the Dashboard to visualize the robot locations and provide information to human operators, but it is not what the traffic schedule or traffic negotiation systems use. It's a good idea to publish the fleet states if you want to use the Dashboard, but you will still need to use the TrafficLight API for the traffic management to work.

If traffic schedule or traffic negotiation doesn't use the information in the FleetState, then how does the location and route information in the schedule database get updated?

2) Am I right that the communication between fleet adapter and fleet manager can be in any protocol and that won't be a concern for RMF. It can be rabbitmq, can be TCP/IP or any form. What RMF needs is that the communcation between fleet adapter and RMF is in ROS2.

3)

For lifts, you should send a LiftRequest message over the adapter_lift_request topic. This will create a session with the lift that will allow your fleet manager to control where the lift is going. Just make sure to watch the session_id field of the LiftState to make sure that it's your session which is active.

Is it the fleet adapter that controls the lift or the fleet manager? I have the impression that after the delivery job has been converted into Task and if the job requires the robot to take the lift, these list of tasks including moving to lift, calling lift and taking lift etc would be push to the task manager of the fleet and handled outside of fleet manager.

[mxgrey]

Due to my limited experience working on opensource projects, I have the impression that to use RMF framework, we do not need edit the code inside the framework and to change the behavior, we should extend the classes in the library to produce our own custom version to run the custom behavior.

There are a lot of ways we could approach things if the existing design is not suitable.

1. You can fork the codebase and unilaterally make whatever changes you want, without collaborating with us on it. This is the quickest, easiest, and dirtiest way of dealing with an incompatibility. This is not generally recommended because (a) Your changes might not be compatible with changes that we make to RMF in the future, which means you'll miss out on future developments, and (b) If the design is incompatible for you, it's probably incompatible for others as well, so we could work together to make a better design instead of everyone forking off and doing their own thing.

2. You can fork the codebase, make some improvements, and submit it back to us as a pull request. This is preferable to option (1) because it helps to strengthen the overall community of RMF, and it makes sure that you can still benefit from our future developments.

3. You can open a discussion with the community about why the current design doesn't fit your needs. For example, there is already a discussion about extending the delivery request message here. You could either get involved in that discussion or open a new ticket to begin a new discussion if your concern is sufficiently different from the topic in that issue. This option will usually either be followed by option (2) or we (the developers+maintainers of rmf_core) might take it on ourselves to implement the changes that the community asks for.

[mxgrey]

If traffic schedule or traffic negotiation doesn't use the information in the FleetState, then how does the location and route information in the schedule database get updated?

The rmf_fleet_adapter library takes care of this. The exact details will depend on whether you're using the "full control" API or the "traffic light" API.

The FleetState messages are indeed still used by the "legacy full control" fleet adapter, but as I mentioned here that legacy fleet adapter is not generally recommended.

Am I right that the communication between fleet adapter and fleet manager can be in any protocol and that won't be a concern for RMF. It can be rabbitmq, can be TCP/IP or any form.

Correct.

What RMF needs is that the communcation between fleet adapter and RMF is in ROS2.

To use all the out-of-the-box tools that we provide, yes, those tools are implemented on top of ROS2.

Is it the fleet adapter that controls the lift or the fleet manager?

Ultimately this depends on how the system integrator wants (or needs) to set it up. There are some legacy systems which are already installed in various facilities where the fleet manager talks to the lift directly. In those cases, it may be up to the fleet manager to control the lift. For new green field RMF systems, it's recommended that the full control fleet adapter be allowed to control the lift.

Typically the legacy systems will prefer the "traffic light" API over the "full control" API anyway, and the "traffic light" API right now doesn't do anything with lifts or doors; it leaves all of that up to the fleet manager.

A full control fleet adapter could still be used alongside a fleet manager that directly controls the lifts and doors. The only catch is that the system integrator will need to "spoof" the lift and door state messages that the full control fleet adapter is listening for.

[imdalaf]

Thanks for the reply.

If traffic schedule or traffic negotiation doesn't use the information in the FleetState, then how does the location and route information in the schedule database get updated?

The rmf_fleet_adapter library takes care of this. The exact details will depend on whether you're using the "full control" API or the "traffic light" API.

My project has now decided to use the full control fleet adapter. Talking about route, my team is discussing the approach which the fleet route is generated. The fleet manager commonly has the ability to generate route for the robot to execute and therefore, it makes sense to use fleet manager to generate the route and send it to the fleet adapter and then rmf core. However, we understand few issues:

• the fleet manager planned route is internal to itself, if we want the fleet manager to plan according to the navigation graph routes hold by rmf, then some development work needs to be done.
• if the fleet manager were to be in charge of route planning, then when there is conflict, then the RMF will need to interface with fleet manager instead of just only the fleet adapter

Based on what i understand, the RMF is designed to do the planning at global level (i.e.: taking consideration of all the participants) to give a more optimum route plan for the robot.

Can I tap on your experience to understand the pros and cons on using fleet manager to do the route planning?

[mxgrey]

if we want the fleet manager to plan according to the navigation graph routes hold by rmf, then some development work needs to be done.

Maybe I'm reading too much into this statement, but I think there may be a misunderstanding here. RMF does not hold any navigation graph routes. Fleets that are integrated into RMF are not constrained to any particular navigation graph. Every fleet can have its own navigation graph that is completely independent of the rest of the fleets. The traffic schedule system will automatically identify conflicts based on the spacetime trajectories of the robots, no matter what navigation graphs any of the fleets are using.

If you know what the fleet manager's navigation graph is, then you can put that navigation graph directly into its fleet adapter.

use fleet manager to generate the route and send it to the fleet adapter and then rmf core

If the fleet manager is able to tell you what route the robot will follow, and the fleet manager is also able to accept pause/resume commands, then it may be a good fit for the "Traffic Light" fleet adapter. It won't generally be as optimal at dealing with conflicts as the "Full Control" fleet adapter, but it would allow you to let your fleet manager generate the routes, and then you don't have to worry about defining a navigation graph for your fleet.

Can I tap on your experience to understand the pros and cons on using fleet manager to do the route planning?

When you use the "Full Control" fleet adapter, you have to simply let the fleet adapter decide what routes the robot will follow. The fleet manager is no longer used for global route planning at that point. I can't imagine much point in having two different modules planning entire global routes when only one of them is taking the robot traffic into consideration.

[imdalaf]

When you use the "Full Control" fleet adapter, you have to simply let the fleet adapter decide what routes the robot will follow. The fleet manager is no longer used for global route planning at that point. I can't imagine much point in having two different modules planning entire global routes when only one of them is taking the robot traffic into consideration.

Thanks for the reply. I fully agree on this point.

[mxgrey]

Closing as this is not an issue. To continue discussing this topic, please open a discussion.