-
Notifications
You must be signed in to change notification settings - Fork 17
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
Execute motions for multiple motion groups #19
Comments
There is currently no support for actually executing multi-group motions with any publicly available version of If you're willing to make setup-specific modifications, then tricks like the one used to report multi-group state (multiplexing it into the first group) could be used for commanding it as well. But that would not be very nice. There is no fundamental limitation that prevents proper support from being added, other than me not having any time to do it, and no user willing to take this on. There are some non-public implementations, but in my opinion they are not very nice and very controller/robot specific. In addition, they require the use of industrial_core_v2. |
If you don't need any synchronised motion, one straightforward (but very ugly) way to implement this is to essentially install everything twice on the controller: two state servers, two trajectory relays, two sets of TP programs and updating all used flags, registers, etc to not conflict. If you then 'assign' one of those instances to the main robot, and the other to the turntable, you should be able to treat the turntable as just-another-robot. From the ROS side, nothing much would change, other than running two instances of the nodes in This is how multi-group motion is currently approached in |
We do need synchronized motion so having two sets of everything likely wouldn't work for us. I'm definitely willing to make setup-specific modifications or do some other development to get this up and running. What's the reasoning that expanding the tricks used to report multi-group state aren't very nice? What would need to be done to get proper support for multi-groups up and running? I'm not sure if this would be something we could do or want to do with our setup but if the positioner was added as a 7th axis into motion group 1 would the current driver support that? |
yes, that would essentially make it a single-group setup again. Which is fully supported. |
I'm going to close this. Not because I feel this was resolved, but because a work-around is know, and because multi-group support is not something that is on the roadmap for Pull Requests adding this and/or discussions about how to add it are very much welcomed though. |
@jlynchpitt: just to give this some closure (and because I'm curious): did you get this to work in the end, or did you choose a different approach? |
I actually haven’t tried it yet since this part of the project was put on hold for now. I’ll give an update once I give it a try though. |
Hello,
I have a similar setup and issue to the person who made the issue #11. I have an m710ic Fanu arm with a 1-axis turntable in group 2. Looking at that issue it seems straightforward to make the changes to support one axis and monitor the joint states for my system.
Am I correct in my assumption that with the changes in the 'positioner_axes_as_78' branch it is still not possible to execute motions for both motion groups? Would that be a feature that is possible?
Thanks for your help.
The text was updated successfully, but these errors were encountered: