setup: enable Wi-Fi + fix model download paths + survive SSH session drops

[Carl Chalmers (Clamps251)]

Three independent bugs in sparrow_setup.sh that all surfaced during a series of fresh field installs. Bundled here because all three touch the same file and were found in the same debugging session.

Fix 1 — Enable Wi-Fi radio before the hotspot prompt

Some fresh Pi Trixie installs ship with wifi soft-blocked (via rfkill) or with nmcli radio wifi off. When either is the case, setup_persistent_wifi_hotspot fails with a cryptic NetworkManager error and no clear signal to the operator that they just need to unblock wifi. The fix is one small idempotent helper called before the hotspot config:

enable_wifi_radio() {
    log "Ensuring Wi-Fi radio is enabled..."
    rfkill unblock wifi 2>/dev/null || true
    nmcli radio wifi on 2>/dev/null || true
}

Both commands exit 0 when wifi is already enabled — safe to run unconditionally on every install.

Fix 2 — ONNX model download paths missing tritonserver/model_repository/ segment

The container's LOCAL_MODELS_DIR (in sparrow.env) and the bind mount in docker-compose.yml both expect models under .../Models/tritonserver/model_repository/<name>/1/model.onnx. But the setup script was downloading all three ONNX models one directory level too high — to \$SYSTEM_FOLDER/Models/<name>/1/model.onnx — so on a fresh install audio.py logs Audio ONNX model not found at: /home/sparrow/Desktop/system/Models/tritonserver/model_repository/megadetector_birds_v1/1/model.onnx and inference.py fails the same way as soon as the first image arrives.

Fixed all six occurrences (three download_model_* functions + three matching mkdir -p in create_folders) to include the middle segment. Reference deployment (192.168.1.233) was unaffected because its models were placed manually before the current download step existed — this bug only bites fresh installs.

Fix 3 — Survive SSH session drops

sparrow_setup.sh runs set -euo pipefail with no signal traps. When a Pi Connect / SSH session drops mid-run (extremely common on slow field networks during the multi-minute Docker download), the parent shell dies, sends SIGHUP to the script, and it terminates silently — no error line in the log, no error on the (now-dead) terminal, no way for the operator to know where it stopped. One line at the top of the script fixes this:

trap '' HUP PIPE

HUP = ignore parent shell death. PIPE = ignore broken-pipe from writing to the now-dead terminal. The script keeps running, keeps writing to /var/log/sparrow_setup.log, and the operator can reconnect and tail -f to catch up on progress.

Discovered during a real field install where the Docker step died silently after "Reading state information..." with no error. Manual re-execution of every command in install_docker_pi_debian() succeeded — proving the commands were correct, the failure was just the session being killed by SSH transport.

[Copilot]

Pull request overview

This PR updates the Raspberry Pi field install setup script to make installs more reliable on fresh images by ensuring Wi‑Fi is enabled before configuring the hotspot, fixing ONNX model download directory structure to match the container mount, and attempting to keep setup running through SSH/Pi Connect session drops.

Changes:

• Add a trap intended to ignore SIGHUP/SIGPIPE so the setup script continues running after SSH disconnects.
• Introduce enable_wifi_radio() and invoke it before the hotspot password prompt/setup.
• Fix ONNX model download and folder creation paths to include Models/tritonserver/model_repository/....

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.