Limits are too conservative on FCI

[prakharg01]

Hi, while running the franka_ros2 wrapper built on top of libfranka, we notice that the limits set are too conservative for operation. The arms gets into joint velocity violation very often, but the workspace seems to be safe.

• Is there a way to override FCI limits(positions or velocity). Can we modify through watchman to make the arm move faster or close to limits. We are working on realtime teleoperation and the arm keeps getting the same joint velocity violation when we are using external joint impedance controller.

• The Cartesian and joint position controllers written as examples in franka_ros2 don't seem to even start working on h/w, as soon as the controllers are activated the arm gives the violation. We also notice that the ROS2 system plugin uses active_control rather than robot.control. Running the example using libfranka examples works but same one fails or gives violation when using Ros2

• We need to make the safety a little less conservative and don't seem to find a way for that.

[BarisYazici]

Is there a way to override FCI limits(positions or velocity). Can we modify through watchman to make the arm move faster or close to limits. We are working on realtime teleoperation and the arm keeps getting the same joint velocity violation when we are using external joint impedance controller.

There is no way to change the velocity and position discontinuity limits. These limits are enforced to not to damage the robot hardware. If these limits are triggered it means your signal is discontinuous. You wouldn't wanna send the discontinuous signal to the robot. It will make really bad noises and damage the hardware.

You can always enable the rate limiters to make your signal compliant with our discontinuity limits. But there is a caveat as you are doing teleoperation you are probably using cartesian velocity motion generator. If you activate the cartesian velocity rate limiter, you wouldn't receive any cartesian velocity discontinuities but you might still receive joint velocity discontinuities. To solve that, you could always map the cartesian velocities to the joint velocity using the jacobian. And then send joint velocities to the robot with the rate-limiter activated. But keep in mind these rate limiters are modifying your signal to make it compliant for our discontinuity checks. The root cause is signal you are sending, so maybe you can already make it better before you are sending to the robot. Try to plot the velocity signal and acceleration signal you will see there are sudden jumps.

The Cartesian and joint position controllers written as examples in franka_ros2 don't seem to even start working on h/w, as soon as the controllers are activated the arm gives the violation. We also notice that the ROS2 system plugin uses active_control rather than robot.control. Running the example using libfranka examples works but same one fails or gives violation when using Ros2

We did some fixes for the cartesian pose and joint position example controllers. Could you try again? Maybe the issue is already fixes there.

We also notice that the ROS2 system plugin uses active_control rather than robot.control. Running the example using libfranka examples works but same one fails or gives violation when using Ros2

Implementation wise there is no difference between the active control and control callback in libfranka. Only difference is control callback has by default enables low pass filter. In active control rate-limiter and low-pass filter are implemented in the user side and by default inactive. You could also try the libfranka active control examples and control callback examples and compare them directly in the libfranka level without the ROS 2 in between.