Closed mhubii closed 1 month ago
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
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 (jointposition{t+delta_t} - jointposition{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?
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 (jointposition{t+delta_t} - jointposition{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
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:
this leaves me with 2 questions:
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.hppwould 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.
Refers to #167
Cartesian pose / velocity demo
.pdf
by.rst
fileAdmittance RCM demo
Add TF for initial RCM(this would require modifications to the launch, as modifiable robot description is needed)