-
Notifications
You must be signed in to change notification settings - Fork 219
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
rsi_hw_interface: Control external axes #100
Comments
Apologies for my late reply. I believe controlling external axes is definitely interesting. Here at TUD we have an KR 210 on a 4m rail with 3 additional external axes. Me and @rtonnaer have done some work exploring how those could be incorporated / properly supported by the hw interface, but we've not arrived at something shareable yet. re: quirk: that is a rather strange thing. Afaik, we've not seen that on the KR C4 here. As to how we best integrate this: at the moment the hw interface only supports a joint space interface. That will have to be extended with some form of a Cartesian input/output. Afaik there is no standard way to do this in |
The way you added external axes in https://github.com/ivareri/kuka_experimental/tree/external_axes is pretty similar to what we have tried at TUD. However so far I have only added external axes to rsi_state.h, not to rsi_command. Next week I planned on doing some updates to my ROS configuration for the KR210. I will check how KRC4 controllers report the positions of linear axes (mm and deg). Based on this info the driver should be able to be configured. Based on the configuration of the workcell each user will have a different ordering of the external axes. I will also try your version of the driver with our KR C4 and let you know how and if it works. |
I'm either missing something, or my first post might have been a bit unclear w.r.t. TCP offset. Both branches I mentioned work in joint space. What the Cartesian input/output in ros_control be used for? It has been some time since I looked at this last, but some of the things that would need to be configurable is:
|
@ivareri: re: cartesian: my apologies, somehow I interpreted your OP as implying that the external axes would be controlled using a Cartesian interface. |
I'm a bit unsure if this should be an issue or a PR (or even on the mailinglist), apologies if it ended up in the wrong place.
I have two branches for controlling (linear) external axes on a KRC 2 via RSI.
https://github.com/ivareri/kuka_experimental/tree/external_axes simply sets axis position using the
AXISCORR
object.https://github.com/ivareri/kuka_experimental/tree/external_axes_tcp_offset is intended to be used with mathematically coupled axes, in addition to the
AXISCORR
object, it uses thePATHCORR
object to displace the TCP position. This requires the external axes to line up with KUKAWORLD
frame. Axes direction and relation to X,Y,Z is currently hardcoded.Both branches have been tested and is working on a KRC 2. There is one quirk that I'm unsure if is specific to our setup or not. RSI output from a linear axis is in [mm * 180/PI]. I asked KUKA support about it, but the guy I talked to didn't know too much about KRC 2 with ext. axes and RSI, and recommended me to live with it if I could.
I could put in some effort to clean up and make the code more configurable if wanted. If so, I would like some input on what should be configurable, and the best way to do it.
The text was updated successfully, but these errors were encountered: