Practice Project for Systems Engineering - Part 2

Part 1 was all whiteboards and sticky notes: we argued over requirements, carved a latency budget, and froze a mission that could be proven on a kitchen table. That was the left-hand descent of the V-model.

Part 2 begins the climb up the right-hand side. Here the abstractions acquire voltages, GPIO pins and FreeRTOS tasks. We will:

1. Pin every SMART requirement to a functional block. You'll see a tight sense → estimate → decide → act pipeline that closes in 10 ms—fast enough to intervene five times before the car has rolled a single wheel-diameter.

2. Choose silicon and copper that can't mis-brake. A $20 QuicRun ESC supplies dynamic-braking torque, an ELRS receiver delivers low-loss throttle frames, and a $1 74HC157 mux makes sure the radio always has veto power if firmware dies.

3. Split software into four clean layers. The Application layer ships features; the Domain layer does the math; the Service layer adapts ports; HAL drivers and RTOS tasks sit at rock bottom. Every layer is unit-testable on a PC.

4. Give the driver two eyes, not one. A WildFire Nano AIO camera/VTx provides a 13-17 ms analogue feed for racing, while the ESP32 still pushes MJPEG over Wi-Fi for bench work. The two links share nothing but a battery, so congestion on one can't sink the other.

By the end of this part you'll have the full bill-of-materials, a layered codebase skeleton, and concrete verification hooks—all ready for the soldering iron. If Part 1 was the blueprint, Part 2 is the build manual. Let's zoom in.

DISCLAIMER: I haven't done extensive testing for the hardware pieces included in the project. Since this is an exercise, I "trusted" GPT o3 with the estimates for the latencies and such. If I were planning to carry on with this project, a whole verification and validation process would need to be done for those parts.

1 Functional Architecture - What the System Does

In classical control parlance this is a sense → estimate → decide → act pipeline. The feedback loop closes every 10 ms, giving the controller five fresh opportunities to intervene during the 25 ms it takes the car to travel 20 cm at 30 km h⁻¹.

Anything that cannot be traced forward to a requirement,or backward to a verification step,gets chopped as scope-creep.

2 Physical Architecture - What the System Is

As with other parts of the series, selecting certain parts, such as the MCU, ESC, Servos, etc., must be carefully considered. Here, I'm "trusting" the LLM (GPT o3) to select for me, but if I were to build the system, I would refine this part in detail.

Design intent

• Fail-silent hardware path. Radio PWM always has a physical lane to the ESC. The ESP32 takes over only while a watchdog-toggled GPIO keeps the mux selected; loss of toggling (<30 ms) reverts to radio.
• All life-critical loads share the main Li-Po rail—if SmartDrive-XR dies, the driver regains stock control immediately.
• WildFire Nano gives a sub-10 ms FPV feed for racing; Wi-Fi MJPEG stays for bench work.

3 Software Architecture - Where Behaviour Lives in Time

3.1 Layered View

┌────────────────────────────────────────────────────────────┐
│   Application layer ("features")                           │
│    • ABSController • FailsafeManager • LatencyProfiler     │
│    • FpvOsdManager                                         │
│────────────────────────────────────────────────────────────│
│   Domain layer ("business logic")                          │
│    • VehicleState • PwmShapeStrategy • ControlLaw (PID)    │
│    • StateEstimation                                       │
│────────────────────────────────────────────────────────────│
│   Service layer ("ports & adapters")                       │
│    • StateProvider • SpeedCommander • CsvLogger            |
|    • MjpegStreamer • FpvMonitor (RSSI) • **PwmMuxDriver**  │
│────────────────────────────────────────────────────────────│
│   HAL + RTOS (drivers & tasks)                             │
│    • imu\_bmi270.c • hall\_driver.c • esc\_pwm\_driver.c   │
│    • fpv\_rssi\_adc.c • pwm\_mux\_driver.c                 │
│    • cam\_dma.c • wifi\_sta.c • rtos\_task\_mgr.c          │
└────────────────────────────────────────────────────────────┘

Why this split?

• Application layer answers "What feature do I ship?"
• Domain layer answers "What maths / logic makes it correct?"
• Service layer answers "How do I talk to IO, network, storage?", using Port-and-Adapter (Hexagonal) pattern.
• HAL + RTOS hides silicon specifics, keeping everything above unit-testable on the host.

3.2 Core Design Patterns

3.3 RTOS Task Model (ESP-IDF v5 / FreeRTOS SMP)

Bench note: Added FPV tasks raise CPU utilisation to ≈ 51 %/core, still well within head-room.

3.4 File-Tree & Build Targets

