Add claude GitHub actions 1777390682438#1928
Add claude GitHub actions 1777390682438#1928zhangyinxina-ui wants to merge 6 commits intodimensionalOS:mainfrom
Conversation
…d-stair-climbing-feature Add 3D navigation and stair-climb skills to Unitree G1 skill container with tests
…d-stairs-feature Add 3D stair-climbing waypoints and navigation skill
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e3469dfe11
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if planar_distance > 1e-3: | ||
| duration = planar_distance / safe_speed | ||
| move_rpc( | ||
| Twist(linear=Vector3(safe_speed if x >= 0 else -safe_speed, 0.0, 0.0), angular=Vector3()), |
There was a problem hiding this comment.
navigate_3d
After navigate_3d rotates to atan2(y, x), the robot is already facing the requested planar target direction, so using x to choose forward/backward speed flips movement for all goals with x < 0. For example, x=-1, y=0 rotates ~180° and then drives backward, which sends the robot away from the intended offset rather than toward it. This makes a large portion of 3D navigation requests systematically incorrect.
Useful? React with 👍 / 👎.
Greptile SummaryThis PR adds stair-climbing skills (
Confidence Score: 3/5Not safe to merge — two P1 defects cause incorrect robot motion and immediate false failure during stair traversal. Two independent P1 bugs: navigate_3d drives in the wrong direction for any x<0 target, and climb_stairs_3d will falsely abort on the first poll of every waypoint if the navigation stack is even slightly slow to acknowledge the goal. Both affect the primary purpose of this PR. dimos/robot/unitree/g1/skill_container.py (direction bug in navigate_3d) and dimos/agents/skills/navigation.py (race condition in climb_stairs_3d polling loop) Important Files Changed
Sequence DiagramsequenceDiagram
participant Agent
participant NavigationSkill as NavigationSkillContainer
participant G1Skill as UnitreeG1SkillContainer
participant NavStack as NavigationInterface RPC
participant MoveRPC as G1ConnectionBase.move
Note over Agent,MoveRPC: climb_stairs_3d flow (NavigationSkillContainer)
Agent->>NavigationSkill: climb_stairs_3d(goal_x, goal_y, total_height, steps)
NavigationSkill->>NavigationSkill: generate_stair_waypoints()
loop For each waypoint
NavigationSkill->>NavStack: set_goal_rpc(waypoint)
loop Poll until timeout
NavigationSkill->>NavStack: get_state_rpc()
NavigationSkill->>NavStack: is_goal_reached_rpc()
end
end
NavigationSkill-->>Agent: Completed stair climbing...
Note over Agent,MoveRPC: navigate_3d flow (UnitreeG1SkillContainer)
Agent->>G1Skill: navigate_3d(x, y, z, speed)
G1Skill->>MoveRPC: yaw align (angular only)
G1Skill->>MoveRPC: planar move (linear.x = +/-safe_speed) ⚠️
G1Skill->>G1Skill: _run_stair_sequence(z)
loop step_count segments
G1Skill->>MoveRPC: move forward/backward
end
G1Skill-->>Agent: 3D navigation completed...
Reviews (1): Last reviewed commit: ""Claude Code Review workflow"" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| move_rpc( | ||
| Twist(linear=Vector3(safe_speed if x >= 0 else -safe_speed, 0.0, 0.0), angular=Vector3()), | ||
| duration=duration, | ||
| ) |
There was a problem hiding this comment.
The yaw-alignment step (lines 132–138) rotates the robot so its forward direction points at (x, y). After that rotation, the robot should always move forward (+safe_speed) to reach the target. Using safe_speed if x >= 0 else -safe_speed is wrong: for any target where x < 0 (e.g., x=-1, y=0), the robot rotates 180° and then drives backward, which moves it away from the target instead of toward it.
move_rpc(
Twist(linear=Vector3(safe_speed, 0.0, 0.0), angular=Vector3()),
duration=duration,
)| while time.time() - start_time < timeout_per_step: | ||
| if get_state_rpc() == NavigationState.IDLE: | ||
| if is_goal_reached_rpc(): | ||
| break | ||
| return f"3D stair navigation failed at waypoint {idx}/{len(waypoints)}." | ||
| time.sleep(0.2) |
There was a problem hiding this comment.
Right after set_goal_rpc(waypoint) is called, the poll loop immediately enters and checks get_state_rpc() == NavigationState.IDLE. If the navigation stack hasn't yet transitioned out of IDLE (it is still processing/acknowledging the new goal), the condition evaluates to IDLE + is_goal_reached = False, which causes an instant return of the failure string — killing the climb on every waypoint. A brief startup grace period (e.g., waiting for the state to leave IDLE before applying the IDLE=failure branch) is needed to prevent this false early-exit.
1 participant
Problem
Closes DIM-XXX
Solution
Breaking Changes
How to Test
Contributor License Agreement