Autonomous Laser Guided Drone

Mission

The goal is to detect a known IR signature reflected off a target surface, confirm lock using time-based consistency checks, and then use a coarse-to-fine sensor layout to estimate direction and refine angle. A key requirement is observability. Every major decision in the autonomy flow should be visible in telemetry so I can debug quickly and explain behavior clearly during integration.

• Carrier frequency: 38 kHz, TSOP38238 compatible
• Control loop scaffold: 100 Hz
• Telemetry: 5 to 10 Hz over TCP to a lightweight web UI

Constraints

IR tracking is sensitive to conditions you cannot fully control. Ambient IR from sunlight can swamp receivers, reflections change with surface material and angle, and noise spikes can look like real targets if the logic is too eager. I designed the system around two constraints. First, the target signal must be recognizable, so the beacon is modulated at 38 kHz to match the TSOP38238 receiver carrier behavior. Second, lock must be earned over time, not triggered instantly, so detection uses thresholding plus a sliding window confirmation step before the system commits to a new state. These choices reduce false positives and make the behavior more repeatable during integration.

This project is currently at a verified-subsystems stage, with full end-to-end integration in progress.

Build

The system is split into a beacon side and a drone side. On the beacon side, a custom laser diode module is driven by an ESP32 using PWM so the emitted signal flashes at a controlled 38 kHz carrier. On the drone side, an ESP32 handles IR signal processing, lock confirmation, and tracking logic, while the flight controller is responsible for stabilization. The flight controller is an X12 5-in-1 AIO, providing IMU and barometer data through the existing flight stack. Altitude is managed using a time-of-flight sensor as the primary reference, with the barometer as backup. For integration and debugging, telemetry is streamed over TCP to a minimal web UI so internal state and sensor-derived values are visible in real time.

Beacon ESP32 PWM (38 kHz) → reflected IR → TSOP38238 array → lock + tracking on ESP32 → MSP over UART → flight stack → telemetry over TCP → web UI

Lock is treated as a confidence decision, not a single sensor event. The IR receivers are monitored continuously, then filtered to reduce noise and short spikes. A threshold identifies candidate detections, but lock is only declared after a sliding window confirms consistent signal presence across time. This prevents the system from reacting to brief reflections or ambient interference that happen to cross the threshold. Once the lock condition is met, the autonomy state machine can transition predictably, and if confidence drops later, the system can fall back without unstable oscillation between states.

Modulation at 38 kHz makes the target signature predictable, the sliding window makes the lock decision stable.

Direction estimation is done in two stages so the system can react quickly without sacrificing precision. For coarse tracking, two IR sensors on the rear and two on the front are placed in parallel with a fixed baseline. This provides a fast directional cue and helps establish which way the drone should orient. After the general target direction is known, fine tracking is handled by a front-facing module of three closely spaced sensors. Fine tracking compares relative signal strengths and uses the local intensity gradient to refine angle estimates. This approach avoids mechanical scanning and produces smoother heading corrections during alignment and early approach.

Coarse tracking gets you pointed the right way fast, fine tracking gives stable alignment without twitchy motion.

The control loop is designed to remain responsive while still allowing useful observability. The autonomy control scaffolding runs at 100 Hz to support timely adjustments and stable behavior during state transitions. Telemetry is intentionally slower, streamed at 5 to 10 Hz over TCP, which keeps the UI smooth without competing with the control loop. The telemetry view is meant to answer practical questions during integration, such as whether lock confidence is rising, whether the angle estimate is converging, and whether altitude sensing is stable under movement.

• Mode and state: search, lock confirm, align, approach, fallback
• Lock confidence and per-sensor signal levels
• Angle estimate and heading correction
• Altitude from ToF and barometer fallback indicator
• Update rates for loop and telemetry

Validation

Bench verified, integration in progress

I validate subsystems independently with measurable checks before combining them into end-to-end behavior. This keeps integration predictable and makes failures easier to isolate. Current validation focuses on signal detectability, lock stability, tracking consistency, loop timing, and telemetry reliability. Full controlled flight behavior is being built by composing these verified parts into a single state machine with clear fallback rules.

Works best indoors or in low-glare conditions where sunlight and strong heat sources do not saturate IR.

Validated subsystems

• 38 kHz beacon modulation on ESP32 PWM
• IR detection + lock confirmation (threshold + sliding window)
• Coarse direction estimate (front/rear pairs)
• Fine tracking angle refinement (3-sensor front module)
• Altitude sensing (ToF primary, barometer fallback)
• Telemetry streaming over TCP to web UI (5 to 10 Hz)

Next integration steps

• Tie approach speed to lock confidence and add conservative abort thresholds.
• Improve resilience under higher ambient IR.
• Add replayable logging for post-test debugging.

Contact

If you are hiring for robotics, embedded, or autonomy roles, I would love to chat. This project reflects how I work. I prefer systems that are measurable, debuggable, and designed around clear state behavior rather than one-off demos. I can walk through the architecture, the signal processing choices, and how I validated each subsystem during integration.