Where can we change the waiting times for waypoints?

[TheConstructAi]

When launching a fleet adapter, the waypoints tend to have:

• 5-second waiting time between waypoints, where can we change that?
• When no waypoints are assigned, there is a loop of a 30-second wait, where in the code can we change that or the parameter set in the python adapter?

Do they depend on the linear and angular speeds set for the robot in the config file as well?

[mxgrey]

5-second waiting time between waypoints, where can we change that?

I'm not sure what waiting time you're referring to. Can you elaborate on when and where you're seeing a 5-second wait?

When no waypoints are assigned, there is a loop of a 30-second wait

I think this is referring to the ResponsiveWait behavior which to be honest is a bit of a hack that wasn't meant to exist for as long as it has. Because it was meant to be a temporary hack there isn't an API for it, except to toggle it off entirely. If there's a particular reason for modifying the 30 seconds, it would be pretty easy to add an unstable API to do so, but I'm not sure what the value would be. I don't think you'll see qualitatively better traffic behavior outcomes by using a value that's more or less than 30s.

Do they depend on the linear and angular speeds set for the robot in the config file as well?

The linear and angular speeds only impact the trajectory predictions that the planner generates. They won't have any effect on any waiting behavior that might exist.

[TheConstructAi]

I'm not sure what waiting time you're referring to. Can you elaborate on when and where you're seeing a 5-second wait?

It happens between each waypoint sent. So when the robot moves to the waypoint and reaches it its stays there waiting some seconds until the next waypoint is sent. Is this related to the parameters of linear and angular speed and the planner calculating that that's the time it should take to reach there?

think this is referring to the ResponsiveWait

Exactctly. Having issues with it because it sends the robot a goal every 30 seconds an this shouldn't be specially when the robot is docked ( because it gets our of the dock position). We are going around that by trying to ignore these goals when the robot is docked, but isn't there a better way to tell RMF that the robot is docked and that he doensthave to send goals every 30 seconds? Because otherwise we have to deal with it form the robot server side and even in the RobotHandler.

[KKlimowicz-PIMOT]

I’m encountering a similar problem. I’ve adapted rmf_demo RobotCommandHandle and written my own fleet_adapter. I’m currently using ROS2 Humble. The issue I’m facing is that the robot waits at every waypoint. When the distance between waypoints is large, the waiting time can sometimes extend to about 10 minutes. I’ve looked through the documentation but haven’t found any information on how to change this waiting time. I understand that a waiting time is assigned to every waypoint. This part of the code indicates that: waypoint_wait_time = self.target_waypoint.time. However, I couldn’t find where this waiting time is calculated. And I don't want to turning off completely.

[Yadunund]

@KKlimowicz-PIMOT 10min wait between waypoints is very concerning. Is this in simulation or with real robots?

The timepoint in the waypoint is generated by the planner and not something one should edit. But more importantly, we updated our implementation such that fleet_adapters do not need to make the robot wait at a spot until the self.target_waypoint.time has elapsed. Instead, just command your robot along the waypoints received via follow_new_path().

Lastly, are your waypoints along the same straight line? if so you should consider selecting them in rmf_traffic_editor and making them colinear. The planner will skip stopping at intermediate waypoints if they're all colinear and no conflict is detected ahead.

[KKlimowicz-PIMOT]

Thank you for that information. Right now, I am unable to verify the newer version, but I’ll give it a try by the end of the week. Just to make sure, we’re talking about the updated implementation of OpenRMF for ROS2 Humble, right? If you could point me to a commit or a section of the code that I could look up and examine myself, I would really appreciate it.

The problem occurs while using our custom simulation created with Unity. This issue falls outside the RMF simulation concept. We can treat it like real robot but with ideal sensors.

Here is attachment of the screenshot which I took last time: And here is part of road which produce that waiting time: It is aligned and from the start to the end, it measures 410m.

[Yadunund]

Thank you for that information. Right now, I am unable to verify the newer version, but I’ll give it a try by the end of the week. Just to make sure, we’re talking about the updated implementation of OpenRMF for ROS2 Humble, right? If you could point me to a commit or a section of the code that I could look up and examine myself, I would really appreciate it.

Are you using the EasyFullControl API to implement your fleet adapter? If so, the point I mentioned about not making your robot wait should be handled by the underlying implementation of EasyFullControl. If you have your own RobotCommandHandle, make sure you're not explicitly waiting at a waypoint once oyur robot reaches the waypoint. This was done in the past, like in this example but is no longer required.

The problem occurs while using our custom simulation created with Unity. This issue falls outside the RMF simulation concept. We can treat it like real robot but with ideal sensors.

Ah we've never tested with Unity as the simulator. You will need to ensure that the clock behavior with Unity matches that with Gazebo. ROS nodes sync their time with the Gazebo clock by subscribing to the /clock topic that the ros_gz_bridge publishes. Unclear if clock sync is the problem in your case but it's worth ensuring your simulator works similar to Gazebo.

[KKlimowicz-PIMOT]

Okay, I’ve found a solution. Once you mentioned that the timepoint at the waypoint is calculated by the planner, I started wondering about the parameters that influence it. I then realized that my problem came from misunderstanding config file for the fleet adapter. In the config file there are lines telling about limits. At first, I treated it as if there were limits in some area. After investigating, I understood that limits were used to calculate the ‘arrival’ time at the waypoint too. My simulated robot was moving much faster than the limits, so it waited. If the distance between waypoints became longer, it waited longer.

Nonetheless, I will answer your question, so maybe it will help someone.

Are you using the EasyFullControl API to implement your fleet adapter?

I was using that template and modified only sections where it was mentioned by comments. And as you said I no longer require it. I am going to make adjustments to that particular section to ensure the entire loop functions properly.

You will need to ensure that the clock behavior with Unity matches that with Gazebo.

In Unity I am publishing my own clock which is properly scaled so that nodes can work properly.

Thank you for your help.

[Yadunund]

Glad you found a solution!