Behavior of osc_pose controller with control_delta = False

[rhjiang]

What I thought was that the osc_pose controller, with control_delta set to False, should take you from your current pose to the absolute pose described by the [position, axis_angle] action given, via a trajectory of intermediate feasible poses. However, I am not able to get this behavior. Even when I command the current position and current axis angle orientations, the robot arm jerks around wildly (I would have expected no motion). Could someone please explain how the osc_pose controller should behave?

[roberto-martinmartin]

you are right, it should keep the posture. Could you do some debugging in the controller and print out the error in position and orientation that is computed? sounds like something is off. Thanks

[rhjiang]

Thanks for the response. Do we have access to what the controller computes as the error? If not, the best I think I could print out is (current pose - commanded pose) which would by definition would be 0 because I am commanding the current pose.

[roberto-martinmartin]

You do have access to that, yes. It would be better to print out that because it is directly the value that the controller tries to minimize. Any errors in reference frames or 180-degree-periodicity in the orientation would appear there. It should be this line, if I remember correctly: https://github.com/ARISE-Initiative/robosuite/blob/master/robosuite/controllers/osc.py#L303

On Dec 6, 2020, at 12:20 PM, rhjiang notifications@github.com wrote:

Thanks for the response. Do we have access to what the controller computes as the error? If not, the best I think I could print out is (current pose - commanded pose) which would by definition would be 0 because I am commanding the current pose.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ARISE-Initiative/robosuite/issues/139#issuecomment-739557775, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2YQIOYNGP3OKSIPSO7TMDSTPRRTANCNFSM4UPR6CRQ.

[rhjiang]

Thank you. I am printing out there error, and there is significant position error calculated. Would it be possible to give a sample code for the controller config? We are using this:

options = {}
controller_name = 'OSC_POSE'
options["controller_configs"] = suite.load_controller_config(default_controller=controller_name)
options["controller_configs"]['control_delta'] = False

Our environment is:

suite.make(
            "TwoArmPegInHole",
            robots=["IIWA","IIWA"],
            **options,
            has_renderer=False,
            ignore_done=True,
            use_camera_obs=True,
            use_object_obs=True,
            camera_names=self.cameraName,
            camera_heights=512,
            camera_widths=512,
        )

[roberto-martinmartin]

@cremebrule , could you provide a code snippet? Sounds to me like a problem due to different reference frames for the desired and current values. Where do you get the desired value from, @rhjiang ?

[rhjiang]

I am using observations of position and orientation that are given in the world frame:

return np.hstack((obs["robot0_eef_pos"], T.quat2axisangle(obs["robot0_eef_quat"]), obs["robot1_eef_pos"], T.quat2axisangle(obs["robot1_eef_quat"])))

[cremebrule]

Hi @rhjiang ,

Thank you for bringing this up! Tested locally, and found that our controller is using absolute commands offset by the initial eef pose, which isn't intuitive. For some reason, there was also no docstring for the use_delta argument so there was no description of expected behavior.

This will be fixed in PR #141.

[rhjiang]

Thank you for this. I think something might still be funky about the orientation control. Right now I am trying to test commanding a rotation with no translation, using:

return np.hstack((obs["robot0_eef_pos"], np.array([0,np.pi/2,0]), obs["robot1_eef_pos"], np.array([0,np.pi/2,0])))

There is no motion, with this command.