Skip to content
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

EEF limtis or Fallen Object + EVAL done triggered every rollout if EEF breaches limit #9

Open
rojas70 opened this issue Dec 14, 2021 · 1 comment
Labels
question Further information is requested

Comments

@rojas70
Copy link

rojas70 commented Dec 14, 2021

Currently, when EEF limtis + EVAL are running, and those limits are violated, every rollout in the EVAL gets terminated early on. This continues until the eval number of steps/rollouts is completed.

The same thing happens if an object falls.

  • Should we accept this behavior? The behavior should be common early on but improve as the robot learns.
  • Should we turn off this limits with a flag (todo)?
  • The code does not crash, but you get a null evaluation result.
@rojas70 rojas70 added the question Further information is requested label Dec 14, 2021
@rojas70 rojas70 added this to the complete_script_no_her milestone Dec 14, 2021
@rojas70 rojas70 changed the title EEF limtis + EVAL done triggered every rollout if EEF breaches limit EEF limtis or Fallen Object + EVAL done triggered every rollout if EEF breaches limit Dec 14, 2021
@rojas70
Copy link
Author

rojas70 commented Jan 12, 2022

After further revision, it seems that EEF workspace works well.

  • commit 2ede60e in picking_env fixed many bugs.
  1. Still, after a fallen_object, if we are using HER, reset_internal() L1306 gets called (self.update_object_goal_her_poses()) but here, new observables have not yet been updated and the setting of an old object triggers an exception.
  • observables are not yet set in base.py:MujocoEnv.reset() (that will be called at the end of reset internal). Would moving to after the setup of observables work?
  1. Checks for fallen objects happens inside picking.py._get_obs(), which gets called in the picking.py.step() method under a control loop (about 30 cycles per policy step).
  • Could add a check for the flag... if true, no more checking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant