Customization of the Task Planner (#508)

Posted by @anandharaj-dotworld:

I’m looking for guidance on how to customize the RMF planner to better meet our specific needs. Can we integrate custom planning algorithms, adjust planning parameters, and adapt plans dynamically based on real-time data or user-defined rules? Additionally, what options are available for configuring planning behavior and priorities to better align with our operational requirements?

Posted by @anandharaj-dotworld:

@Yadunund Have you any idra for this improvement.

Posted by @Yadunund:

Hi @anandharaj-dotworld,

I’ve moved your ticket to the Discussions board.

Presently, the rmf_task::TaskPlanner is not modular enough to swap out the algorithms employed. Certain options can be updated between planning calls. It also handles battery constraints although a modular interface to support a wide variety of constraints would be beneficial.

As part of our on-going efforts to develop the next generation of Open-RMF, we will likely redesign our task allocation framework while utilizing the more modular mapf framework. We have no committed timelines for this development.

in the meanwhile, there may be ways to address your use case with the existing framework:

and adapt plans dynamically based on real-time data or user-defined rules

The rmf_task library is used by the rmf_fleet_adapter library to to solve task (re)allocation dynamically given the state of fleets during runtime. You should be able to write a custom ROS 2 node that reacts to your user-defined rules and other conditions to submit requests to modify/cancel/reschedule tasks on the fly. Eg. Say a robot from a fleet is scheduled to clean a particular area but this area is closed down due to maintenance. You can have a ROS 2 node that ingests the maintenance schedule and submit a cancellation + reschedule task request to the Dispatcher node using definitions in rmf_api_msgs. See examples of sending task request.

Additionally, what options are available for configuring planning behavior and priorities to better align with our operational requirements?

It would be helpful if you can provide a detailed explanation of the behaviours you would like to support along with your operational requirements.

Posted by @mxgrey:

Fully agreed with everything mentioned here.

I’ll add that I don’t expect we’ll make significant changes to the customizability of the rmf_task that exists today, but all feedback on intended use cases, expectations, and requirements will be taken into account as we develop the “next generation” of task management, which we fully intend to make far more modular and customizable.

Posted by @anandharaj-dotworld:

Hi @Yadunund ,

Thanks for your response. I’m trying to set up a condition-based flow. For example, when I send a go_to_place request to a robot, I want to trigger a specific activity if the robot successfully reaches the waypoint. Conversely, if the robot fails to reach the waypoint, I want to execute a different activity. Is it possible to achieve this by rewriting the planner?

Posted by @mxgrey:

This is more of a task execution issue than a task planner issue, although it does touch on both.

Conditional workflows for tasks is not something that the current generation of Open-RMF is meant to support, but it’s a key feature that we’re targeting for the “next generation” of Open-RMF.

The closest you can get to what you’re describing with the current generation of Open-RMF is to do the following:

  1. Turn off “finishing tasks” and “responsive wait” so the robots don’t perform any automatic actions when they run out of tasks.
  2. Carefully issue direct task requests to the individual robots according to what you want them to do. Each step of your intended task workflow should be issued as a direct task, and then you supervise the activity of the robot from some kind of task manager which will issue the next segment of the task workflow when needed.

I want to caution that this is a very risky approach since you’ll be taking a heavy amount of responsibility for RMF operations that would normally be managed by the core.

If possible, I would recommend seeing if your conditionally branching activity can be expressed as a single perform_action that you can plug into a composed task definition. Then you can use the existing task pipeline as-is.

Posted by @anandharaj-dotworld:

This is more of a task execution issue than a task planner issue, although it does touch on both.

Conditional workflows for tasks is not something that the current generation of Open-RMF is meant to support, but it’s a key feature that we’re targeting for the “next generation” of Open-RMF.

The closest you can get to what you’re describing with the current generation of Open-RMF is to do the following:

  1. Turn off “finishing tasks” and “responsive wait” so the robots don’t perform any automatic actions when they run out of tasks.
  2. Carefully issue direct task requests to the individual robots according to what you want them to do. Each step of your intended task workflow should be issued as a direct task, and then you supervise the activity of the robot from some kind of task manager which will issue the next segment of the task workflow when needed.

I want to caution that this is a very risky approach since you’ll be taking a heavy amount of responsibility for RMF operations that would normally be managed by the core.

If possible, I would recommend seeing if your conditionally branching activity can be expressed as a single perform_action that you can plug into a composed task definition. Then you can use the existing task pipeline as-is.

The approach wasn’t feasible because each task had unique conditions, requiring dynamic customization of task formats. Additionally, i needed to gather information at runtime, further complicating the process and making it challenging to manage tasks manually or fit them into a pre-defined structure.


Edited by @anandharaj-dotworld at 2024-08-20T15:41:45Z

Posted by @anandharaj-dotworld:

I would like to write my own conditional task planner, can you give some KT for how task planner was working

Posted by @anandharaj-dotworld:

Currently, I am using a logic where each activity is treated as a separate plan and executed as an individual task. Once a task is completed successfully, the next task is initiated based on specific conditions. However, this approach introduces delays between tasks, making the process time-consuming.

Posted by @mxgrey:

Once a task is completed successfully, the next task is initiated based on specific conditions.

This is the only feasible way to get what you want in the current generation, so I’m glad you were able to make that work.

However, this approach introduces delays between tasks, making the process time-consuming.

If you can put the task flow logic into your fleet adapter code then you can use the rmf_fleet_adapter API for direct task requests [C++][Python]. There wouldn’t be any noticeable latency to this beyond what you would get if you could directly integrate the logic into the task execution the way you were originally asking. The only downsides are

  1. Each segment of the task will be portrayed as a separate task by Open-RMF, and
  2. You’ll need to manage task ordering and idle behavior manually

Posted by @anandharaj-dotworld:

Yes, You are correct, i was currently implemented like this, I was handle all the flows as manually, that was i asking to create new task request format like as conditional flow.

Posted by @anandharaj-dotworld:

Is that possible to give, the direct request on the task_api_request topic?

Posted by @mxgrey:

Correct you can also use task_api_request topic. That’s how the web pipeline sends the direct task requests in. But then you’ll have some latency, especially if it’s jumping through a network.

Posted by @anandharaj-dotworld:

@mxgrey ! When I tried using direct requests, the response time was reduced to only 50 to 100 milliseconds. However, I noticed some delays with continuous direct requests. With periodic requests, each task was queued, and when I only performed a go_to_place, it took about 100 milliseconds to generate waypoints, which I received from the follow_new_path callback. In cases where I used custom tasks, it took between 400 to 700 milliseconds to proceed with each task after it was queued. Is that possible to send the task to direct queue?


Edited by @anandharaj-dotworld at 2024-08-27T11:49:05Z

Posted by @anandharaj-dotworld:

@mxgrey! Thanks for the suggestion. I have achived task preparation time. Now its taskes only 10-30ms

Posted by @anandharaj-dotworld:

If it’s possible, could you provide guidance on where I should write the task planner? Additionally, I’m comfortable with adding a wrapper to an existing task planner, so any tips on how to do that would be appreciated.