Added new kuka_kss_hw_interface and associated kuka_msgs packages.

[patduda]

The goal of this new package was to utilize the latest Kuka technology and system knowledge to provide a driver that is more functional and industry ready.
It has many new features:

1. True server implemented in Ethernet KRL (EKI) that runs in the background. Once installed, the system will listen for a connection from the ROS node. Support for Auto External is built in so the ROS node can start/stop programs and enable/disable drives.
2. Connection startup checks validate robot model, driver versions, axis types, axis velocities.
3. Support for external axes and linear axes.
4. Modular design: Support for different communication methods (EKI, RSI, future EtherCat). Support for different control options (EKI, RSI, other future options like mxAutomation). Control types implemented in different KRL programs.
5. Consolidated control and switching from Kuka motion control with EKI to remote motion control with RSI.
6. New services: start_motion, stop_motion, robot_enable, robot_disable, device_info, robot_status, reset, request_control_type, get_control_type.
7. Built-in support for linux real-time extensions.

[simonschmeisser]

Does that imply that for dense trajectories the maximum achievable speed will be limited by the distance between points? Ie so that a full stop would be possible at any time if no further points where to follow

We use splines here for our internal driver and love this feature of Kuka

[patduda]

Yes. The legacy motion planner will limit velocity if point spacing is very close.
I also found that the EKI update rate of 20Hz is a bit slow for smaller robots. The robot executes the planned moves faster than the update rate and is starved of data so it plans a stop. This results in jerky motion.
For your spline motions, to use the single line SPTP or do you download a trajectory as a spline block? Do you suggest we change the PTP to SPTP in ros_krlptp.src?
I experimented with a spline TIME_BLOCK using the moveTime parameter. I couldn't get this to provide continuous motion.
The architecture of this new driver enables different operating mode programs so we could assign different programs to each use a different motion strategy. This might be helpful if there is not a "best" solution to fit all cases.

[simonschmeisser]

We use several spline_ptp blocks of varying point size/lenghts that we concatenate. Unfortunately we found no way to use them with a variable length of points directly. You can visually tell where two blocks are connected. We try to guess a velocity override based on the ratio of velocity to max velocity, this is not accurate at all but sufficient for bin picking.

I don't know if switching this line to SPTP is advisable or not, you got the @ kuka.com address 😉

[patduda]

OK. Thanks for your insights.
One of the challenges with the SPLINE block is that it cannot support a variable length or loop inside. It sounds like you used the common strategy of a fixed size block. Did you also use the C_SPL blending after the end of the block? That can help to smooth the path.
Is your driver also using ROS Control, or is it downloading a whole trajectory for execution?
I appreciate your suggestion and I will test the single SPTP to see if it improves performance.