Repository navigation
Merge/camera ready into main - #8
Merged
Merged
Conversation
The MID360 is mounted inverted. The stock livox_ros_driver2 rotates the points by MID360_config.json's roll-180 extrinsic but publishes the IMU in the raw sensor frame, while mid360.yaml told FAST-LIO the two share a frame. On the real robot FAST-LIO diverged within seconds of walking (recorded bag: 36 km of drift over 146 s; the robot stayed within 2 m). - Add livox_imu_upright (h1_bringup), started only by h1_real_drivers.launch.py: the driver's IMU is remapped to /livox/imu_raw, rotated by the same extrinsic read from MID360_config.json, and republished on /livox/imu. It logs an error at startup if gravity still reads downward. This reproduces the only functional change in the correlllab/fast_lio_nav2_humanoid driver; the livox_ros_driver2 pin stays at 13eb05e. The sims publish an upright IMU directly and do not run it. - mid360.yaml is now the single FAST-LIO config for sim and real: the fast_lio_nav2_humanoid values, except 0.4/0.4 m voxels (0.5 loses registration on the sparse sim lidar; <=0.3 destabilises the real MID360 while walking), scan_line 6 (a line filter only; the real sensor emits lines 0-3, the sims 0-5) and pcd_save_en false. - slam_toolbox_h1.yaml is now the stock mapper_params_online_async values (slam_toolbox 2.6.10) that the reference stack loads. Validated by offline replay: the real bag passed 8/8 runs (0/5 before) including 2 at 1x rate; a RoboCasa walking loop tracks ground truth to 0.22 m RMS. Not yet validated on the robot's own computer or in Isaac. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Reproducible builds: - Pin external base images by digest, git clones to exact commits, the uv installer version, and IsaacLab's rl_games/robomimic VCS extras. - Select dated Ubuntu and ROS snapshot archives (docker/locks/apt-sources.sh) with a vendored ROS snapshot key; disable inherited live CUDA APT lists. - Constrain every pip/uv install with docker/locks/*.txt and verify the full RoboCasa asset tree against a recorded digest. - Correct combinations the old images held inconsistently: ROS uses Pinocchio 2.7 / cmeel-boost 1.83 / OpenCV 4.10 on NumPy 1.26 and removes the base image's NumPy-2 cmeel closure first; Isaac keeps its bundled torch 2.7 / psutil 5.9.8 with stable-baselines3 2.8.0, ipython 9.10.1, opencv-python 4.11 and pandas 2.2.3. - Copy a CA bundle from a pinned Jammy image into the bare arm64 base so the HTTPS snapshots work with TLS verification on. Provenance and remaining gaps are in docker/locks/SOURCES.md. core_ws cache: launch_ros.sh always runs incremental colcon and propagates failures, builds a staged copy of livox_ros_driver2 instead of its build.sh (which deletes caches and masks errors), refuses stale installed packages, and stops back-dating MJPC sources. Tests: run_all.sh, native heartbeat-clock regression, prompt lower-body collapse detection, cameras off by default and image IDs in run.json. Bumps h12_safety_layer (heartbeat on steady time) and CL_isaaclab_sim (physical reset on env reset). All four live stack cases still fail; see the stack results for evidence. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…; update RViz layout and ignores
Simulator speed (RTF 0.2 -> 1.0 headless, 0.16 -> 1.0 windowed): - Run RoboCasa fixture updates and success checks once per control step, as RoboCasa's env.step does, instead of every physics step. - Serialize Livox CustomMsg scans as one packed buffer (byte-identical to rclpy serialization) instead of 20k Python point objects. - Cast lidar scans and render cameras from MjData snapshots on per-sensor worker threads; schedules, stamps and messages are unchanged, no drops. - Always use EGL for offscreen cameras, creating the context before the passive viewer opens, and sync the viewer from its own MjData on a 60 Hz thread; mouse perturbation forces are forwarded to the simulation. Spawn: back the robot off until every collision geom is GOLEM_SPAWN_MARGIN (default 0.20 m, both platforms) from non-floor geoms in the spawn pose and in the pose the unpowered upper body sags into. Distances use mj_geomDistance with the midphase disabled (inflated box-box contacts and multi-geom midphase culling misreport them); the search never passes an obstacle behind the base. Lower body: add lowerbody_auto_switch (default false) so ALMI stands and walks without handing off to the walk policy; the stack test expects ALMI throughout. docker_run.sh/docker_stack.sh inspect containers by type, since the containers share names with their images. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
h12_slam (new in-tree package) owns the shared nav launch
(h1_navigation.launch.py) and the lidar/SLAM/nav configs: MID360_config.json,
mid360.yaml, slam_toolbox_h1.yaml, nav2_config*.yaml.
h1_bringup top-level launches now only include building blocks:
h1_state (jsp + rsp), h1_control ([estop] -> safety -> frame_task, staggered),
h1_lowerbody (RL controller + optional MJPC estimator behind
start_position_verified), h1_models (model servers + skills). Per-robot
lowerbody params move to config/lowerbody_{sim,real}.yaml with identical
values. h1_real_controller.launch.py is replaced by h1_state + h1_control.
New h1_real_slam.launch.py: drivers + state + navigation. Adds rviz/nav.rviz.
Old and new expansions of the sim, real, desktop and safety_grippers
bringups produce the same nodes, args, delays and parameter values.
In sim, lowerbody:=mjpc now starts no RL node. Commented-out MJPC blocks
and the unused use_mjpc_viz arg are removed.
After pulling on a symlink-install host, delete build/ and install/ for
h1_bringup once to drop dangling links to the moved files.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Runs the two-agent policy from Locomanipulation_game (LocoManip-Marl-Flat-IK-Direct-v0) on the H1-2: a legs agent that walks on /cmd_vel and an arms agent that reaches arm targets through IK. Includes the deploy node, controller, kinematics, the marl_ik policy config and controller tests. The exported policy weights are not included; the README describes how to export them. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012uRSUqhg6wqFCekhR7SYsj
…r, safety-layer bounds) and a game commander The controller takes the deploy features of LocoManip-Marl-Flat-Golem2-Direct-v0 from its yaml (policies/marl_golem), each off by default so marl_ik behaves as before: - odometry "legs": the arm command moves by the IMU attitude (taken back to the pelvis through the torso joint) and the planted feet's kinematics; a foot counts as planted within stance_height of the lowest one, since the robot has no foot force sensor; - arms.residual_cutoff_hz: the 3 Hz one-pole low-pass on the residual, which the arms observe; - target_margin -0.001: targets inside h12_safety_layer's clip; - torque_headroom: targets kept where kp (target - q) - kd qd is within 85% of effort_limits. Checked against the training env step by step (Locomanipulation_game scripts/skrl/deploy_parity.py): observations and networks identical, joint targets within 1.3e-4 rad, leg odometry 2.4 mm/s median error. game_commander_node drives marl_deploy_node with training's schedule: walking segments uniform in the training ranges for 4-8 s and arm goals sampled by the training command (arm_goals_<spread>_<drop>.npz), half each. A lidar obstacle guard and a SLAM geofence keep walking off the furniture; events and a 10 Hz status line go to a JSON-lines log. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
…e in sim Starts the state publishers, the split safety layer with the real robot's preset (relax_safety_split, the e-stops the policy trained against), marl_deploy_node with the policies/marl_golem export, the game commander, and SLAM (FAST-LIO, body->pelvis mount, pointcloud_to_laserscan, slam_toolbox; no nav2, so the commander is the only /cmd_vel publisher). frame_task_server and the lower-body RL node stay off: marl_deploy_node owns both safety channels. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
…n RoboCasa run.sh follows tests/stack/run.sh: disposable ROS and sim containers on a test domain (194), the ROS side running locomanipulationgame_bringup.launch.py after the canonical launch_ros.sh build, the sim running the canonical launch_robocasa.sh with record_simulator.py swapped in as its entry point. The recorder (no ROS output) saves the compiled scene and the state at 30 Hz for render_recording.py, which follows the robot with the room's walls hidden, and 50 Hz pelvis and joint telemetry for analyze_run.py, which scores falls, e-stops, walking tracking, arm goals and joint margins against h12_safety_layer's table. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
The robot spawns facing a counter, so walking forward first ends at the obstacle guard within a couple of seconds. The scripted sequence now backs off 3 s and turns 4 s before walking 4 s, then reaches standing and crouching and walks on. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
A goal's completed flag was a numpy bool when the run ended on the telemetry's last sample, which json.dump can't write: metrics.json was cut off mid-file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
A robot that fell without an e-stop kept receiving walking and arm-goal commands until the run's duration. A tilt past 1 rad (training's fall termination) for 0.5 s now ends the run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
… bringup launch Documents the Golem3 policy, the commander, the export and parity commands as they exist, and locomanipulationgame_bringup.launch.py in place of the lowerbody:=marl_ik switch, which no launch file implements. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
When a cabinet or counter blocks the follow camera, it swings to the first clear view (other sides, then steeper) and moves in if none is clear. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
Under timeout in a terminal, docker compose run put in a background process group stops on the terminal and the run never ends. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
…n physics, without ROS sim2sim_walk.py runs locomotion_game_deploy's MarlController on the compiled scene a RoboCasa run recorded (record_simulator.py's model.mjb), with only the robot's and the floor's collisions kept and the floor widened, through the production loop's per-step PD, elastic band release and the safety layer's clip and e-stop checks (relax_safety_split, counted). A fixed schedule (walks, reaches) or a RoboCasa run's replayed events; variants change one physics or timing setting at a time (joint damping, armature, frictionloss, contact softness, friction, cone, timestep, implicit PD, delay). It scores velocity tracking, gait (lift, unloaded share, cadence, stride, slip), reaches and falls, and with --score also scores recordings from other sims written in the same format. sim2sim.sh runs it in a disposable robocasa container through the docker scripts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
…t the feet) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
…oals in Git LFS policies/marl_golem now holds run R of LocoManip-Marl-Direct-v0 (Locomanipulation_game marl-direct, commit 54d935f): legs.pt, arms.pt, estimator.pt, export.yaml and the arm goals for spread:drop 4:10, 7:10 and 10:10, built from run R's target tables. policies/.gitattributes tracks *.pt and *.npz with Git LFS, as model_server/weights does. marl_golem.yaml and the README name run R and the current task and config classes; the export and parity commands use the scripts' default task. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DuoTaYHKcJbW1w79benm8q
The zero-length band pulls the torso toward the anchor from every direction, but it damped only the velocity along the band, so lateral and fore-aft swing went undamped; it also damped the pelvis's velocity while pushing the torso. It now damps the torso's full linear velocity (mj_objectVelocity) at 2e3 N*s/m. After a 0.1 s lateral shove on the limp robot, torso position spread drops from ~6.7 mm to ~0.2 mm; the resting pose is unchanged. ElasticBand.key_callback compares against the GLFW space key code directly: mujoco 3.3.1's viewer doesn't import mujoco.glfw, so the attribute lookup raised and killed the viewer's render thread, hanging launch_passive. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014NMXK58NsKWDSfrR4YkdfW
… optional height_drop policies/marl_ik now holds golemlim120k's export (agent_120000, LocoManip-Marl-Direct-v0, learned odometry), networks in Git LFS. That run clips joint targets into GOLEM's position e-stop range, which export.yaml carries as target_limits; the controller narrows its position bounds to them. It also trained without the height_drop input (legs 95, arms 123 obs), so the input is now behind height_drop_obs (default true, as marl_golem needs). marl_ik has no arm-goal samples: run it with use_commander:=false. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014NMXK58NsKWDSfrR4YkdfW
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014NMXK58NsKWDSfrR4YkdfW
h1_locomanipulationgame.launch.py is the shared block: marl_deploy_node and the game commander (both behind start_position_verified) and SLAM without nav2. locomanipulationgame_sim_bringup.launch.py keeps the sim behavior (commander on, no operator confirm, elastic band released) and refuses to start when ROS_DOMAIN_ID is unset or 0, since it engages and walks without an operator. locomanipulationgame_real_bringup.launch.py runs on the onboard PC instead of h1_real_robot_bringup: drivers, state publishers, estop and safety layer without frame_task_server, plus the game block on wall time with the confirm_engage gate forced on, no elastic band, and the commander off by default. marl_deploy_node zeroes the velocity command when it engages, so a /cmd_vel received while pre-posing or waiting for the confirm no longer walks the robot on the first policy step. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…o lmg_*
- Package h1_bringup -> h12_bringup (module, resource marker, setup files),
and every h1_*.launch.py -> h12_*.launch.py, including
h12_slam/launch/h12_navigation.launch.py. References updated across
launch files, configs, docker scripts, tests and docs.
- locomanipulationgame_{sim,real}_bringup -> lmg_{sim,real}_bringup.
- h12_locomanipulationgame.launch.py no longer starts its own SLAM nodes;
both lmg bringups include h12_slam's h12_navigation.launch.py behind
use_slam instead (this also starts nav2).
- marl_deploy_node's config path is built as a string ParameterValue.
After pulling, remove build/ and install/ for h1_bringup and h12_slam
before rebuilding, or the old package stays installed.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Package, Python module, resource marker and setup files renamed; references updated in h12_bringup (launch file and package.xml), common_cmds.md, CLAUDE.md and the tests/locomanipulation_game scripts. After pulling, remove build/ and install/ for locomotion_game_deploy before rebuilding, or the old package stays installed. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- marl_deploy_node always loads the exported networks; the policy_mode parameter and launch argument are removed. ZeroNetwork remains for the unit tests. - lmg_sim_bringup fixes engage_wait_for_confirm to false (engages once the pre-pose settles) instead of exposing it; lmg_real_bringup keeps it true. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
G1_ASSETS resolves CL_Assets beside golem_robocasa, the way battery_env.py does; the robocasa container mounts it at /home/code/CL_Assets for both robots. The files are byte-identical to leprechaun_g1's. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
g1.yaml's xml_path resolves in the ros container (CL_Assets beside the policy mount at /home/code) and in the repo (homie_policy's fallback to the repo root). HOMIE's files stay in policy/. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
The G1 overlay no longer mounts leprechaun_g1: both services read the G1's model from the base file's CL_Assets mount. prepare_mounts checks the CL_Assets/g1 files each service reads (exist, not LFS pointers, with a `git lfs pull` hint): every ros container, since golem_ros2_models installs both robots' models, and the robocasa service for the G1. The policy check stays G1 and ros only. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…ontainer The read-only rt/lowstate printer the first real session runs in step 6. The G1 overlay mounts tools/ at /home/code/tools in the ros service, the path the Mac compose already uses. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
Every reader now takes the G1's model from CL_Assets/g1, whose files are byte-identical to leprechaun_g1's assets (78 files; the README's link to the unit page is the one difference). Its read_lowstate.py is in tools/; its docs move into docs/g1/ in the docs commit. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
- docs/g1/hardware.md (new, in the nav): our unit, the dev computer's running program, mode_machine, rt/lowstate's layout and slots, and the open hardware questions, from leprechaun_g1's docs/hardware/g1.md, docs/bringup.md and README. - docs/g1/dds.md: the robot's network, its topics, and reading it without the stack (the Python 3.10 environment, cyclonedds ls, read_lowstate.py), from leprechaun_g1's docs/bringup.md. - first-session.md: t_pose and home in place of arms_down, which is inside the hip spheres and stops short; the arms hang clear of the hips before each launch; tools/read_lowstate.py at /home/code/tools. - index.md, packages.md: golem_ros2_models and the G1's self-collision model and planner in place of g1_description and leprechaun_g1. - CLAUDE.md and AGENTS.md (in step), README.md, RUNNING.md: the package tables and count, CL_Assets, the G1 overlay's mounts and checks, the third-party list, the onboard PC's build of golem_ros2_models, and the stale-install cleanup for h12_ros2_model and g1_description. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…ite's file g1_robosuite resolves CL_Assets/g1 directly and no longer has _REPO, which the FAST_LIO extrinsic check used to find core_ws. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
blank_env.py registers Blank: robosuite's EmptyArena without its visual walls (a floor, a light), the robot spawned at the origin facing +x, and the task signals stubbed as Battery's are. h12_mujoco.py and g1_mujoco claim it in any case through resolve_task's robot_task hook, and both refuse --layout and --style for it (sim_common.refuse_kitchen_args). Each runner's spawn and elastic band run unchanged; the kitchen paths and both surface goldens are unchanged. Tests: test_sim_common_tasks.py resolves blank/Blank/BLANK for both robots and keeps Battery H1-2 only; test_blank_env.py builds Blank for each robot, checks the scene holds only the floor and the robot, and steps 500 times with the band holding the pelvis up. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
CL_Assets' G1 torso spheres now stand inside the torso's flanks, so at home the closest sphere pairs (the upper arms against the torso) are 25 mm apart instead of 2.2 mm. The G1 configs' controller.d_min goes back to 0.02, and from home a planned palm move across the body plans and executes. - g1_split.yaml, sim_split.yaml: d_min 0.02. - robots/g1.py, README, g1_real_robot.launch.py, docs/g1: the 20 mm keep-out; arms_down stays in self-collision (the real wrists and hands rest on the hips); the start-up fails from a pose with a sphere pair about 10 mm apart or closer, not only from an overlapping one. - test_config: the G1's d_min matches the old loaders' fixtures again. - test_robot_model: every named configuration but arms_down keeps 0.02. - CL_Assets: pin to 1a26fb7 (g1_assets, not yet pushed). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
A relative /frame_task target is added to the frame's measured pose in the pelvis frame (model_body at the measured joints), the frame of absolute targets, the IK and /left_ee_pose, so the IMU orientation no longer rotates the move. /frame_poses, which its README documents as pelvis-frame, comes from the same placement. Tests: a relative move with the IMU at identity and at yaw -90 deg plus a tilt resolves and reaches the same pelvis-frame target, on both robots. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
… sphere pairs A start-up move whose IK step has no solution (pink's NoSolutionFound, on both robots) logs the closest enabled self-collision pairs and their distances against controller.d_min, and its error says how many are inside it, so a start inside the keep-out reads as self-collision (RobotModel.closest_collision_pairs). The hazard notes in g1_real_robot.launch.py, the README and first-session.md quote the new line. - first-session.md step 8 sends arms_front_45 then home, and says a success:false at the pose (threshold_joint 0.001 rad) is expected. - The G1 sphere model is pinned: golem_ros2_models checks the installed file's sha256, golem_upper_ik that home's closest pair is 24.9 mm from the torso. - CL_Assets 963c93f: the torso spheres were fitted by an optimiser, the lab's original is at f183096; gen_ros_urdf.py's docstrings name golem_ros2_models. - docker_common.sh checks the H1-2 files golem_ros2_models installs (ros only), not h1_2_magpie_ros.urdf; tests/docker follows. - robot_cli.sh and MACOS.md drop the rob_reach stub and its stale crash note. - robots/g1.py names CL_Assets/g1/g1_description; a test comment matches the G1's bound. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…lsense pin Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC # Conflicts: # core_ws/src/golem_bringup/launch/h12/h12_grippers.launch.py
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…ding policy's leg buzz passes Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
The base compose file now mounts HOMIE's policy (/home/code/g1_locomotion) and tools/ (/home/code/tools) into every ros container, launch_ros.sh builds the g1_* packages whatever GOLEM_ROBOT says, and prepare_mounts checks the policy for every ros container. The same container then runs either robot's bringup. docker-compose.g1.yml keeps only what depends on the attached robot: GOLEM_ROBOT=g1, the G1 sim's knobs, and G1_DDS_INTERFACE with its cyclonedds_local.xml pin. tests/docker: the fixture carries the policy for every run; new checks that the base ros service has both mounts and that launch_ros.sh builds every package for the H1-2 too. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
CLAUDE.md/AGENTS.md §3, §4, §9, README.md, docs/RUNNING.md, docs/g1/*, docker/BUILD.md and tests/g1/README.md: the ros container needs no --g1 to run the G1's bringup, every ros container mounts HOMIE's policy and tools/ and builds the g1_* packages, and the H1-2's native onboard build takes the whole workspace. --g1 still selects the sim's robot, docker_stack.sh's bringup and wait_for_sim.py's robot, and the real G1's DDS interface pin. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…up, and the report cuts it at a sim reset The unpowered robot's collapse after the bringup went down could reset the scene (sim time back to 0), which the report read as a recording that ended before the release. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…g1_locomotion is g1_homie core_ws/src/g1/ is gone: g1_dex3 becomes dex_3 and g1_locomotion becomes g1_homie (directory, package, Python module, resource marker), and g1_navigation moves up under its own name. HOMIE's policy/ moves with g1_homie unchanged; the walking node's default policy_dir is now /home/code/g1_homie. Executables, node names, topics, services, actions and parameters keep their names. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…_ws/src/g1_navigation golem_bringup exec_depends on and launches dex_3 and g1_homie; the ros container mounts HOMIE's policy from core_ws/src/g1_homie/policy at /home/code/g1_homie (the walking node's default policy_dir), and docker_common.sh checks it there; the Mac bringup stubs the new names; tests/docker, tests/g1 and tests/robocasa/g1 use the new paths and module. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…_ws/src CLAUDE.md and AGENTS.md (package tables and counts, the HOMIE licence rule's path, the policy mount at /home/code/g1_homie), README.md, docker/BUILD.md, docs/RUNNING.md and docs/g1/ name the new packages and paths. The stale-install cleanup also deletes g1_dex3 and g1_locomotion, and a native H1-2 build leaves the G1's packages out by name. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…fig from core_ws/src/g1_navigation Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MezUeauFS9tKMgZKJxo1HC
…t-up like the H1-2's, cleanup - Rename h12_slam, h12_deploy_mjpc and h12_skills to golem_slam, deploy_mjpc and golem_skills; fold g1_navigation into golem_slam (g1_body_to_pelvis) and golem_skills (/skill/frontier_explore). - G1 bringups start golem_slam by default (use_nav); the real G1 also starts the MID-360 driver (launch/g1/g1_real_drivers.launch.py, g1_MID360_config.json) and FAST_LIO on g1_fastlio.yaml. Not yet run on the robot. - g1_homie pre-poses the legs on the first heartbeat and an upright state, as the H1-2's leg node does; the timing and arm-controller checks gate the policy start instead. The start no longer holds wall-clock sample gaps to half the latency limit, and sim.yaml's tick_rate floor is 0.1, so a sim at 0.2x real time starts. - G1 sim: estop position_offset -0.1 (the H1-2 sim's), head camera scale 0.5 by default, and the Battery workcell task. - Remove dead files and helpers (duplicate FAME weights, standalone_fame_test, unused Nav2 configs, deploy_mjpc controller.yaml, Isaac inspect scripts, sim2real_gap_monitor, policy_manager's unused switch gate, golem_skills' copy of model_logging); fix stale docs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015EG7p9VGB8kvHAmAY1dmDC
main's one commit (8709a1d) bumps the h12_safety_layer submodule, which camera_ready removes (golem_safety replaces it); the removal is kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015EG7p9VGB8kvHAmAY1dmDC
Contributor
Author
|
I'm sorry for my sins |
…era scale empty The runner has no SSH key for .gitmodules' git@github.com URLs. The G1 sim's head camera scale default lives in g1_sensors.py (0.5). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015EG7p9VGB8kvHAmAY1dmDC
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015EG7p9VGB8kvHAmAY1dmDC
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.