Week 9: From Breadboard to Bedside , The Hardening Phase
Transitioning the A.E.G.I.S. framework from a fragile breadboard sprawl into a ruggedized standalone prototype through rigorous stress-testing and empirical validation.
Week 9 has been an exercise in architectural hardening. In engineering, there is a vast chasm between a system that functions on a laboratory bench and one that survives the chaotic variables of a real-world environment. This week, the A.E.G.I.S. framework transitioned from a fragile sprawl of jumper wires into a ruggedized, standalone prototype, accompanied by a rigorous stress-testing regime designed to break the software before it reaches the demonstration phase.
1. The Physical Embodiment: Engineering the Hub
The "Invisible Guardian" now has a physical presence. The transition from a Raspberry Pi 5 breadboard to a final chassis required a deep dive into spatial ergonomics.
The Radar Aperture Challenge: The HLK-LD2410C mmWave radar operates at 24GHz, meaning its "vision" is easily obscured by high-density materials. I spent this week designing a custom mounting bracket that ensures the radar is angled at exactly 15° downward. This ensures that the "Bio-Verification" beam is focused on the floor area, the primary site of a fall, without being obstructed by the Pi 5's active cooling fans or the SPI display wiring.
2. The Philosophy of Reliability: "Edge-Case Hunting"
In a BEng dissertation, testing is not merely a box to be ticked; it is the scientific validation of your claims. I have structured this week's evaluation around the concept of "Technical Integrity versus Human Utility."
- Technical Integrity (Verification): Does the Python physics engine maintain a consistent 10-FPS throughput?
- Human Utility (Validation): Does the "Red Alert" actually provide enough visual contrast to be noticed by a caregiver from 5 metres away?
3. The "Chaos Lab": Experimental Results
Rather than simple pass/fail checks, I conducted a series of "Chaos Experiments" to determine the breaking point of the bimodal logic.
| Experiment ID | Scenario | Mathematical Trigger | System Output | Result |
|---|---|---|---|---|
| EXP-01 | The Rapid Descent | σ>10.0 | Red Alert (100% Conf) | SUCCESS |
| EXP-02 | "The 'Ghost' Disturbance" | σ>10.0 (Chair Drop) | Alert Suppressed (Radar: Empty) | SUCCESS |
| EXP-03 | The Floor-Level Breath | σ<2.5 | Radar: Stationary / Blue State | SUCCESS |
| EXP-04 | Thermal Stress Test | 4-Hour Continuous Runtime | CPU Temp stable at 54°C | SUCCESS |
The "Chair-Drop" Victory: The most significant result was Experiment 02. By dropping a high-mass object, I successfully triggered a Wi-Fi variance spike that mirrored a human fall. However, because the Master Logic Loop queried the radar and received an "Empty" status, the 100% alert was blocked. This proves that the bimodal fusion successfully solves the "False Positive" problem that plagues single-sensor systems.
4. Technical Deep-Dive: Resolving Race Conditions
The most difficult hurdle this week was a Race Condition within the threading model. Occasionally, the Wi-Fi CSI thread would attempt to update the current_confidence variable at the exact micro-millisecond the Radar thread was reading it, causing a GIL (Global Interpreter Lock) hang.
The Solution: I implemented a Thread-Safe Mutex (Mutual Exclusion) Lock. By using Python’s threading.Lock(), I ensured that only one sensor could write to the confidence engine at a time. This minor code adjustment reduced "stuttering" on the ILI9341 display and ensured a consistent data-refresh rate of ~120ms.
— Week 9 Prototype5. The Prototype Status Report
- Chassis Integration: Successfully mounted the bimodal sensor array into a semi-permanent housing.
- Logical Validation: Proved that bimodal sensing effectively ignores non-biological movement.
- Latency Benchmarking: Confirmed that the "Impact-to-Alert" delay is consistently under 450ms.
- Resource Management: Validated that the Pi 5 handles the 256k baud radar stream without thermal throttling.
The Week 10 Horizon: With the physical build complete and the software validated, we move into Performance Evaluation. I will be conducting formal "Living Room Simulations" to calculate Precision and Recall rates, providing the empirical data required for the final chapters of my dissertation.