-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Controller difference for different envs #11
Comments
Hi, Octo models do not fail on the widowx tasks. The controller we use are here: https://github.com/simpler-env/SimplerEnv/blob/main/simpler_env/utils/env/env_builder.py . Note that "delta_pose_align" is different from "delta_pose". You can see https://github.com/simpler-env/ManiSkill2_real2sim/blob/cd45dd27dc6bb26d048cb6570cdab4e3f935cc37/mani_skill2_real2sim/agents/controllers/pd_ee_pose.py#L202 for "align" vs "non-align". In simple terms, "delta_pose_align" decouples translation and rotation, instead of directly multiplying 2 SE(3) matrices. |
Thanks, let me look into that! |
Also, why there's no difference in handling the different arm controllers in the model wrappers? Seems like only the gripper actions are handled differently. In terms of gripper actions, can you explain why you set |
The OpenVLA likely uses a different setup from RT-* and Octo for real eval, so need to connect to the authors to verify if (and how) they implement the sticky actions in real eval. There are other things like action ensembling and obs len / action len that need to be verified too. Could you share some videos of OpenVLA failing on Bridge? Is the arm reaching the object? If it's not reaching, most likely there are implementation issues. |
One failure case of OpenVLA: Here are some explanations from the OpenVLA authors, but I don't think they are clear enough. Can you share where you found the |
This is almost surely an implementation issue. Looks like the rotation orderings might be wrong for Bridge envs for OpenVLA. OpenVLA might output ypr instead of rpy for Bridge. That is, on Bridge evaluations, while for Octo,
|
I tried all arrangements and neither worked. The task is to pick up the spoon, and the gripper should move forward in order to do that. However, every time it always goes straight down without moving forward, which is very weird. |
Have you tested with other tasks? Spoon.mp4karotte.mp4 |
Hi, thanks for the great work! I'm playing around with your environments and found that both RT1 and Octo seems to be capable of only the
google_robot
tasks but not thewidowx
tasks.Further, I noticed that
google_robot
environments use thearm_pd_ee_delta_pose
+gripper_pd_joint_target_delta_pos
controllers whilewidowx
environments use thearm_pd_ee_target_delta_pose
+gripper_pd_joint_pos
controllers. Notice that both the arm and gripper controllers are different. However, in your model wrappers, you seem to be treating theworld_vector
androt_axangle
the same way regardless of the difference in the controller. I wonder if that's causing the models to failwidowx
tasksFYI, I got the controllers using
env.unwrapped.control_mode
. More details on controllers can be found hereThe text was updated successfully, but these errors were encountered: