Main contents of "Traffic Monitor" and "Dispatcher Planner"

[Jason-Zhou1]

I have attended a Romi-H webinar and found a slide to describe the Romi-H structure. The slide is shown as below: May I know what are the main contents of the module "Traffic Monitor" and "Dispatcher Planner" in the "The Core Systems"?

[mxgrey]

This diagram is a rough abstraction of the concepts behind RoMi-H, and these bubbles won't always map to a single specific module that can be pointed at. As we iterate on the design and implementation of RoMi-H, I think we'll start to converge on a high-level diagram that maps more accurately to specific modules, but for now these diagrams need to be viewed in the abstract instead of in the literal.

The "Traffic Monitor" could refer to the component of the schedule database that announces traffic conflicts whenever they appear. That functionality currently lives inside the schedule node.

The "Dispatch Planner" module is currently a work in progress. So far the demo platforms that have been developed for RMF did not require a planner to dispatch tasks to different fleets, because in all the demo platforms done so far, each task type could only be performed by one of the fleets. So task dispatching was trivial: The task gets assigned to whatever fleet is capable of performing the task, while the rest of the fleets just ignore the task request.

We are currently working on a true dispatch planner and formal task bidding system which we're aiming to include in release 1.2.0, slated for end of December 2020. The idea is that every fleet that can perform a task request will offer a bid for how much it would "cost" them to perform a task, and the bid with the lowest "cost" will be the winner. The "cost" will be determined by two factors:

1. How quickly the task is finished
2. How much other tasks get delayed if the new task needs to preempt them

[Jason-Zhou1]

Hi @mxgrey Thank you for your detailed explanation! I have 2 more questions to ask:

1. What's the main difference between "rmf_traffic" and "rmf_traffic_ros2"?
2. Where is the Costmap located in the Romi-H system?

[mxgrey]

What's the main difference between "rmf_traffic" and "rmf_traffic_ros2"?

rmf_traffic provides a middleware-neutral implementation of the core traffic scheduling algorithms and utilities.

rmf_traffic_ros2 provides convenient wrappers for using the rmf_traffic utilities as part of a distributed ROS2 system.

There is no ROS2 dependency in rmf_traffic, so those utilities can be used in any kind of application or distributed across any kind of middleware.

Where is the Costmap located in the Romi-H system?

There is no costmap representation in rmf_core. Costmaps are one method that is typically used for representing volume occupancy for autonomous navigation planning. While it's true that the traffic utilities deal with navigation planning, they are principally concerned about identifying conflicts between the intended routes of autonomous vehicles. The traffic utilities are not responsible for the "local" navigation of vehicles around static or temporary obstacles in their environment.

Different robot platforms often have different representations of costmaps, many of which may be proprietary. On top of that, different robot platforms with the same costmap representations may still require different costmap values because of differences in the robot's external profile. Because of these factors, we leave it to the robot platforms themselves to determine how they represent their costmaps.

If it's important for a system integrator to take a robot's costmap into account when performing traffic planning, they can implement a custom rmf_traffic::agv::RouteValidator that uses the robot's custom costmap when determining whether a candidate route is valid.

[Jason-Zhou1]

Hi mxgrey, I have found two planning files in rmf_core, 1: ../rmf_fleet_adapter/src/rmf_fleet_adapter/jobs/Planning.cpp 2: ../rmf_traffic/src/rmf_traffic/agv/Planner.cpp Are they doing the different tasks? Thank you!

[mxgrey]

rmf_traffic/src/rmf_traffic/agv/Planner.cpp implements the API provided by the rmf_traffic/agv/Planner.hpp header, which provides the rmf_traffic::agv::Planner class, its nested classes (namely Planner::Configuration, Planner::Options, Planner::Start, Planner::Goal, and Planner::Result), and the rmf_traffic::agv::Plan class (along with its nested class Plan::Waypoint). This API is designed to be as generic and generally usable as possible.

rmf_fleet_adapter/src/rmf_fleet_adapter/jobs/Planning.cpp uses the rmf_traffic/agv/Planner.hpp API alongside rxcpp and ROS2 to implement a multi-threaded reactive traffic planner for fleet adapters. It's used for both "full control" and "traffic light" categories of fleet adapters.

[Jason-Zhou1]

Hi mxgrey, For the "conflict detection" algorithm, I still cannot understand what are the rules or conditions for rmf_traffic to determine the conflict status. Would you please give me some explanations about that? Thanks a lot!

[mxgrey]

For the traffic management framework, there are three important pieces of data that every participant (i.e. robot) must provide:

• itinerary: a sequence of piece-wise cubic splines that describe where the robot intends to be in the future
• footprint: a shape that describes the approximate 2D outline of the robot
• vicinity: an area around the robot which needs to be kept clear of other robots to avoid interfering with the robot's operation

The footprint and vicinity of a robot follow along the itinerary as a function of time. Given Robot A and Robot B, a conflict happens if the position of Robot A ever gets closer to the position of Robot B when the footprint of Robot A is inside the vicinity of Robot B.

This means that robots are allowed to get closer to each other as long as the footprint of one isn't touching the vicinity of another.

This also means that it's never a conflict for two robots to move further away from each other. This point is important for dealing with situations where robots start out inside of each other's vicinity, which can happen due to inaccurate predictions or network latency. When that happens, we simply require that the robots make a plan to immediately move away from each other.

[Jason-Zhou1]

Hi mxgrey, May I know where is the main() function to call the conflict detection procedure? Thanks!

[mxgrey]

Traffic conflict detection is implemented in the rmf_traffic library, and that library gets used in many many places within the RMF system, including in all of the traffic planners and traffic negotiators.

But I'll guess that you're asking for the entry point of the ROS2 node that takes care of announcing conflicts that show up on the schedule. The main() function for that node can be found here. That function spawns and runs an rmf_traffic_ros2::schedule::Node instance. Inside of that instance, there is a thread running that is dedicated to detecting and reporting any conflicts that show up on the schedule.

[Jason-Zhou1]

hi mxgrey, I have seen doxygen folder in the rmf_core repo(rmf_fleet_adapter/rmf_rxcpp/RxCpp-4.1.0/Rx/v2/examples/doxygen/). Can we generate some class diagram or pseudocode for rmf_core (especially DetectConflict and Negotiation) from files in this folder? Thanks!

[mxgrey]

The file you're referring to comes from the rxcpp library which is being used internally by the rmf_fleet_adapter package. It's a third-party library which we've integrated into rmf_fleet_adapter by simply copy/pasting the source code into our repo.

I don't know for sure, but it looks to me like the doxygen folder you've pointed to is meant to provide code snippets that are probably used by rxcpp's doxygen examples. It doesn't help with the process of actually generating any documentation.

That being said, all the public API headers of all the packages in rmf_core have been thoroughly documented with doxygen-friendly markup. It should be straightforward to set up scripts to generate doxygen documentation for the rmf_core packages if anyone is interested in contributing that.

[mxgrey]

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