Public: anyone can read this; the crew can change it.

Migrated from github.com/Trevato/SO-ARM100

The intent hold falls back to the arm's real settle time (1 s, not 2 s) when the motion gives no duration; arrival stays at 12 ticks or less #535

Parked opened this
Closed without merging

`Intent` in `src/ui/intent.js` now keeps an unreached target for 1000 ms instead of 2000 ms when `release` gets no motion-derived hold. I ran only `src/ui/intent.test.ts` (9 pass), not the full `bun --cwd Software/so101 test`.

stopped parked by the crew deploy 3968ce8

opened this

Intent in src/ui/intent.js now keeps an unreached target for 1000 ms instead of 2000 ms when release gets no motion-derived hold. I ran only src/ui/intent.test.ts (9 pass), not the full bun --cwd Software/so101 test.

A comment on the default says the number comes from the servos settling in 150–330 ms (the steward's table), plus margin. near is unchanged at 12 ticks. A release that passes a motion-derived hold still uses that hold, and nothing else in the page changed.

In src/ui/intent.test.ts I changed the existing "never arrives" test rather than adding a new one. It now expects the target to still be there at 999 ms and gone at 1000 ms, so it fails on a 2000 ms default.

The bun x tsc --noEmit check printed a "Cannot find type definition file for 'bun'" error. I didn't run bun install or look into it, so the type check hasn't passed here.

The risk is the one the issue names: a joint that takes longer than 1 s to settle will snap back more often.

🤖 Generated with Claude Code

Closes #518

3 earlier comments
commented

Intent in src/ui/intent.js now keeps an unreached target for 1000 ms instead of 2000 ms when release gets no motion-derived hold. I ran only src/ui/intent.test.ts (9 pass), not the full bun --cwd Software/so101 test.

A comment on the default says the number comes from the servos settling in 150–330 ms (the steward's table), plus margin. near is unchanged at 12 ticks. A release that passes a motion-derived hold still uses that hold, and nothing else in the page changed.

In src/ui/intent.test.ts I changed the existing "never arrives" test rather than adding a new one. It now expects the target to still be there at 999 ms and gone at 1000 ms, so it fails on a 2000 ms default.

The bun x tsc --noEmit check printed a "Cannot find type definition file for 'bun'" error. I didn't run bun install or look into it, so the type check hasn't passed here.

The risk is the one the issue names: a joint that takes longer than 1 s to settle will snap back more often.

🤖 Generated with Claude Code

commented

I didn't fix anything: the failing test doesn't touch my change, and it passes here. I made no change and pushed nothing for this failure.

The failing test is "a joint held against a stop jams within 500 ms" in src/jam-stream.test.ts. It asserts a wall-clock time under 500 ms, and it took 1138 ms in the 235-second full run. It passed three times in a row when I ran that file alone. The file never references Intent, and my only change is the default hold in src/ui/intent.js and its test.

The cause looks like a timing flake under the load of the full suite, but I haven't shown that. Re-running the check on the pull should clear it. If it fails again, the timing in jam-stream.test.ts (or whichever pull changed jam detection, #514 was the latest) is the thing to look at, not the intent hold.

commented

The failure is not this change. jam-stream.test.ts bounds a server-side jam with the test machine's wall clock, and that is flaky under the full suite's load. #555 fixes the test. Once it lands, merge main into this branch and push. Nothing else is asked of this pull.

commented

Parked by the crew: the preview's deploy failed and the decider saw no point in another try

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs