Design Choices & Architectural Decisions

1.1 Two-Drone Cooperative Architecture

Decision

Implement a cooperative system with two drones having distinct, specialized roles rather than a single multi-purpose drone or multiple identical drones.

Rationale

• Complementary Capabilities: AR Drone excels at stable hovering and ArUco detection, while Tello Drone has better computational resources for YOLOv8
• Altitude Separation: High-altitude scouting provides global view while low-altitude navigation handles detailed obstacle avoidance
• Risk Mitigation: Helper drone scouts ahead, reducing collision risk for payload-carrying parent drone
• Resource Constraints: Hardware limitations prevented both capabilities on a single platform

Trade-offs

• Pros: Specialized hardware optimization, parallel operations, fault tolerance
• Cons: Inter-drone communication complexity, synchronization challenges, higher total cost

Alternatives Considered

• Single Drone: Rejected due to insufficient computational resources and camera limitations
• Swarm Architecture: Rejected due to coordination complexity beyond project scope

1.2 Layered Architecture Pattern

Decision

Organize system into five distinct layers: Hardware → Perception → Planning → Control → Communication

Rationale

• Separation of Concerns: Each layer has clear responsibilities and interfaces
• Modularity: Components can be developed, tested, and debugged independently
• Maintainability: Changes in one layer minimally impact others
• Academic Best Practices: Follows standard robotics architecture patterns (perception-planning-action)

Trade-offs

• Pros: Clean code organization, easier debugging, team parallel development
• Cons: Layer boundaries introduce latency, potential over-engineering for small project

2.1 YOLOv8-nano for Object Detection

Decision

Use YOLOv8-nano model (3.2M parameters) for real-time obstacle detection on Tello Drone.

Rationale

• Performance: Achieves 10-15 FPS on Tello's limited hardware (vs. 2-3 FPS for larger models)
• Accuracy: 89.7% mAP on COCO dataset sufficient for obstacle classes (person, chair, table, etc.)
• Size: 6MB model fits in memory constraints
• Latency: ~70ms inference time enables reactive avoidance

Trade-offs

• Pros: Real-time performance, low memory footprint, adequate accuracy
• Cons: Lower accuracy than YOLOv8-large (89.7% vs. 95.2% mAP), fewer fine-grained detections

Alternatives Considered

• YOLOv8-small/medium: Rejected due to frame rate dropping below 10 FPS (unsafe for reactive avoidance)
• MobileNet-SSD: Rejected due to lower accuracy (78% mAP) despite faster inference
• Classical CV (HOG+SVM): Rejected due to poor generalization to diverse obstacle types

2.2 ArUco Markers vs. Alternative Localization

Decision

Use ArUco marker detection (OpenCV DICT_4X4_50) for AR Drone localization instead of GPS or SLAM.

Rationale

• Precision: ±2cm accuracy at 1m distance (vs. ±5m for GPS)
• Indoor Use: Works in GPS-denied environments (lab, disaster zones)
• Computational Efficiency: Low processing overhead compared to SLAM
• Setup Simplicity: Markers easy to deploy in target zone
• Proven Reliability: Well-tested OpenCV implementation

Trade-offs

• Pros: High accuracy, low latency, works indoors, minimal compute
• Cons: Requires pre-placed markers, limited to marked areas, line-of-sight dependency

Alternatives Considered

• GPS: Rejected due to poor indoor performance and insufficient precision (±5m)
• Visual SLAM (ORB-SLAM): Rejected due to high computational cost and drift accumulation
• AprilTag: Rejected in favor of ArUco due to better OpenCV integration

2.3 Pinhole Camera Distance Estimation

Decision

Use monocular pinhole camera model $d = \frac{H \times f}{h}$ for distance estimation rather than stereo vision or depth sensors.

Rationale

• Hardware Constraints: Tello has single camera (no stereo pair or depth sensor)
• Sufficient Accuracy: ±20% error at 5m acceptable for threat assessment
• Simplicity: Single calibration parameter (focal length) vs. complex stereo calibration
• Real-time Performance: Trivial computation cost

Trade-offs

