Skip to content
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

Does the rsi_hw_interface driver modify the target joint positions? #151

Closed
tllatzal opened this issue Mar 22, 2019 · 5 comments
Closed

Comments

@tllatzal
Copy link

Hello everyone,

we want to use the kuka_experimental package to control a KR16 R1610 using ROS. I have a question regarding the functionality of the rsi_hw_interface.
Please correct me if I am wrong: The RSI interface is quite a low level interface to the robot so the Kuka controller does not do any trajectroy planning while RSI is active and simply moves the joints to the target joint positions received every 4 ms. So the trajactory (and velocity and acceleration) planning has to be done on the ROS side. Are the trajectories planned by ROS (e.g. Moveit) parsed and streamed directly via the RSI interface to the robot or are they modified by the rsi_hw_interface driver to account for joint movements too big for the 4 ms timeframe?

Thanks a lot

@gavanderhoorn
Copy link
Member

Are the trajectories planned by ROS (e.g. Moveit) parsed and streamed directly via the RSI interface to the robot

No.

or are they modified by the rsi_hw_interface driver to account for joint movements too big for the 4 ms timeframe?

Neither.

This may sound pedantic, but it's important to be as precise as possible when talking about this.

The hardware_interface (ie: KukaHardwareInterface) does nothing more than periodically forward to the controller (over RSI) whatever gets written into joint_position_command_ (here). It doesn't do any interpolation, checking or parsing.

Which "entity" writes into joint_position_command_ would depend on how the ros_control stack is configured. Typically, one of the ros_control controllers is used.

Which controller that would be is up to you.

If you configure it to be a joint_trajectory_controller, that controller will be responsible for making sure that robot joint limits are not violated.

@gavanderhoorn
Copy link
Member

Closing this as it's a question and not an actionable issue or defect.

@gavanderhoorn
Copy link
Member

See #126 and #89 for some related issues.

@gavanderhoorn
Copy link
Member

Note:

received every 4 ms

there is no assumption about the period in the hardware_interface. As RSI supports multiple, this would not work.

@tllatzal
Copy link
Author

Thanks a lot for the extremely fast and helpful answers. That helps me a lot understanding how it all works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants