Repository navigation
UAT US14/US5: firmware choreography & security sweep servos don't move #166
Copy link
Copy link
Open
Labels
area:firmwareESP32-S3 firmware (stackchan-fw)ESP32-S3 firmware (stackchan-fw)bugSomething isn't workingSomething isn't workingready-for-humanRequires human implementation or live-device verificationRequires human implementation or live-device verificationstatus:activeReady to start, not blockedReady to start, not blocked
Description
Symptom. Scripted physical motion doesn't execute, even though the state/audio/event
layers fire correctly. Idle-motion head glances DO work, so it's choreography/sweep-specific.
Evidence.
- US14 dance:
Dance mode: macarenastreams audio, but nostate_changed → dance,
no_handle_dance, no rainbow ring, no body movement. Resolves via song-playback path only. - US5 security:
state_changed → security+security_pose scan_startemitted, capture
loop started, photo taken — but the yaw sweep (−500→+500→0) never executed.
Expected. Dance runs choreography + rainbow ring; security performs the yaw sweep.
Log excerpt.
20:04:02 Dance mode: macarena / streaming singing audio macarena.mid # no state_changed->dance
20:07:14 event state_changed -> security ; event security_pose scan_start # but no physical sweep
Note. US14 "didn't move this time" suggests possible intermittency. audio_capture_pending
in the security loop is the known #31 pending, not part of this issue.
Video verification (2026-07-11 phone recording IMG_1295.MOV, starts 19:41:32).
- Dance window: frames at 20:04:04 / 20:04:12 / 20:04:22 show the head and body in an
identical pose across 18 s while the mouth/speech-bubble animates — audio playing,
zero choreography, no rainbow ring visible. - Security window: frames at 20:07:17 / 20:07:28 / 20:07:38 show the camera-capture view
then a return to the neutral face with no yaw change across 21 s — capture loop ran,
sweep didn't. - Nuance preserved: for dance there is no
state_changed → dancein any log, so the
firmware dance state may never have been entered (event emission vs state entry is
unresolved without serial capture); for security the state was entered and the pose
event emitted, yet the sweep still didn't run. Two distinct failure layers.
From the filmed UAT session 2026-07-11 (uat-sessions/2026-07-11/: results.csv, container logs, two video recordings). Investigated and drafted with AI assistance (Claude Fable 5 via Claude Code); human-reviewed before filing.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
area:firmwareESP32-S3 firmware (stackchan-fw)ESP32-S3 firmware (stackchan-fw)bugSomething isn't workingSomething isn't workingready-for-humanRequires human implementation or live-device verificationRequires human implementation or live-device verificationstatus:activeReady to start, not blockedReady to start, not blocked
Activity
BrettKinny commentedon Jul 11, 2026
Implemented across draft PR #171 and StackChan firmware commit
969c2b2: dance now enters/exits the firmware state, LED MCP arguments match the firmware schema, server choreography owns the dance timeline, firmware holds exclusive cooperative motion ownership, and IMU overlap cannot steal another owner's lock. Cancellation/admin/fast-completion races have regression coverage.Firmware prerelease:
fw-v1.3.3-rc.1. The security sweep root layer still needs serial/physical verification; no speculative servo fix was applied. Evidence clips:2026-07-11-US14-FAIL-phone.mp4,2026-07-11-US5-FAIL-phone.mp4.