ROOKWELD / THE WORKSHOP
Where systems
grow hands.
Physical computing, local infrastructure, strange interfaces and blueprints for machines that do more than live behind glass.
Enter the lab ↓REALITYOS / HUDNODE 01
SYSTEM LINK
ONLINENODENULLFEATHER
NETTAILSCALE / OK
AILOCAL / READY
PING24 MS
01 / THE METHOD
Build small.
Connect carefully.
Learn from reality.
The workshop is where software meets resistance: unreliable networks, limited displays, physical inputs, constrained hardware and everything that makes a clean diagram become a real system.
Not every experiment becomes a product. Every one should make the next build more honest.
02 / BUILDS & PROTOTYPES
Things that have
left the screen.
01BUILT PROTOTYPE
HUD
RealityOS Pocket HUD
A compact ESP32-S3 endpoint that turns system state into a physical glanceable interface — built around a 128×64 OLED, Wi-Fi telemetry and alert overlays.
- ESP32-S3 N16R8
- SSD1306 OLED · 128×64
- Wi-Fi / HTTP endpoint
- INFO · WARN · CRIT overlays
02OPERATIONAL LAB
Z2
realitycore Homelab
An Ubuntu-based workshop server for services, monitoring, storage experiments and RealityOS infrastructure — designed to remain useful even while individual experiments change.
- HP Z2 Mini G9
- Ubuntu Server · Docker Compose
- Prometheus · Grafana
- Tailscale-connected
03BUILT / EVOLVING
AI
Distributed AI Nodes
A split-compute approach where GPU-heavy local models live on the mobile workstation while web tools, services and monitoring remain on the server node.
- ZBook Fury GPU node
- Ollama local models
- API-routed services
- Private node network
04EXPERIMENT SERIES
I/O
Physical Interfaces
Small hardware explorations that test how software can sense, signal and respond beyond a screen — from presence and identity to light, sound and environmental input.
- Raspberry Pi · Arduino
- RFID · BLE · sensors
- GPIO · SPI · I²C
- LEDs · TTS · buttons
03 / SYSTEM BLUEPRINTS
Before the build,
draw the forces.
Selected architecture studies. Blueprints describe intent and system boundaries; they are not presented as proof that every connected component is currently production-ready.
BP-01HUD SIGNAL PATH
SYSTEM
STATE→HUD
API→ESP32
CLIENT→OLED
OVERLAY
Turn distributed state into a compact physical status surface with bounded alerts.
BP-02DISTRIBUTED LAB
FURYGPU / MODELSPRIVATE MESHREALITYCORESERVICES / DATAEDGE NODESHUD / SENSORS
Place each workload where the hardware and availability make sense.
BP-03REALITYOS CONCEPT LAYERS
INTERFACELauncher · HUD · Quick views↓ORCHESTRATIONRouter · Specialist agents · Pipelines↓CONTINUITYMemory layers · Timeline · Incubator↓INFRASTRUCTUREModels · Tools · Nodes · Vault
A system-design reference for RealityOS. The full case study remains paused until the current implementation can be inspected and verified.
04 / ON THE BENCH
Next experiments.
Small by design.
A deliberately short queue. These are directions for the next useful build—not promises disguised as finished products.
B-01NEXT ITERATION
HUD Input Layer
Add a physical button path and intentional acknowledgement flow to the existing ESP32 status display.
B-02EXPERIMENT
Presence & Identity
Explore bounded BLE or RFID presence signals without turning the prototype into an unnecessary surveillance system.
B-03CONCEPT
Ambient Node
A small Raspberry Pi or ESP32 surface for light, sound and environmental signals connected to RealityOS services.
05 / MATERIALS & TOOLS
The stack changes.
The method survives.
COMPUTEESP32-S3 · Raspberry Pi · Arduino · HP Z2 · ZBook Fury
INTERFACESOLED · RFID · BLE · GPIO · SPI · I²C · sensors · LEDs
SOFTWAREPython · Flask · FastAPI · Node-RED · Docker · Ollama
OPERATIONSLinux · Windows · Tailscale · Prometheus · Grafana
DESIGNBlueprints · rapid prototypes · telemetry · failure-aware flows
THE WORKSHOP / ALWAYS IN PROGRESS
Useful things begin
as unreasonable experiments.