You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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_frame
s.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.The text was updated successfully, but these errors were encountered: