Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use with multi-robot systems (ie: multiple active controlled_frames)? #3

Open
gavanderhoorn opened this issue Mar 11, 2022 · 1 comment

Comments

@gavanderhoorn
Copy link
Contributor

IIRC, this was not a use-case considered during the initial design of these messages / actions, but it's something which seems like a natural extension of the use-cases which were considered.

Are there any thoughts on how to use the message(s)/action in this repository with systems composed out of multiple robots?

Such systems could support both synchronous (ie: everything moves at the same time, coordinated) and asynchronous motion (ie: parts of the composite are allowed to move independently from each other), where there would be multiple controlled_frames.

The current iteration of trajectory_msgs/MultiDOFJointTrajectory (with trajectory_msgs/MultiDOFJointTrajectoryPoint) seems to support this by making all fields (unbounded) lists. Each index in those lists corresponds to a 'tip' / eef-link of the robot-composite, and those are driven towards the corresponding geometry_msgs/Transform (with a certain velocity and acceleration).

With cartesian_control_msgs, it would be possible to support the asynchronous motion variant by using multiple action servers. But the synchronous one seems difficult to achieve.

@stefanscherzinger
Copy link
Contributor

stefanscherzinger commented Mar 21, 2022

@gavanderhoorn

Interesting use case.

Are there any thoughts on how to use the message(s)/action in this repository with systems composed out of multiple robots?

I was thinking similar to what you mentioned with asynchronous, where every robot gets its own action server (within a suitable controller).
The approach with trajectory_msgs/MultiDOFJointTrajectory seems very generic. Looking at it briefly, however, it reminds me more on controlling a swarm of UAVs than a fleet of manipulators.

Speaking of fleets, would it be sufficient to synchronize these asynchronous robots with conventional ROS communication tools? I.e. sending (publishing) each robot's trajectory goal at the same time from some high-level program logic. It might be necessary to investigate the upper boundaries of at the same time in ROS1, though.

If there was a message format for commanding synchronized trajectory goals, how would an implementation of the corresponding action server look like for a fleet of robot manipulators?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants