Additional demos

[mhubii]

Refers to #167

Cartesian pose / velocity demo

• Replace .pdf by .rst file
• Format code
• Composable node

Admittance RCM demo

• Refer https://github.com/RViMLab/homography_imitation_learning_inference
  • Add TF for initial RCM (this would require modifications to the launch, as modifiable robot description is needed)
  • Revive base implementation

[mhubii]

hi @BoWangFromMars , started reformatting your PR. Would it be okay for this node to accept a twist rather than a pose? Think this should be a little safer for use. Or is it important to you to command absolute poses? Let me know

[BoWangFromMars]

Hello, yes, you are right. Controlling the absolute pose by 'pose' requires users to have basic knowledge of the robot, like path planning, interpolation. For example, the values of consecutive pose commands should not differ too much, and users should plan the path and interpolate the trajectory to make it smoother. In my view, even if we replace 'pose' with 'twist', we need to limit the value of 'twist' within the robot's velocity limits. To send absolute 'pose' in Cartesian space, we can calculate the corresponding joint positions based on KDL, and we can estimate the velocity of each joint motor based on (joint_position_{t+delta_t} - joint_position_{t}) / delta_t and further ensure every joint motor does not exceed its velocity limit. However, in terms of 'twist', we users can determine the velocity of robots in Cartesian space directly, we still need to transfer it to joint velocity to judge it exceed the joint motor velocity limit or not. Thus, users should always assume the responsibility of ensuring the robot work safely(within velocity limit of each joint motor) no matter which command types we use. What do you think?

[mhubii]

Hello, yes, you are right. Controlling the absolute pose by 'pose' requires users to have basic knowledge of the robot, like path planning, interpolation. For example, the values of consecutive pose commands should not differ too much, and users should plan the path and interpolate the trajectory to make it smoother. In my view, even if we replace 'pose' with 'twist', we need to limit the value of 'twist' within the robot's velocity limits. To send absolute 'pose' in Cartesian space, we can calculate the corresponding joint positions based on KDL, and we can estimate the velocity of each joint motor based on (joint_position_{t+delta_t} - joint_position_{t}) / delta_t and further ensure every joint motor does not exceed its velocity limit. However, in terms of 'twist', we users can determine the velocity of robots in Cartesian space directly, we still need to transfer it to joint velocity to judge it exceed the joint motor velocity limit or not. Thus, users should always assume the responsibility of ensuring the robot work safely(within velocity limit of each joint motor) no matter which command types we use. What do you think?

All valid points! Hadn't thought about twists require limits, too. Will think through

[mhubii]

okay @BoWangFromMars , formatting mostly finished. Unfortunately the intended use of this repository is less documented atm, but you can find an explanation for your demo here:

https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/dev-humble-cart-vel-demo/lbr_demos/lbr_demos_fri_ros2_advanced_cpp/doc/lbr_demos_fri_ros2_advanced_cpp.rst#pose-controller

this leaves me with 2 questions:

• Check pose limits?
• The pose_control should ideally be a ros2_controller a la https://github.com/lbr-stack/lbr_fri_ros2_stack/blob/dev-humble-cart-vel-demo/lbr_ros2_control/include/lbr_ros2_control/forward_lbr_position_command_controller.hpp

would you be interested in turning the pose_control into a ros2_controller? I could assist you, otherwise I could do that myself. Let me know. We should open a new PR for that though.