# Fleet Adapter for MiR: Accurate task tracking issues (#159)

**URL:** <https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903>\
**Category:** Open-RMF General\
**Tags:** rmf-github-discuss\
**Created:** [May 24, 2022, 8:55am UTC](https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903 "2022-05-24T08:55:45Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [May 24, 2022, 8:55am UTC](https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903/1 "2022-05-24T08:55:45Z")

</div>

Posted by @dennis-thevara:

I have created a MIR Fleet Adapter based on the template [here](https://github.com/open-rmf/fleet_adapter_template) after I realised that the MIR Adapter in the [main repo](https://github.com/osrf/fleet_adapter_mir) as well as [alexchua0108’s pull request](https://github.com/osrf/fleet_adapter_mir/pull/11) 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.

[https://user-images.githubusercontent.com/24698638/169990780-9de8ed6b-4127-4a9a-b6cc-a6d748db8024.mp4](https://user-images.githubusercontent.com/24698638/169990780-9de8ed6b-4127-4a9a-b6cc-a6d748db8024.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!

> **Chosen answer**
>
> Answer chosen by @dennis-thevara at 2022-06-01T09:13:05Z.  
> Answered by @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](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotCommandHandle.py#L199-L205) which calls the `api.navigate()` function should return true only after confirmation that the robot has accepted the request as described [here](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotClientAPI.py#L57-L65).
> 
> Subsequently there is a check [here](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotCommandHandle.py#L233-L236) 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](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotCommandHandle.py#L235-L236) printed as soon as you send the task request, then it confirms the above.

---

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [May 26, 2022, 4:27am UTC](https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903/2 "2022-05-26T04:27:10Z")

</div>

Posted by @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](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotCommandHandle.py#L199-L205) which calls the `api.navigate()` function should return true only after confirmation that the robot has accepted the request as described [here](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotClientAPI.py#L57-L65).

Subsequently there is a check [here](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotCommandHandle.py#L233-L236) 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](https://github.com/open-rmf/fleet_adapter_template/blob/9efc0d4d0f178840c096c736aa611b9d8a481f2b/fleet_adapter_template/fleet_adapter_template/RobotCommandHandle.py#L235-L236) printed as soon as you send the task request, then it confirms the above.

* * *

**This is the chosen answer.**

---

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [May 26, 2022, 4:29am UTC](https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903/3 "2022-05-26T04:29:23Z")

</div>

Posted by @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.

---

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [June 1, 2022, 9:18am UTC](https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903/4 "2022-06-01T09:18:31Z")

</div>

Posted by @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](https://github.com/open-rmf/fleet_adapter_template) 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.

---

<div class="post-metadata">

**Author:** ![Archive-o-matic](https://sea2.discourse-cdn.com/flex022/user_avatar/discourse.openrobotics.org/archive-o-matic/32/26074_2.png) [@Archive-o-matic](https://discourse.openrobotics.org/u/Archive-o-matic)\
**Post date:** [June 2, 2022, 1:45am UTC](https://discourse.openrobotics.org/t/fleet-adapter-for-mir-accurate-task-tracking-issues-159/44903/5 "2022-06-02T01:45:57Z")

</div>

Posted by @Yadunund:

Glad to hear that! Looking forward to the PR!