| name | pi-iteration-workflow |
| version | 1.0.0 |
| description | Edit-test workflow for the voldemorbot robot codebase — Windows-to-Pi SSH deploy loop, pixi/ROS2 rebuild triggers, flaky-WiFi survival via screen, PowerShell SSH quoting pitfalls, sudo caching on the Pi Zero. Use when pushing platform/robot changes to hardware, restarting the robot service, or a Pi SSH session misbehaves. |
Pi Iteration Workflow
Fast loop for editing platform/robot code on Windows and testing it live on real hardware over SSH. Companion to ros2-architect for the ROS2/Pixi workspace conventions this loop deploys — this skill owns the deploy mechanics, not the workspace architecture. Full host table and command sequences in RECIPES.md.
1. Access
- Prefer
rpi-5-direct (192.168.250.2, direct Ethernet) over WiFi aliases or the Cloudflare tunnel — the tunnel is often broken/unauthenticated and shouldn't be relied on. Full alias table in RECIPES.md.
- Account is
ralvarezdev, not pi, on both boards. Identity file: D:\Secrets\ssh\raspberrypi\id_ed25519_ralvarezdev.
- Pi 5 has passwordless sudo; the Pi Zero does not. Any
sudo command touching the Pi Zero needs an interactive password — run those in the user's own terminal, never through a non-interactive tool call.
- mDNS (
.local) resolution flakes on this network. Fall back to the raw IP with an explicit -i — the raw IP doesn't match the ~/.ssh/config Host pattern, so the identity file isn't picked up automatically.
2. The edit-test loop
- Edit
platform/robot/... locally on Windows.
- Commit + push to
master.
cd ~/voldemorbot && git pull on the target Pi.pixi.toml/pixi.lock changed → ~/.pixi/bin/pixi install -e dev.- Any
ros2_ws/src source changed → ~/.pixi/bin/pixi run -e dev build-ws. Editing source alone does nothing — this step is what actually installs launch files and console_scripts.
- Restart the service:
sudo systemctl restart voldemorbot-pi-zero.service (or -pi5).
- Verify it stuck with
systemctl status ... --no-pager -l, then journalctl -u ... --since 'HH:MM:SS' --no-pager -l for the actual node output — status alone truncates it.
3. Regenerating pixi.lock
Always lock on the Pi 5, never Windows — Windows can't cross-build several aarch64 conda-forge sdists (e.g. netifaces) and pixi lock just hangs. The Pi 5 has 16GB RAM and is the real target arch, so it resolves cleanly and fast. Full lock-and-sync-back sequence in RECIPES.md.
4. Surviving a flaky connection
WiFi/mDNS on this network drops mid-session often enough that anything long-running (pixi install fetching packages, a colcon build) must run inside screen, not foreground SSH — the process then survives the disconnect independent of the SSH session. Detach with Ctrl+A D (not Ctrl+C); reattach with screen -d -r work (the -d force-detaches a stale "Attached" state a plain -r would refuse). /tmp is wiped on every reboot, so anything staged there needs re-copying after one. Command sequence in RECIPES.md.
5. PowerShell SSH gotcha
Don't build one SSH command string with nested double-quotes and | for PowerShell to parse — pipe characters get read as PowerShell's own pipeline operator mid-string, and \" escaping doesn't survive it. Instead, ssh -t into the box with no trailing command, then run the actual multi-line command block directly in the resulting Pi shell.
6. Sudo credential caching
A successful interactive sudo on the Pi Zero caches for ~15 minutes (/run/sudo/ts/<uid>), so a sudo systemctl restart ... issued non-interactively shortly after will succeed silently. Don't assume the window is still open, though — if sudo reports "a password is required," hand the command back to the user to run interactively rather than retrying it yourself.
