Starting missions from ROS bridge

[BenziF]

Hi everyone,

I recently opened a similar issue, but i thought this can also be of interest independently from the other one. Feel free to delete it if you see fit.

I was wondering if there was a way to modify the mission queue of the MiR via ROS, selecting which missions to add/remove from the queue and then signaling the robot to start its mission (equivalent to pushing the "Play" button via the web API).

Right now, we can only move the robot using /cmd_vel or /move_base/goal, which is fine for research purpose. Since from REST API one can easily start the mission and model the mission queue, I was wondering if that would also be possible via ROS, or else if it's easy to implement.

[mintar]

This is not implemented yet, but it would be a very welcome addition! I believe this is the best way to implement the "docking" action (see #69, #72) as well as others.

I don't think it would be very hard to implement. The REST API is stable and well-documented by the MiR people. If you'd like to do this, I'd be more than happy to review and merge PRs! If you have any specific questions during this process, feel free to open issues to discuss it.

[moooeeeep]

I need to handle cart missions soon'ish. I've found this library that might help with the REST API interaction:

• https://github.com/osrf/mir100-client

Currently I'm thinking about whether and how this should be integrated into the driver. Maybe one could expose the most relevant endpoints of this API via ROS services. Not sure if it's worth to generate all of them automatically and advertise them all the time. Perhaps a library would be useful that defines and builds auto-generated srv files and provides some kind of factory that can advertise any combination of method+endpoints as a ROS service. Then we could implement the required client code to create and enqueue missions via those services.

Any non-trivial task will probably involve running a sequence of several calls to the REST API. Maybe a custom higher-level API based on specific use cases would be more useful, that would then be exposed via ROS services instead of or in addition to the above described low-level API.

Not sure if this is still within the scope of what this repo is intended to deliver.

I'm open for any input or suggestions!

[mintar]

That library looks very useful. I agree that we shouldn't replicate all of the REST API over ROS services - at that point you could just use the REST API directly. So perhaps start with your use case in mind.

[Guillaume-Syc]

Hello !

In the file MirMoveBase.action, there is an argument,: move_task.
For this argument there is many possibility including :
int16 DOCKING_MOVE = 4
int16 DOCKING_GLOBAL_MOVE = 5

I've read the topics #74 and #72 but I don't understand what is the purpose of those params ?
Can we use them to send the robot to the dock or is it just for futures implementations ?

Thank for your time