Build the experiment, not just the analysis
A hands-on systems challenge: use an ESP32 and Python to turn a behavioral rule into timed stimuli, trustworthy events, live monitoring, durable data, and a defensible result.
Behavioral rigs are where an experimental idea meets physical reality. A useful controller must deliver the intended stimulus, recognize what happened at the inputs, remain safe when something fails, and leave a record another scientist can reconstruct later.
RuleShift asks you to build that complete path. Two pushbuttons stand in for left and right lick sensors, so the entire exercise is completed on a bench. No animals, reward systems, lasers, or other experimental equipment should be connected.
- Core
- 8–10 hours
- Controller
- ESP32
- Interface
- Python
- Mode
- Bench only
The system boundary matters
Python supervises. The ESP32 runs the experiment.
Desktop scheduling and USB serial latency are not experimental clocks. The GUI sends a validated configuration and receives events; the ESP32 owns trial timing, state transitions, inputs, outputs, and timestamps.
Python GUI
- Configure and validate
- Connect and monitor
- Write files continuously
- Display live behavior
ESP32
- Run the state machine
- Own stimulus timing
- Debounce responses
- Timestamp every event
Behavior box
- Play two tones
- Control two LEDs
- Read two buttons
- Return to a safe state
The experiment
RuleShift
The operator hears a low or high tone and responds using the left or right button. The correct mapping reverses halfway through the session. The system records whether the operator adapts, repeats the old rule, develops a side bias, or misses the response window.
| Block | Low tone | High tone |
|---|---|---|
| Acquisition | Left response | Right response |
| Reversal | Right response | Left response |
Variable ITI
The ESP32 waits for a seeded random interval.
Auditory cue
A low or high tone specifies the correct side.
Response
The first valid left or right button edge is scored.
Feedback
LEDs and an error tone report the outcome.
Rule switch
Halfway through, the tone-to-side mapping reverses.
What you will build
One experiment, four engineering layers
Firmware
Implement an explicit, non-blocking finite-state machine. The ESP32 owns the experimental clock, trial sequence, outputs, input edges, outcome logic, and safe stop.
Communication
Use a documented line-oriented protocol with configuration acknowledgements, errors, trial identifiers, state, and monotonic device timestamps.
Control interface
Build a responsive Python GUI for discovery, connection, parameter entry, manual hardware tests, session control, live events, metrics, and plotting.
Analysis
Rebuild trials from the raw event stream, validate timing and sequence integrity, then quantify accuracy, reaction time, bias, reversal cost, and perseveration.
Event first
Save what happened, not only the score
The append-only event stream is the source record. A trial table is reconstructed from it. Every session also keeps its configuration, seed, software provenance, and figures.
{"t_us":1532400,"trial":12,
"event":"tone_on","value":"high",
"state":"TONE"}
{"t_us":2145100,"trial":12,
"event":"response","value":"left",
"valid":true,"state":"RESPONSE"}
{"t_us":2145500,"trial":12,
"event":"outcome","value":"incorrect",
"state":"FEEDBACK"}Live operation
Show state, trial, events, outcomes, rolling accuracy, latest reaction time, and at least one updating plot without freezing.
Failure is data
Surface malformed lines, impossible sequences, disconnects, and missing events. Never make a broken trial look complete.
Submission
What to send back
- 01ESP32/Arduino firmware and tested board/core version
- 02Python GUI source with environment and launch instructions
- 03Wiring diagram, final pinout, and documented serial protocol
- 04One complete raw demonstration session and derived trial table
- 05Analysis notebook or script with saved figures
- 06Completed design write-up and a two- to three-minute demonstration video
The submitted recording may come from you or another adult pressing the buttons as a bench demonstration. It should not be presented as a formal human-subjects result.
How we review it
Trustworthiness over polish
A thoughtful partial system with a precise account of its failure is stronger than a complete-looking interface that drops events or hides uncertainty.
Timing architecture
Stimulus and response timing belongs on the ESP32. We look for understandable state transitions and measured timing—not GUI sleeps.
Data integrity
Raw events should survive interruption, preserve both device and host timing, and expose malformed or impossible sequences.
Reliability
Buttons should behave as edges rather than repeated levels, the interface should remain responsive, and every stop path should leave outputs safe.
Experimental judgment
Outcome definitions, reversal measures, quality control, and limitations should follow from the experiment rather than from the plot you hoped to see.
Ground rules
Build carefully and report honestly.
Bench testing only. Do not connect this controller to an animal, valve, laser, or other experimental apparatus.
AI tools are allowed. Tell us where they materially helped and how you checked their output. You should be able to defend every state transition and analysis.
Partial work is welcome. Stop near the suggested time budget. Do not hide failed tests or fabricate a successful demonstration.
Questions people ask
Do I need prior neuroscience experience?
No. The experimental logic is explained in the package. You should be comfortable programming in Python and willing to learn or demonstrate basic embedded programming, circuits, and serial communication.
Do I need to use a particular GUI framework?
No. PySide6, PyQt, Tkinter, or another Python desktop toolkit is acceptable. The important requirements are responsive serial handling, clear state, durable logging, and reproducible operation.
Can I use different pins or components?
Yes. Document the final wiring and use electrically safe components. A passive piezo buzzer is the simplest audio device. Do not drive an ordinary low-impedance speaker directly from an ESP32 GPIO.
Does the submitted session need convincing learning?
No. This is a system demonstration, not a human-subjects study. We care whether the events are trustworthy and whether your analysis distinguishes a behavioral result from a hardware or timing artifact.
What if I do not finish everything?
Stop near the suggested time budget and submit careful partial work. Explain what is missing, which parts you tested, what failed, and which next step has the highest priority.
Can I request an accessible alternative to tones or buttons?
Yes. The core skills are architecture, event integrity, and analysis—not hearing acuity or dexterity. Email amohebi@wisc.edu for an equivalent visual-cue or accessible-switch version.
Start here
Download the complete challenge
The ZIP includes the full specification, write-up template, hardware smoke test, serial-port helper, analysis checklist, and example configuration and events.
ESP32/Arduino · Python · JSONL/CSV