Skip to content

UAT US14/US5: firmware choreography & security sweep servos don't move #166

Description

@BrettKinny

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: macarena streams audio, but no state_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_start emitted, 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 → dance in 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.

Activity

  1. added
    bugSomething isn't working
    area:firmwareESP32-S3 firmware (stackchan-fw)
    needs-triageAwaiting triage (see docs/agents/triage-labels.md)
    ready-for-humanRequires human implementation or live-device verification
    status:activeReady to start, not blocked
    and removed
    needs-triageAwaiting triage (see docs/agents/triage-labels.md)
    on Jul 11, 2026
  2. BrettKinny commented on Jul 11, 2026

    @BrettKinny
    OwnerAuthor

    This was generated by AI during triage.

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:firmwareESP32-S3 firmware (stackchan-fw)bugSomething isn't workingready-for-humanRequires human implementation or live-device verificationstatus:activeReady to start, not blocked

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions