Fleet Adapter for MiR: Accurate task tracking issues

[dennis-thevara]

I have created a MIR Fleet Adapter based on the template here after I realised that the MIR Adapter in the main repo as well as alexchua0108's pull request are based on the older implementation of the full_control adapter. The only changes I've made to the fleet_adapter.py and RobotCommandHandle.py scripts are modifications to the parameters of the calls to the API client methods.

Within RobotClientAPI.py I've implemented the following methods for RobotAPI with some changes to their signatures:

• check_connection(self) -> Bool
• position(self) -> Union[list[float],None]
• navigate(self, goal: list[float]) -> Bool
• stop(self) -> Bool
• navigation_remaining_duration(self) -> int
• navigation_completed(self) -> Bool
• battery_soc(self) -> Union[float,None]

start_process and process_completed are as yet unimplemented.

Functionally it works fine so far, and I am able to send goal positions to our MIR 500 via the terminal using the dispatch_multi_stop node from rmf_demos_tasks. That said, we've been seeing some strange behavior of the markers in the RViz panel during tracking. I have attached a recording of this below as it's easier to show than describe.

EnchantedDiligentAtlanticbluetang.mp4

At this point, I have the following questions:

1. I understand that the velocity of the green marker in the tracking panel is dictated by the linear and angular params of the limits trait in the config file used by the adapter code. Is there a way to make this match the actual execution of the path by the robot more precisely instead of trial and error modifications to the velocity params?

2. In addition, the execution marker begins moving instantly, instead of when the robot actually begins moving. Is this governed by a setting or param I can tweak to closely match the actual robot?

3. The pink marker that tracks the robot's actual position frequently teleports to waypoints along its path even before the actual robot has begun moving. Is this possibly an issue with the REST API client or do I need to make any changes to the adapter code to improve the synchronization? For what it's worth, during testing of the API client separately, I'm able to continuously poll the robot's status API in a loop with next to no packet drops.

Thanks for your time!

[Yadunund]

Hello,

This is likely happening due to your fleet adapter reporting that the navigation has completed before the actual robot begins moving and has to do with how you may have implemented RobotClientAPI.py and RobotCommandHandle.py.

Specifically this block which calls the api.navigate() function should return true only after confirmation that the robot has accepted the request as described here.

Subsequently there is a check here to determine whether the robot has completed navigating to the requested destination.

I can't say for certain what's happening with your adapter as I don't have access to your code but my hunch would be that your implementation of navigation_completed() is checking whether the task queue in the MiR is empty and if so returning true. But the adapter's state machine changes to Moving so fast that the task queue in the MiR fleet manager has not yet been populated with the navigation request you submitted when Idle. This should be easy to confirm by looking at the printouts in the terminal that is running your adapter. If you see this line printed as soon as you send the task request, then it confirms the above.

[Yadunund]

I believe Alex's PR linked above overcomes this problem. If your're keen on contributing, it would be great if you could target your improvements to alex's branch. We can merge everything into main after.

[dennis-thevara]

Thanks a lot for the insight! It took a few days before I was able to test my changes to the robot, but I believe the issue was as you had described. I've made a few changes to api.navigate() to return True only after the robot accepts the mission, and modified my previous navigation_completed() method as well. For now it seems to work as expected. I'll spend some more time polishing this API client and catching any other issues that may pop up before opening a PR.

On that note, I just wanted to point out that the structure of my Adapter implementation more closely matches the Python template here and also your Ecobot adapter, and is quite different from Alex's. Also I've wrapped the whole thing into a standalone ROS2 Python package.

[Yadunund]

Glad to hear that! Looking forward to the PR!