Pick the cube and place it in the bin, on an Elephant Robotics myCobot 280 M5 with the Adaptive Gripper. A LeRobot EnvHub environment.

Pin a commit. @main works but tells you nothing about which scene produced a result.

EnvHub does not install a repository's requirements.txt. Before loading:

Observations follow LeRobot's gym convention, so preprocess_observation maps them onto observation.images.front / observation.state with no remap layer. Joint units are radians, because the myCobot driver is radians-native on /joint_states and /arm_command and so are the recordings below. This is not the SO-101 convention — do not add a degree conversion.

Joint order is the URDF chain, base to wrist: joint2_to_joint1, joint3_to_joint2, joint4_to_joint3, joint5_to_joint4, joint6_to_joint5, joint6output_to_joint6, then gripper_controller. The gripper's open and closed targets are 0.15 and -0.5 rad, which are the two values the real driver commands.

Two honest differences from the real capture, neither of which a feature remap fixes. It was logged at 6 fps (its ROS image rate) while this env runs at 20 Hz, so a chunked policy trained on it executes about three times fast here. And front names a fixed third-person camera in this scene, not a reproduction of the real webcam pose — the observation key matches, the viewpoint does not.

The sim dataset was recorded before two fixes described below (a tracking camera, and a bin that was not in the scene at all), so it is not frame-compatible with this build either.

The Adaptive Gripper cannot close around the 48 mm cube from above under contact physics: at the grasp pose the finger geometry physically overlaps the cube volume. When the gripper is commanded closed within 5 cm of the cube, the cube is kinematically attached to the flange until the gripper opens. Scripted experts and learned policies get the same rule, so train and eval stay consistent — but a success rate here is not a claim about contact-rich grasping. The bin follows from that: it is visual-only, since an attached cube would be dragged straight through solid walls, and place-success is a geometric predicate rather than a containment contact.

No baseline numbers are published with this environment. Nothing has been measured on it under a protocol worth citing yet. The bundled scripted expert completes the task from 6 of 6 randomised cube spawns, which is a statement about the scene being solvable, not about any policy.

Both are the kind of bug that produces a working-looking env and a policy that cannot learn.

A URDF-derived MuJoCo spec compiles with discardvisual on, which deletes every geom that collides with nothing. The bin was built non-collidable at spec level and so was silently removed — the task had no visible target. It is now built collidable and switched off after the compile, by geom name, because fusestatic has already merged its joint-less body into the world body.

The front camera was a targetbody camera aimed at the cube. That keeps the manipuland at image centre in every single frame, which erases exactly the signal a visuomotor policy has to read. It is now bolted to the world and aimed at a fixed point between the spawn box and the bin.

EnvHub fetches only the file named in the ref. The bundled mycobot280_envs package and ~9 MB of robot meshes are not fetched with it, and their directory is never put on sys.path — so env.py calls snapshot_download for its own repo on first load, recovering the repo id and commit from the cache path. A cloned checkout skips that entirely.

One trap if you copy the pattern: locate yourself with Path(__file__).absolute(), never .resolve(). The cache exposes snapshots/<commit>/ as symlinks into a flat blobs/ store, and resolving them discards both the repo name and the commit.

Worth knowing if you publish your own: an environment spanning more than one file does not work through make_env unless it bootstraps this way.

The robot description — assets/mycobot_280/mycobot_280_m5_gripper.urdf and 15 STL meshes — is derived from elephantrobotics/mycobot_ros2 (branch humble), whose mycobot_description/package.xml declares <license>BSD</license>. That repository ships no top-level LICENSE file. The meshes are re-converted from the upstream Collada with <up_axis> honoured; link and joint transforms are untouched. See NOTICE and assets/mycobot_280/UPSTREAM_NOTICE.

The MuJoCo scene construction, the gym environment, the scripted expert, and this entry point are original, Apache-2.0. The scene geometry is authored, not measured against the physical cell.