ImpedanceMotion Segfault and other issues on system version 4 and libfranka 0.8.0

[jmkl009]

I observed the following errors on a clean Ubuntu 21.04 install with linux kernel version 5.10 patched with rt support. Frankx is compiled against libfranka 0.8.0. The franka panda arm firmware version is shown as 1.3.4-F-AX and 1.3.4-F-A7, system version 4.1.1

• Running ImpedanceMotion as the example shows gives segfault. Upon closer inspection, the line "*model = robot->loadModel()" in include/frankx/motion_impedance_generator.hpp is the source of the error. This line should be "model = new franka::Model(robot->loadModel())" or something like that, as no memory was allocated for *model.
• Impedance control also does not work the intended way, as changing motion.target after async_move in the example code has no effect at all. I believe this is because the constructor of motion_impedance_generator makes a copy of the ImpedanceMotion object, instead of making a reference to the original object.
• The robot will refuse any cartesian motion target after the setEE() function in the set_default_behavior() is run. After a closer inspection, the F_T_EE matrix is set differently from the default one in the desk settings:
  0.7071, 0.7071, 0, 0
  -0.7071, 0.7071, 0, 0
  0, 0, 1, 0.1034,
  0, 0, 0, 1
  This seems to be a libfranka 0.8.0 issue where we have to set F_T_EE matrix in desk from now on.
• Without setting F_T_EE matrix in desk results in LinearMotion/WaypointMotion/PathMotion twists the robot around its axis of "roll" until it stops due to self-collision most of the time. Setting the F_T_EE matrix in desk manually to the value specified in setDefaultBehavior solves the issue. However, the robot runs into cartesian_motion_generator_joint_acceleration_discontinuity very often despite command success rate close to 100% and dynamic rel set to 0.2, so moving the robot through these motion types are not practical.
• After setting the desired F_T_EE matrix in desk, the example force_control breaks even with set_default_behavior now commented out.

[pantor]

Hi @jmkl009, thanks for your feedback! I'll have a look at your issues soon, however please keep in mind that frankx only supports system version 3 and libfranka 0.7. This is because my robot is not (yet) supported by Franka for system version 4, or at least that was the state a few weeks ago.

[lukashermann]

@jmkl009 Did you manage to resolve these issues in the meantime?

[Fang-Haoshu]

@jmkl009 Hi, did you manage to resolve these issues in the meantime?

[jmkl009]

@lukashermann @Fang-Haoshu @BlGene I managed to resolve all but one issues above with custom patches plus many convenience functions. However, that one issue plagued our application the most and eventually led me to drop frankx. Namely, the low success rate in finishing execute a cartesian path with elbow control (no matter how small I set the velocity and acceleration to be). @pantor if LinearMotion/WaypointMotion/PathMotion works much better in 0.7.1 and system version 3, I am curious about what was changed from 0.7.1 to 0.8.0 and system version 4 that causes this.

[pantor]

@jmkl009 I think there is no information about internal changes between system version 2/3 and 4, so I really don't have an idea neither. What do you use now (instead of frankx) to mitigate the issues of cartesian control?

[jmkl009]

My solution is not perfect, I currently use franka_ros_interface which in turn uses moveit and a joint trajectory controller ROS package that interpolates between the points of a motion plan generated from moveit. Although it controls panda through joint positions, each joint position is calculated from a cartesian pose along a cartesian path, so as to eventually achieve cartesian motion. The reason why this solution is not perfect is because I do not have control over the elbows so I always have to do a cartesian motion followed by a joint motion to achieve my desired end pose.

[BlGene]

@jmkl009 we have a similar workaround as well.

Can you please be a bit more specific, were you getting the following error: command aborted: motion aborted by reflex! ?
If you have a small debugging script that generates your error that would be helpful too.

[jmkl009]

@BlGene I always get one of two errors, one the same as yours, the other command aborted: cartesian_motion_generator_joint_acceleration_discontinuity

[dkuss-tudresden]

Any update about ImpedanceMotion's "Segmentation fault (core dumped)" using libfranka 0.7.1 and system 3?