• Pros: Works with existing hardware, fast, simple implementation
• Cons: Requires known object heights, ±20% error, struggles with unknown objects

Alternatives Considered

• Stereo Vision: Rejected due to lack of dual cameras on Tello
• LiDAR: Rejected due to payload weight and cost constraints
• DepthAnythingV2 (Monocular Depth ML): Rejected due to computational overhead (1-2 FPS)

3.1 Hybrid Path Planning: Linear Interpolation + Bresenham

Decision

Combine linear interpolation for initial path generation with Bresenham's algorithm for discrete waypoint computation, plus reactive replanning on obstacle detection.

Rationale

• Efficiency: Linear interpolation is O(1) for direct paths
• Precision: Bresenham provides discrete grid waypoints for movement commands
• Reactivity: Replanning triggered by YOLOv8 detections enables dynamic avoidance
• Simplicity: No complex map-building or A* search needed for open environments

Trade-offs

• Pros: Fast computation, works for open spaces, reactive to obstacles
• Cons: Suboptimal in cluttered environments, no global path optimization

Alternatives Considered

• A* Search: Rejected due to requiring pre-built map (unavailable in dynamic environments)
• RRT/RRT*: Rejected due to computational overhead and overkill for simple scenarios
• Pure Reactive (no planning): Rejected due to risk of local minima and inefficient paths

3.2 Grid Search Pattern for AR Drone

Decision

Use snake/boustrophedon pattern on 5×5 grid (0.5m cells) for systematic area coverage.

Rationale

• Coverage Guarantee: Ensures all cells visited exactly once
• Predictability: Deterministic pattern aids debugging
• Efficiency: Minimizes backtracking compared to random walk
• State Tracking: Simple state machine (unexplored → exploring → explored → target found)

Trade-offs

• Pros: Complete coverage, simple implementation, predictable
• Cons: Not optimal if target location has prior probability distribution

Alternatives Considered

• Spiral Pattern: Rejected due to complexity in rectangular grids
• Random Walk: Rejected due to non-guaranteed coverage
• Probabilistic Search: Rejected due to lack of prior target information

3.3 Three-Level Threat Assessment

Decision

Classify obstacles as HIGH (<1.5m, center), MEDIUM (1.5-2.5m), LOW (>2.5m or peripheral) based on distance and position.

Rationale

• Safety Margin: 1.5m threshold provides reaction time at typical drone speed (0.5 m/s)
• Position Awareness: Center obstacles more dangerous than peripheral ones
• Decision Simplicity: Three levels balance granularity with implementation complexity
• Empirical Validation: Thresholds tuned through flight testing

Trade-offs

• Pros: Clear decision boundaries, accounts for position, safe margins
• Cons: Discrete levels may cause abrupt behavior changes at boundaries

Alternatives Considered

• Binary (avoid/ignore): Rejected due to insufficient granularity
• Continuous threat function: Rejected due to added complexity for marginal benefit
• Five-level system: Rejected due to over-engineering

4.1 PID Controller for Precision Landing

Decision

Implement discrete-time PID controller with anti-windup (Kp=1.0, Ki=0.1, Kd=0.3) for final landing correction.

Rationale

• Proven Method: PID is industry standard for UAV position control
• Handles Drift: Integral term corrects accumulated dead reckoning errors
• Fast Convergence: Achieves ±10cm accuracy in 2-3 iterations
• Tunable: Gains adjusted empirically during flight tests

Trade-offs

• Pros: Well-understood, robust to disturbances, fast convergence
• Cons: Requires manual tuning, potential overshoot if poorly tuned

Alternatives Considered

• Pure Proportional Control: Rejected due to steady-state error
• Model Predictive Control (MPC): Rejected due to computational overhead and complexity
• LQR: Rejected due to difficulty modeling drone dynamics accurately

4.2 Balanced Obstacle Dodge Maneuvers

Decision

Design lateral (80cm side → forward → 80cm back) and vertical (60cm up → forward → 60cm down) maneuvers with net displacement = 0cm.

Rationale

