Jerking end-effector while scaling velocity

[kamilcetin]

Hey there,

I am using the jog_arm package to run KUKA lbr iiwa 14 model robot arm in the Cartesian velocity control mode. I am able to send the desired Cartesian velocity commands. However, with the default jog_settings.yaml, it is moving very slow. When I increased the scale parameters (linear, rotational and joint) under the command_in_type: "unitless", it is moving faster. But, the end-effector is jerking at the initial and the last of the movements. I also take care of the initial singularity or collision positions. Even I set the collision_check: false.

I also tried the other command_in_type: "speed_units" and changed the publish_period to move the arm faster. But, there is still jerk at the initial movement while sending velocity commands.

Do you know how I can solve the sending large-scaled velocity commands without jerking problems?

Thanks,
Kamil

[AndyZe]

Did you try making the low_pass_filter_coeff parameter larger? I have not seen that specific issue before.

Can you run rqt_plot and attach a screenshot that shows the jerky command? Possibly it's a filtering bug, but unlikely. This code has been used quite a bit.

[kamilcetin]

Yes, I have already tried to increase low_pass_filter_coeff to more than 2 up to 200 before, but it never decreases the the oscillations at the beginning of the movement.
Nevertheless, I cannot see any movement on the rqt_plot, all topics are straight line on zero. Even I cannot monitor any topics when I run /jog_arm_server.
This is the image of rqt_graph shows the nodes in ROS.

[kamilcetin]

In the definitions of the parameters, it says that "publish_period: define the rate of outgoing joint commands. Typically in the 60-125 Hz range."
On the other hand, I am trying to run the KUKA in Fast research Interface mode which means 1kHz. Do you think that make problem on jerk movement at the initial and final time of the velocity commands?

[AndyZe]

To achieve 1kHz, it will probably have to re-publish an identical command several times. If the jogCalcs thread can't keep up with the requested rate, it just republishes the previous command.

Can you try switching from velocity control to position control or vice versa?

[kamilcetin]

Do you mean jog_arm_server/joint_delta_jog_cmds ?

[AndyZe]

I mean the outgoing commands are likely to be duplicated when you're running at 1kHz

[AndyZe]

^That would not be a problem if you're sending velocity commands. It likely wouldn't be a problem for position commands either

[kamilcetin]

When I tried to publish joint_command_in_topic with the messages of jog_msgs::JogJoint through my code and to subscribe it by /jog_arm_server node, there is not any movement because I cannot see any joint commands (jog_arm_server/joint_delta_jog_cmds) publishing/subscribing in rqt_graph. This might be another issue about jog_arm package.

Let's turn back to the jerking problem! When I send Cartesian velocity commands, I don't think it is because of the frequency what I am running at. Because it is still jerking when I run with the same frequency of jog_arm_server.

I may try to implement slow start motion as well, but how? Because the Cartesian velocity commands depend on force measurement and are changing too fast.

[machinekoder]

What is the kuka_ros_bridge doing? Does it have any interpolation feature inside?

We are using jog_arm_server with ros_control and a 1kHz thread. ros_control is, however, interpolating the trajectories and converting them to smooth movements.

Not sure what the kuka_ros_bridge does, but I would start investigating there.

Also, I can recommend plotjuggler over rqt_plot, it has a far better interface.

[machinekoder]

If you are seeing oscillation, that's usually a result of a mismatch in software acceleration settings and hardware acceleration. Do you see the same behavior in simulation?