Open gavanderhoorn opened 7 years ago
@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 joint_states
and they are swiftly ignored when sending trajectories.
(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:
@gavanderhoorn is there any reason why the external axes support hasn't been added to the driver (besides lack of time, of course 😉)?
No, it's just time + someone who need(s)(ed) it.
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
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.
are swiftly ignored when sending trajectories.
you mean ignored by the IRC5?
So, back to my original question, if the reason was lack of time, I can wrap up this impl and send a PR.
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.
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
Agreed. I'll check it out, I guess it should be possible.
you mean ignored by the IRC5?
Yes, I'll test a bit more to be sure.
Yes, it's just time, and a PR adding support would be very much appreciated
Great, I'll try to wrap it up and send the PR this week if possible.
@gonzalocasas wrote:
you mean ignored by the IRC5?
Yes, I'll test a bit more to be sure.
in any case the ROS->IRC5 side of things would be a ROS configuration issue (ie: xacro/urdf and controller_joint_names
).
@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 abb_driver
now has support for external linear axes. Thanks @gonzalocasas for contributing that.
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.