Roadmap for support for partial goals/asynchronous motion

[marip8]

Per the documentation, MotoROS2 supports multiple motion groups, but it does not currently allow them to be moved independently (i.e., partial goal) or asynchronously from one another. These features, particularly the partial goals, would be very handy for robot + external axis systems, and it seems like it could be straightforward to implement the proposed workaround (i.e., setting un-specified joints to their current value for the duration of the trajectory) under the hood in the driver itself (at least for partial goals). I believe the ROS1 driver also had the capability of partial goals via the topic_list parameter

What is the roadmap for adding these features?

[ted-miller]

The next 'major' planned update is to add compatibility for Iron. Beyond that, we're open to requests.

There's been some activity regarding a streaming interface. But if there is a use-case for partial goals, I'm open to looking at that first.

How would this type of functionality work in your case? You just want to omit an entire control-group when sending a trajectory? Or are you looking to omit individual axes within a group? Are there any safety concerns since the motion planner isn't controlling everything in the system?

[marip8]

You just want to omit an entire control-group when sending a trajectory? Or are you looking to omit individual axes within a group?

For my use case (robot + 2-axis positioner), I would like to just omit entire groups to be able to control:

• The robot only
• The positioner only
• The robot and positioner together, synchronously

[gavanderhoorn]

After writing those FAQs and the roadmap items, I've started to dislike the idea of supporting at least partial goals in MotoROS2.

Main reason is I feel it can lead to unsafe situations 'too easily'.

We have a GP25 on a rail here and in motoman_driver it is possible to submit partial goals (well, on our system it is anyway). 'Forgetting' to include the rail is scary at best, catastrophic at worst. As you write, the driver basically just copies the 'last known joint state' for the non-included joints.

Asynchronous control of groups could perhaps be a compromise, but would probably require either supporting multiple concurrent Action requests -- targetting different groups -- or multiple action servers.

The former is non-trivial, the latter is likely difficult due to resource constraints.

[ted-miller]

I can send you a download link for the latest M+SDK installer. You will need a windows computer.

[gavanderhoorn]

Friendly ping @marip8?

[marip8]

I haven't been able to look into this much yet, but I did get the download from @ted-miller, but I found out that our M+SDK was purchased/acquired on a client project and I don't have access to it now. I'll follow up offline about getting access to a seat of M+SDK

[gavanderhoorn]

Friendly ping again @marip8 :)

[gavanderhoorn]

@marip8 ? :)