Closed acf986 closed 5 months ago
@acf986 This is an expected behavior. According to the warning note of setNullSpacePosture()
, the preferred joint position will be reset to nominal values when RT/NRT_CARTESIAN_MOTION_FORCE mode is re-entered.
@pzhu-flexiv Thanks for your answer. However, after calling setNullSpacePosture(), we never leave the NRT_CARTESIAN_MOTION_FORCE mode, so there should be no reset?
More specifically, we call setNullSpacePosture() after the robot entered the NRT_CARTESIAN_MOTION_FORCE mode, and before the first call to sendCartesianMotionForce().
@acf986 The reset happens when you enter NRT_CARTESIAN_MOTION_FORCE from other modes.
@pzhu-flexiv Thanks for your response! But after entered NRT_CARTESIAN_MOTION_FORCE mode, we immediately called setNullSpacePosture() before sending out any motion/force command. Won't this set the null space posture to the desired value instead of the default one?
@acf986 Currently no, the reset will force to the default value before taking the newly set value. However, after a second thought, we think it's better to not force the reset given use cases like yours. The change will be implemented in v0.9.2, please wait for the update.
@pzhu-flexiv Thanks very much! In that case, let me just give more details. What we hope the robot will do:
Currently, for step 2 and 3, if we use the built in primitive (like compliance move), it works without any issue. The robot will successfully update its null space posture before executing the primitive's motion. We just hope the NRT_CARTESIAN_MOTION_FORCE controller could achieve the same.
Version information
Describe the bug What I am trying to do:
What is the issue:
The possible reason:
Steps to reproduce
Expected behavior The robot arm should move smoothly without twitch, and also with the updated null space posture.
Screenshots
Additional context