|
| 1 | +Minimum Experiment Code |
| 2 | +======================= |
| 3 | + |
| 4 | +Why This Example Exists |
| 5 | +----------------------- |
| 6 | + |
| 7 | +After you run the sample task once, the next useful question is usually: |
| 8 | + |
| 9 | +``What is the smallest amount of code I need to write my own experiment?`` |
| 10 | + |
| 11 | +The answer is **not** "put everything in one script and call random BehavBox |
| 12 | +methods directly." That would be shorter, but it would teach the wrong pattern. |
| 13 | + |
| 14 | +The supported minimum pattern is: |
| 15 | + |
| 16 | +1. one small task module containing only task logic |
| 17 | +2. one runner script for local mock use |
| 18 | +3. one runner script for a headless Raspberry Pi (RPi) over Secure Shell (SSH) |
| 19 | +4. one small session-configuration helper |
| 20 | + |
| 21 | +This keeps the code small while still using the current supported lifecycle. |
| 22 | + |
| 23 | +Where The Example Lives |
| 24 | +----------------------- |
| 25 | + |
| 26 | +The tracked example files are: |
| 27 | + |
| 28 | +- ``sample_tasks/minimal_experiment/task.py`` |
| 29 | +- ``sample_tasks/minimal_experiment/session_config.py`` |
| 30 | +- ``sample_tasks/minimal_experiment/run_mock.py`` |
| 31 | +- ``sample_tasks/minimal_experiment/run_pi.py`` |
| 32 | + |
| 33 | +The Shared Session Configuration |
| 34 | +-------------------------------- |
| 35 | + |
| 36 | +The session helper builds the ``session_info`` dictionary in one place: |
| 37 | + |
| 38 | +.. literalinclude:: ../../sample_tasks/minimal_experiment/session_config.py |
| 39 | + :language: python |
| 40 | + :lines: 1-67 |
| 41 | + |
| 42 | +Why it is written this way: |
| 43 | + |
| 44 | +- output paths are centralized |
| 45 | +- the mock and headless-Pi versions stay consistent |
| 46 | +- the task code does not need to know where files should be written |
| 47 | +- the only real difference between the two modes is whether audio stays mocked |
| 48 | + |
| 49 | +The Minimal Task |
| 50 | +---------------- |
| 51 | + |
| 52 | +The task module contains the experiment logic itself: |
| 53 | + |
| 54 | +.. literalinclude:: ../../sample_tasks/minimal_experiment/task.py |
| 55 | + :language: python |
| 56 | + |
| 57 | +What this task does: |
| 58 | + |
| 59 | +- plays one cue |
| 60 | +- opens one response window |
| 61 | +- watches for one response event |
| 62 | +- optionally delivers reward |
| 63 | +- stops cleanly after a response or after the response window expires |
| 64 | + |
| 65 | +Why it is written this way: |
| 66 | + |
| 67 | +- ``prepare_task()`` holds setup that belongs to the task, not to the runner |
| 68 | +- ``start_task()`` starts the experiment by entering the first phase |
| 69 | +- ``handle_event()`` reacts only to relevant input events |
| 70 | +- ``update_task()`` advances the finite state machine (FSM) based on time |
| 71 | +- ``finalize_task()`` returns a small summary that becomes |
| 72 | + ``final_task_state.json`` |
| 73 | + |
| 74 | +This is the smallest useful pattern that still matches the current task API. |
| 75 | + |
| 76 | +Run It Locally In Mock Mode |
| 77 | +--------------------------- |
| 78 | + |
| 79 | +Use this version on your local machine when you want the browser mock user |
| 80 | +interface (UI). |
| 81 | + |
| 82 | +The runner code is: |
| 83 | + |
| 84 | +.. literalinclude:: ../../sample_tasks/minimal_experiment/run_mock.py |
| 85 | + :language: python |
| 86 | + |
| 87 | +Run it with: |
| 88 | + |
| 89 | +.. code-block:: bash |
| 90 | +
|
| 91 | + cd /Users/lukesjulson/codex/RPi4_refactor/targets/RPi4_behavior_boxes_hardware |
| 92 | + uv run python -m sample_tasks.minimal_experiment.run_mock --session-tag tutorial_minimal |
| 93 | +
|
| 94 | +What is specific to local mock mode: |
| 95 | + |
| 96 | +- it forces mock mode with ``BEHAVBOX_FORCE_MOCK=1`` |
| 97 | +- it starts the browser mock UI automatically |
| 98 | +- it tells you to pulse ``lick_3`` in the browser |
| 99 | + |
| 100 | +This is the right choice when: |
| 101 | + |
| 102 | +- you are working on a desktop or laptop |
| 103 | +- you want to test task flow without real hardware |
| 104 | +- you want to debug the task logic first |
| 105 | + |
| 106 | +Run It On A Headless Pi Over SSH |
| 107 | +-------------------------------- |
| 108 | + |
| 109 | +Use this version when you are logged into a real box over SSH and want the |
| 110 | +responses to come from the physical hardware. |
| 111 | + |
| 112 | +The runner code is: |
| 113 | + |
| 114 | +.. literalinclude:: ../../sample_tasks/minimal_experiment/run_pi.py |
| 115 | + :language: python |
| 116 | + |
| 117 | +Example command on the Pi: |
| 118 | + |
| 119 | +.. code-block:: bash |
| 120 | +
|
| 121 | + cd ~/behavbox/RPi_behavior_boxes_hardware |
| 122 | + uv run python -m sample_tasks.minimal_experiment.run_pi \ |
| 123 | + --output-root ~/behavbox_runs \ |
| 124 | + --session-tag tutorial_minimal |
| 125 | +
|
| 126 | +What is specific to the headless-Pi version: |
| 127 | + |
| 128 | +- it does **not** force mock mode |
| 129 | +- it disables automatic mock-UI startup |
| 130 | +- it assumes inputs come from the real box |
| 131 | + |
| 132 | +This is the right choice when: |
| 133 | + |
| 134 | +- you are connected to a headless Pi over SSH |
| 135 | +- you want a real hardware run |
| 136 | +- you do not expect a local browser control panel to appear automatically |
| 137 | + |
| 138 | +Why There Are Two Runner Files |
| 139 | +------------------------------ |
| 140 | + |
| 141 | +This split is intentional. |
| 142 | + |
| 143 | +The mock and headless-Pi versions should not be hidden behind one opaque flag, |
| 144 | +because users need to understand which environment they are running in: |
| 145 | + |
| 146 | +- local mock mode is for safe local testing with a browser UI |
| 147 | +- headless Pi mode is for real box execution over SSH |
| 148 | + |
| 149 | +If those modes are mixed together carelessly, users end up not knowing whether |
| 150 | +they are testing their code or their hardware. |
| 151 | + |
| 152 | +What To Copy For Your Own Task |
| 153 | +------------------------------ |
| 154 | + |
| 155 | +If you want to start a new task, copy these pieces: |
| 156 | + |
| 157 | +1. ``task.py`` |
| 158 | +2. ``session_config.py`` |
| 159 | +3. one runner script that matches how you plan to work |
| 160 | + |
| 161 | +Then change only the task logic first: |
| 162 | + |
| 163 | +- cue selection |
| 164 | +- response event |
| 165 | +- stop condition |
| 166 | +- reward rule |
| 167 | + |
| 168 | +Do **not** start by rewriting the runner or bypassing ``TaskRunner`` unless you |
| 169 | +have a clear reason. The runner is what gives you: |
| 170 | + |
| 171 | +- consistent startup and shutdown |
| 172 | +- standard task artifacts |
| 173 | +- a path that still matches the current hardware repo architecture |
0 commit comments