Mission Instrumentation

PI2 — High-Rate Flight Data Recorder (Level 2: Repeatability & Measurement)

Mission Goal

Build a flight-style data recorder that samples data at a defined rate, writes to a CSV log file, and produces repeatable runs with consistent filenames and headers.

Why This Matters

Professional missions rely on structured logs. Repeatability turns “cool demo” into “usable system.”

What Data You Collect

• Time (monotonic or timestamp)
• At least one sensor stream (e.g., IMU, temperature, pressure) OR CPU temp + system load if no sensors
• Run ID and sample index

Hardware / Software Needed

• Raspberry Pi + Raspberry Pi OS
• Python 3
• Optional IMU (accelerometer/gyro) for realistic “flight” data
• Storage space on SD card

Inputs From Other Teams

• Data: Approve CSV schema + file naming convention.
• Command & Control: Define “standard run” procedure (start/stop, duration).
• Risk & Safety: Identify safe handling if moving the device around.

What You Must Produce (Deliverables)

• A recorder script that logs to .csv with headers.
• Three runs using the same procedure, stored as separate files.
• A short note stating sampling rate achieved (target vs observed).

Step-by-Step Build

1. Choose a sampling rate (e.g., 10 Hz or 20 Hz).
2. Implement a run ID (timestamp-based) and filename pattern:
   • pi2_run_YYYYMMDD_HHMMSS.csv
3. Write CSV header row once at file start.
4. Log each sample with:
   • sample_index, time, sensor fields
5. Run for a fixed duration (e.g., 60 seconds), then stop cleanly and close file.
6. Repeat 3 times, keeping conditions similar.
7. Compute observed rate: samples recorded / seconds elapsed.

Data Format / Output

Recommended CSV columns:

• run_id,sample_i,t_s,temp_c,metric_1,metric_2

Analysis Ideas

• Check for missing samples (gaps in sample_i).
• Plot sensor data vs time and spot spikes.
• Compare three runs for consistency.

Success Criteria

• Three distinct log files with identical headers and schema.
• Sampling rate is stable and measured (not guessed).
• Team can explain what limits rate (I/O writes, sensor read time, Python overhead).

Evidence Checklist

• Directory listing showing three CSV files
• First 5 lines of each file (headers + samples)
• Sampling rate calculation note

Safety & Privacy

• Keep movement tests controlled; don’t swing devices on cables.
• No personal data in logs.
• Power safety and cable management.

Common Failure Modes

• Not closing the file → corrupted logs.
• Sampling “rate” drifts without measurement.
• CSV schema changes run-to-run.
• Too much printing to console slows logging.

Stretch Goals

• Use buffered writes (write every N samples) to reduce overhead.
• Add a “run metadata” JSON sidecar file.
• Add a simple on-screen status (samples recorded, seconds elapsed).