-
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
Add support for linear (or non-revolute) axes #6
Comments
@jontje: can you comment on whether linear axes are supported in the new EGM driver? |
The underlying library used in the driver has support for linear axes. But the driver doesn't use that functionality at the moment. |
@gavanderhoorn is there any reason why the external axes support hasn't been added to the driver (besides lack of time, of course 😉)? It is relatively straightforward to add support for it only at driver level, even if the controller does not have any external axes configured, it seems to work just fine. I am testing a quick draft implementation using an arm on a linear axis, the remaining axes not in the controller simply report as some max value on (I added support for the maximum of 4 additional axes that the 10-value message format allows and tested with a simple support package that adds 3 ext_axes even if I have only one physically available). So, back to my original question, if the reason was lack of time, I can wrap up this impl and send a PR. |
@gonzalocasas wrote:
No, it's just time + someone who need(s)(ed) it.
It would be nice if we could only report axis state if they are actually there. Can't check right now, but if there is a way to determine how the controller is configured and use that information to avoid sending out joint states for unconfigured axes that would be preferable.
you mean ignored by the IRC5?
Yes, it's just time, and a PR adding support would be very much appreciated. And not just by me, I believe at least @jonbinney has a use for such support as well. |
Agreed. I'll check it out, I guess it should be possible.
Yes, I'll test a bit more to be sure.
Great, I'll try to wrap it up and send the PR this week if possible. |
@gonzalocasas wrote:
in any case the ROS->IRC5 side of things would be a ROS configuration issue (ie: xacro/urdf and |
@gonzalocasas it seems that there are a couple of ways to integrate an external axis from an IRC5:
Do you have yours configured as option 1? The RAPID code would be different for the two cases, since it sounds like MoveAbsJ can't be used for external axes that have a separate controller. |
@jonbinney yes, I have it as option 1. |
This would not be a problem directly, as long as we document it properly I believe. @jonbinney, @gonzalocasas: is there any way the specific setup could be detected at runtime? |
Not sure about autodetection, but we'll probably end up with option ros-industrial/abb#2, so we can play around with it, and if there is a way to autodetect we can make a PR to add that functionality. For now starting by supporting option ros-industrial/abb#1 will be a good start. |
With the merge of ros-industrial/abb#150 Keeping this issue open however as it would still seem necessary to determine at runtime whether an axis (external or not) is a linear one or a revolute one. |
Tracking this here for
abb_driver
.Connects: ros-industrial/ros_industrial_issues#27.
The text was updated successfully, but these errors were encountered: