Thermal inertia
Heat is slow and delayed. Control decisions must account for where the process is heading, not only the current reading.
Hardware × Software × Controlled Autonomy
The Lab
Where software meets physical constraints.
The Lab explores systems that sense physical behavior, evaluate signal quality, control hardware, and stay within clear safety limits.
Featured laboratory system
RoastOS
A coffee-roasting control system with ESP32 edge sensing, temperature and RPM inputs, airflow and heater control, telemetry, safety limits, manual takeover, profile tracking, and an operator screen.
Roast-state calibration
Bean state is read as a progression in material color and process phase, not as theatrical warm lighting.
- Green
- Yellow
- Cinnamon
- Light
- Medium
- Dark
Lab systemControl system viewAlpha / QA before productionSynthetic operating data
Engineering problems
Reliable control starts with constraints.
Before the system acts, it must trust the inputs, keep the command within safety limits, and show the operator what is happening.
Signal trust
Temperature, RPM, airflow, and environmental signals can drift, fail, or disagree. The system must know when not to trust them.
Coupled outputs
Heater, airflow, drum movement, and chaff handling affect one another. A local correction can create a different downstream problem.
Safety limits
Safety logic must be able to constrain or stop autonomous commands before process targets are considered.
Operator takeover
The operator needs immediate, legible manual control without losing the event history or the system state that led to intervention.
Operator screen
The screen should make process phase, signal quality, and control state clear enough for fast decisions.
Physical / mechanical layer
The machine defines the control problem.
The drum, airflow path, heating surface, enclosure, and sensor locations define what the software can observe and influence. This page explains those boundaries without publishing fabrication instructions.
Movement and agitation
Drum behavior and bean movement shape heat transfer and consistency, so the control model has to respect mechanical behavior.
Airflow and chaff
Air movement changes thermal behavior while chaff handling introduces maintenance, cleanliness, and safety constraints.
Materials and enclosure
Stainless-steel, food-contact, thermal isolation, service access, and cleaning considerations influence the system boundary.
Sensor placement
A sensor is only useful when its location reflects the process state being inferred and remains maintainable under prototype constraints.
Software / control layer
Sense, verify, constrain, act, record.
Each control layer checks the conditions required before the next layer can act.
Edge sensing
An ESP32 edge controller coordinates PT100 temperature sensing, environmental context, RPM, airflow, and heater-control surfaces.
Telemetry loop
A FastAPI control brain receives live state, evaluates process context, records events, and exposes a bounded operator interface.
Sensor trust
Range, stale-signal, jump, persistence, and cross-check concepts help distinguish process movement from unreliable input.
Profile tracking
Roast phases, rate-of-rise behavior, first-crack detection concepts, and target-profile context support controlled progression.
Command limiting
Safety supervisor and failsafe behavior constrain outputs before autonomy can act, preserving a clear operator override path.
Session evidence
Telemetry, markers, state changes, manual interventions, and outcomes remain available for review and refinement.
Technical control and operator-takeover view · no private network values or build details.
Visual modeling layer
The operator screen supports fast decisions.
The drum and bean-state view brings roast curves, phase markers, signal state, color changes, and manual controls into one screen.
The screen reflects the current control concept, not a claim that visual inference alone can determine roast quality.
Why it matters
A clear model for sensor-driven control.
RoastOS connects sensors, signal checks, safety limits, control commands, event history, and manual takeover in one operating model.
Public evidence boundary
Deliberately not exposed
The public page excludes exact wiring, pinouts, firmware logic, dimensions, bill of materials, network values, credentials, and unsafe heating instructions. Safety behavior is described as prototype control logic, not certified safety or production readiness.