Repository navigation
Conversation
There was a problem hiding this comment.
go2 replay realtime (arm64)
Details
| Benchmark suite | Current: b61686c | Previous: 14c62ab | Ratio |
|---|---|---|---|
peak memory |
1755.18 MB |
1762.355 MB |
1.00 |
peak threads |
370 threads |
385 threads |
0.96 |
network (transport) |
2729.202 MB |
2731.013 MB |
1.00 |
disk write |
1.602 MB |
1.605 MB |
1.00 |
instructions |
141.047 G |
138.791 G |
1.02 |
This comment was automatically generated by workflow using github-action-benchmark.
[High impact] The PR changes command and feedback paths for three robot platforms. Fix the MuJoCo halt path before merging so the simulated Go2 stops when coordinator commands disappear. FindingsSummaryReplaces shared transport adapters with direct joint commands for R1Pro, G1, and Go2.
Reviews (2) · Last reviewed commit: "test(r1pro): keep focused driver smoke c..." · Reviewed by Greptile |
| arms are held where they were last measured. Stale feedback | ||
| (`reading_timeout_s`, 0.2 s) also stops commands until fresh readings | ||
| return. This replaces the old adapter path, where an estopped robot simply |
There was a problem hiding this comment.
Stale-feedback stop claim overstates protection
The 0.2-second timeout does not cover lost vendor joint feedback. After all three segments first report, _publish_loop keeps publishing cached readings at 100 Hz. ConnectionSource.on_message checks arrival time, not JointState.ts, so commands keep flowing even if all vendor joint feedback stops. Operators could rely on a stop that never happens.
Limit this claim to loss of the connection's published readings, or stop publishing when any vendor segment goes stale.
❌ 18 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
…coordinator A robot behind a ConnectionModule with a cmd_vel port had its base told 0 on every axis every tick, so no task could drive it. Now its base axes (<robot>/base/vx, vy, wz) are registered like an adapter base's virtual joints: tasks claim and win them in arbitration, the tick loop routes them to their own per-robot entry so a velocity task on the base never mode-conflicts with a position task on the joints, and ConnectionSource fills each axis with the winner's speed or 0 when idle or stopped. The coordinator's twist_command mapping covers connection robots too, so the same teleop/nav publishers drive an adapter base or a connection base unchanged. Estop semantics are unchanged: commands stop, the connection module's own deadman halts the robot. Arm-only coordinators and legacy adapter stacks are untouched: a robot without a cmd_vel port has no base axes, and adapters never take the new route.
Follow-up verification for the connection base winners: a velocity task or twist drives vx, vy and wz each non-zero through to the robot's cmd_vel port; two velocity tasks on the same base arbitrate by priority and the loser resumes when the winner stops; and a task whose stream goes quiet zeroes every axis, as an adapter base's does.
The velocity-task timeout can be observed by a later tick than the sleep(0.1) boundary on slow or loaded runners (seen on macOS CI), so keep ticking until the zeroed command shows up.
… hold Greptile review on #5016: - P1: OperatorHoldTask discovered axes only in the joint-state snapshot, which never contains a connection robot's base axes (they are commanded speeds, not read positions), so a running velocity task kept driving the base through a hold, including after an e-stop clear. The coordinator now names every connection base axis to the hold (on start and on add_task), and the hold zeroes them like an adapter base's velocity joints. - P2: the base-timeout test slept 0.1s against a 0.2s reading timeout, so a paused runner stopped the command entirely and the zeroed twist never arrived (seen on macOS CI). The test now advances the task clock (perf_counter, the source of state.t_now) past the task timeout by hand and re-reports the base's feedback right before each tick, so only the task command expires. - P2: the routing test drove an arm named mock and a base named go2, never exercising one robot's <robot>/base split and merge. A new test gives one robot joint ports and cmd_vel and asserts both commands leave in the same tick; another covers the route-level mode-conflict guard, which was the patch's only uncovered code. Regressions: the hold zeroes a running base and keeps it after an e-stop clear (connection level), and unit tests cover set_base_axes with and without an e-stop.
The task clock (perf_counter) was already patched, but the connection source stamps feedback receipts and checks their freshness with the real monotonic clock, so a scheduling pause longer than reading_timeout_s between the last report and the tick could still stale the feedback and drop the zeroing command. Patch time.monotonic with its own frozen clock too, and keep a real 0.25s pause between the report and the tick to prove a slow runner cannot stale the feedback: with the monotonic patch removed the strict assertions fail again.
547f8ef to
5d90023
Compare
| def halt(self) -> None: | ||
| self.connection.stop_movement() |
There was a problem hiding this comment.
Simulated Go2 ignores the stop
GO2Connection.halt() calls MujocoConnection.stop_movement(), which does nothing. If the coordinator stops while the connection stays running, the new deadman calls this method, but the simulator keeps walking at its last speed. The removed adapter sent a zero Twist when it disconnected.
Make the MuJoCo stop path write zero speeds before relying on it here.
Overview
Migrate concrete connections to the shared joint/interface contract and retire the two shared transport adapters. Stacked on #5016.
Problem
The old adapters duplicate routing, while rotating native body commands through odometry unnecessarily couples driving to pose age.
Changes
Validation