firmware/
├── app/
│   ├── abs_controller.c
│   ├── failsafe_manager.c
│   ├── latency_profiler.c
│   └── fpv_osd_manager.c
├── domain/
│   ├── vehicle_state.c
│   ├── state_estimation.c
│   ├── control_law_pid.c
│   ├── pwm_shape_strategy.c
│   └── event_bus.c
├── services/
│   ├── state_provider/
│   ├── speed_commander/
│   ├── csv_logger.c
│   ├── mjpeg_streamer.c
│   └── osd_bridge/
│       ├── fpv_monitor.c
│       └── osd_bridge.c
├── drivers/
│   ├── imu_bmi270.c
│   ├── hall_driver.c
│   ├── esc_pwm_driver.c
│   ├── fpv_rssi_adc.c
│   └── pwm\_mux\_driver.c/.h        # GPIO toggle & self-test
├── platform/
│   ├── board_init.c
│   └── task_manager.c
├── test/                    # Unity + host_sim
└── tools/                   # log parser, CI

Build targets:

• idf.py build – full firmware
• idf.py build -DUNIT_TESTS=ON – on-target Unity harness
• make host_sim – desktop binary with SDL graphing, for CI
• idf.py size-components – memory budgeting gate

3.5 Configuration & Parameter Store

fpv:
  mode:      "analog"   # analog | wifi | off
  vtx_power: 25         # mW  (toggle 25/200 via push-button)
  osd:       true

abs:
  kp: 1.4
  ki: 0.3
  kd: 0.02

Compile-time pins via menuconfig; run-time tweaks via CLI (set fpv.mode wifi etc.) and persisted with Command + Memento.

3.6 Verification Hooks (Right Arm of the V)

3.7 ABS Subsystem — from Raw Sensors to Brake Torque

Everything below can be dropped in as one self-contained section; it replaces the terse "Quick Tour" with a fully annotated, reader-friendly module description.

3.7.1 Data flow at a glance

3.7.2 Two nested control loops

State transitions:

RUN ─► DECEL  (link lost OR driver pulls trigger)
DECEL ─► STOP (v_car < 0.3 m s⁻¹)
STOP ─► IDLE (brake_duty == 0 for 500 ms)
IDLE ─► RUN  (driver reapplies throttle)

3.7.3 ESC as an electronic brake

No caliper, no servo; the ESC does it all.

Firmware constants:

#define ESC_NEUTRAL_US 1500
#define ESC_BRAKE_MAX_US 1300   // never go lower

SpeedCommander linearly interpolates between those limits; the pwm_mux_driver toggles its GPIO at 2 kHz. If the MCU crashes, the RC filter on the mux select pin discharges in ≈ 25 ms and hardware flips back to the radio lane—meeting FR-1b even with dead firmware.

3.7.4 Calibration checklist

1. Set QuicRun to Forward/Brake (hold button 3 s, 1 LED flash).
2. Radio end-point calibration: full-throttle → full-brake → neutral.
3. Record neutral pulse with logic analyser → update ESC_NEUTRAL_US.
4. Road test: log μ_est, adjust PID.kp until damped (ζ ≈ 0.7).

3.7.5 Verification hooks

This richer ABS section now ties sensors, maths, hardware PWM and safety-mux into one coherent narrative—readers can replicate or audit every step.

3.8 The FPV Link: Seeing Through the Car's Eyes (and why it beats Wi-Fi in a race)

The WildFire Nano AIO module bundles sensor, NTSC encoder and 5.8 GHz VTx on one 4 g board. That saves you an extra ribbon cable and, more importantly, slices the latency pie:

Because the module is camera-internal, the ESP32 does nothing for the race-day video stream: zero CPU, zero DMA, zero risk. The ESP still provides a Wi-Fi MJPEG tap for pit-lane tuning; you simply choose which feed to watch.

Safety tie-in: fpv_monitor reads the WildFire RSSI pin through fpv_rssi_adc.c. If signal fades below -90 dBm for half a second the task raises EVENT_FPV_LOST, which the OSD blanks and the controller logs. The event can even trigger a gentle "pull over" profile if you like,just add a handler in FailsafeManager. Worst-case current draw at 200 mW is < 300 mA; a 470 µF low-ESR cap right at the VTx pins stops brown-outs when the power amplifier keys up.

So you get laboratory-friendly Wi-Fi plus race-worthy analogue,each with its own latency-budget test hook,without burdening the microcontroller or poking extra holes in the ABS loop.

4 End-to-End Traceability - Kitchen-Table Proof

5 Risks & Mitigations Snapshot

© 2025 Victor Retamal - Project Notes.