Mission Goal
Build a recovery system that transitions from descent to a controlled glide. Your aim is to recover a payload with predictable landing location and gentle touchdown, demonstrating judgement, safety, and systems thinking.
Why it matters
High-end recovery is not just “slow down” — it’s “land where we intended.” Real missions use guided parafoils, gliders, and controlled descent to recover valuable payloads and avoid hazards. This level is about responsible decision-making and mission readiness.
Inputs from other teams
- Payload/Data team: payload mass, dimensions, and safe mounting limits
- Structures team: strong fuselage/payload bay design; wing reinforcement
- Navigation/Control team: optional: simple trim settings, balance checks, basic guidance ideas
- Mission Governance/Safety: hazard assessment and test boundaries
Design rules
- Judgement & responsibility: you must define safe test conditions and stop rules.
- Systems thinking: glider recovery affects other teams (payload, tracking, comms, safety).
- Evidence + reasoning: show not only results, but why your design decisions are defensible.
Shared Space.craft.ed challenge principles apply. :contentReference[oaicite:5]{index=5}
Build steps
- Choose glider architecture: simple foam/card glider, chuck glider base, or folded-wing design.
- Create a payload bay: mount payload securely; ensure it won’t shift (center of gravity must stay fixed).
- Set center of gravity (CG): start slightly forward for stability; mark CG position on fuselage.
- Wing build: reinforce with tape/spar; ensure left/right symmetry.
- Trim surfaces: small adjustable tabs (elevator/rudder) for fine tuning.
- Recovery transition plan: define how it “enters glide” (e.g., released nose-down then levels; or dropped flat with stable glide).
Test protocol
- Ground glide tests first: gentle hand-launch at walking speed (no throwing hard).
- Trim loop: one adjustment at a time; record each change and the effect.
- Drop tests: controlled low-height releases (0.5–1.0 m) to validate stability.
- Landing zone: define a target box (tape square) and measure landing error distance.
- Stop rules: if it dives dangerously, turns toward people, or breaks—stop and revise.
Success criteria
- Glider achieves stable glide (no repeated stalls or spiral dives) for multiple attempts.
- Landing is gentle enough to protect payload (your defined “no-damage” metric).
- Landing predictability: average landing error reduced over iterations (show improvement).
- Clear safety plan and evidence of responsible test boundaries.
Evidence checklist
- Build photos: glider top/side views + payload bay.
- CG mark location and explanation of why it’s there.
- Trim log: change → observed effect → decision.
- Landing scatter data: at least 5 landings with measured error distance.
- Short video of a stable glide and a controlled landing.
- One-page “mission readiness” summary: risks, mitigations, and next improvements.
Safety
- Test only in a controlled area with a clear landing zone.
- No launches toward people, windows, roads, or fragile equipment.
- Use lightweight materials; no sharp edges; tape corners.
- Stop immediately if flight becomes unpredictable or hazardous.
Common failure modes
- CG too far back: stalls and “porpoising” (up-down oscillation) then crash.
- Asymmetric wings: constant turn/spiral dive.
- Over-trimming: large tab bends cause instability rather than correction.
- Payload shift: CG changes mid-flight → unpredictable behaviour.
Stretch goals
- Design a simple “deployment container” so the glider is protected before release.
- Introduce a basic passive guidance idea (e.g., predictable left-turn pattern to stay within zone).
- Work with Comms/Tracking to add a visible marker or buzzer for easier recovery.
- Create a “handover checklist” so another team can operate your glider safely.
Scaffolding Example (optional)
You are allowed to reuse structures and formats from other teams — but not their decisions.
Structure: “Customer feedback loop”
- Collect feedback (1 question form)
- Pick top 1 improvement
- Implement + test
- Publish change log
Example feedback questions
- What was confusing? What would make this more useful? What should we stop doing?