Mission Instrumentation

MB5 — Recovery Performance Instrument (Level 5: Judgement & Responsibility)

Mission Goal

Design an instrumentation plan for a “recovery” scenario (landing, retrieval, rescue, or post-mission inspection). You must handle ambiguity, define what “safe recovery” means, and justify your decisions.

Why This Matters

In professional missions, recovery and post-event analysis are where responsibility shows up: safety, evidence, chain-of-custody, and honest reporting. Level 5 is about judgement under imperfect conditions.

What Data You Collect

• Impact detection (acceleration spikes)
• Orientation change (tilt)
• Environmental conditions during recovery (temp/light)
• Recovery timeline markers (button-press events)
• Integrity flags (e.g., “sensor saturated”, “battery low”)

Hardware / Software Needed

• 1–2 × micro:bit (payload + optional “recovery operator” receiver)
• MakeCode / MicroPython
• Optional: buzzer or LED indicator (if available) for “recover me” mode
• Optional: radio relay from MB4 design

Inputs From Other Teams

• Command & Control: Define recovery protocol (who decides stop/go, what’s acceptable risk).
• Risk & Safety: Identify hazards (drops, cables, crowding) and mitigation steps.
• Data: Define evidence integrity: timestamps, run IDs, and how logs are stored without editing.
• Comms: Define “lost payload” mode (beacon + last known status).

What You Must Produce (Deliverables)

• A written Recovery Instrumentation Plan (what you measure + why).
• A working instrument program that captures recovery-critical events.
• A short incident-style report from a test run, including uncertainty and limitations.

Step-by-Step Build

1. Define a recovery scenario (choose one):
   • “Payload dropped from 1m onto padded surface; measure impact and orientation change.”
   • “Payload moved through a course; detect rough handling and ‘safe transport’ compliance.”
2. Define “safe recovery” metrics (thresholds and reasoning).
3. Implement event logging:
   • Impact event when magnitude exceeds threshold
   • Tilt event when angle changes beyond threshold
   • Operator markers via button A/B
4. Implement integrity flags (battery low, sensor saturation).
5. Run a controlled recovery test and log results.
6. Write a recovery report:
   • What happened (based on data)
   • What you cannot be sure about
   • What you would change next time

Data Format / Output

• run_id,t_ms,event,ax,ay,az,mag,temp_c,light,flags
• Events: IMPACT, TILT, MARK_A, MARK_B, STATUS

Analysis Ideas

• Count impacts and compare against “safe” thresholds.
• Plot orientation change timeline during transport.
• Decide if the payload should be “cleared” or “quarantined” based on data quality flags.

Success Criteria

• Team defines recovery success in measurable terms.
• Instrumentation captures events clearly and consistently.
• Report demonstrates professional judgement: honest limits, safety awareness, and evidence integrity.

Evidence Checklist

• Recovery Instrumentation Plan (1 page)
• Log file / serial output screenshot from test
• Short recovery report (what happened + what you’d improve)
• Photo of test scenario + safety setup

Safety & Privacy

• Use padded drop zones and controlled movement; no throwing.
• Keep walkways clear; assign a spotter if moving around.
• No filming faces; if recording evidence, focus on device + hands only.

Common Failure Modes

• No clear definition of “safe recovery” → data has no decision value.
• Thresholds chosen without justification.
• Logs edited after the fact (breaks evidence integrity).
• Over-claiming certainty from limited sensors.

Stretch Goals

• Add “lost mode”: loud/bright beacon + last status packet.
• Create a decision tree: “If IMPACT > X then quarantine.”
• Design a handover checklist (operator A to operator B) with data continuity.