• Target Preservation: Balanced maneuvers ensure drone returns to original trajectory
• Error Minimization: Eliminates cumulative drift from repeated dodges
• Simplicity: Fixed maneuver distances avoid complex path recalculation
• Predictability: Deterministic behavior aids debugging and safety

Trade-offs

• Pros: Mathematically guaranteed endpoint, simple implementation, no drift
• Cons: Fixed distances may be suboptimal for some obstacles, increased flight time

Alternatives Considered

• Adaptive Dodge Distance: Rejected due to difficulty ensuring balanced return
• Continuous Trajectory Adjustment: Rejected due to complexity
• Replanning After Each Dodge: Considered but used as complement (reactive replanning)

4.3 Dead Reckoning Position Estimation

Decision

Estimate position by integrating velocity commands with IMU yaw: $x' = x + v \cdot \cos(\psi) \cdot \Delta t$

Rationale

• No External Sensors: Works without GPS or external localization
• Minimal Latency: Instant updates from onboard IMU
• Acceptable Error: ±10-30cm per 3m sufficient when combined with PID correction
• Simple Implementation: Basic numerical integration

Trade-offs

• Pros: No external dependencies, fast, simple
• Cons: Drift accumulation, sensitive to wind, requires PID correction

Alternatives Considered

• Visual Odometry: Rejected due to computational cost and feature-poor environments
• Sensor Fusion (Kalman Filter): Rejected due to lack of additional sensors to fuse
• Pure IMU Integration: Rejected due to severe drift (tested: ±1m per 3m)

5.1 Transform Data Communication Protocol

Decision

AR Drone transmits target coordinates (x, y) to Tello Drone after ArUco marker localization completes.

Rationale

• Simplicity: One-way communication sufficient for scout → parent handoff
• Decoupling: Drones operate independently until handoff point
• Reliability: Single message reduces communication failure points

Trade-offs

• Pros: Simple protocol, minimal network overhead, clear handoff point
• Cons: No real-time updates if target moves, no feedback loop

Alternatives Considered

• Continuous Streaming: Rejected due to network overhead and unnecessary for static targets
• Bidirectional Communication: Rejected as Tello has no useful data to send back to AR Drone

5.2 Dual Camera Intermittent Switching (AR Drone)

Decision

Switch between bottom camera (ArUco) and front camera (obstacles) every 2 seconds rather than using both simultaneously.

Rationale

• Hardware Limitation: AR Drone SDK only supports single camera stream
• Priority: ArUco detection more critical (bottom camera gets more time)
• Safety: 2-second interval provides sufficient obstacle monitoring

Trade-offs

• Pros: Works within hardware constraints, balances both needs
• Cons: Blind spots during camera switches, potential missed obstacles

Alternatives Considered

• Bottom Camera Only: Rejected due to inability to detect forward obstacles
• Front Camera Only: Rejected as ArUco localization requires bottom camera
• Hardware Modification (Dual Streams): Rejected due to SDK limitations

6.1 Python Implementation

Decision

Implement entire system in Python using pyardrone, djitellopy, OpenCV, and Ultralytics libraries.

Rationale

• Library Ecosystem: Mature libraries for CV (OpenCV), ML (Ultralytics), and drone control
• Development Speed: Rapid prototyping for course project timeline
• Team Familiarity: All team members proficient in Python
• Cross-Platform: Works on both Mac and Windows development machines

Trade-offs

• Pros: Fast development, excellent libraries, readable code
• Cons: Slower than C++ (but sufficient for 10-15 FPS requirement)

Alternatives Considered

• C++: Rejected due to longer development time and complexity
• ROS (Robot Operating System): Rejected as overkill for two-drone system

6.2 Modular Code Organization

Decision

Organize code into separate directories: Tello/, AR Drone/, with subdirectories for perception, planning, control, and utilities.

Rationale

• Parallel Development: Team members work on different modules simultaneously
• Reusability: Shared utilities (e.g., coordinate transforms) used by both drones
• Testability: Each module tested independently
• Maintainability: Clear file organization aids debugging

Trade-offs

• Pros: Clean structure, parallel work, easy testing
• Cons: Some code duplication between drones