VESPR: Bat-Inspired Perching Drone

A drone spends most of its energy just staying in the air. A drone that can perch like a bat can cut its motors and stay on station for hours, then fly to a new vantage point when it needs to. Our target application is wildfire overwatch. The drone is based at a fire tower and patrols a wider perimeter by moving between perches, which gives responders a camera they can reposition.

The hard part is seeing the branch. Leading bird-inspired perching research, such as the E-Flap ornithopter, located the branch with external motion capture instead of the vehicle's own sensors. Our project does that sensing onboard.

I lead the perception workstream on a multidisciplinary team. Teammates own guidance, the claw mechanism, and the airframe. My part covers everything from camera pixels to a 3D branch estimate the flight controller can act on:

• Characterizing the depth camera and calibrating it against the IMU
• Building a labeled branch dataset
• Detecting branches and estimating their 3D axis and diameter
• Deploying the pipeline on the flight computer within a latency budget
• Measuring accuracy against motion capture ground truth

An Intel RealSense D435i stereo depth camera feeds a Jetson Orin Nano. A detector finds the branch in the infrared image. I start with a classical line-detection baseline and then compare it against learned segmentation and keypoint models. The detected branch is converted to a 3D axis by fitting its principal direction and sampling depth robustly, because stereo depth is least reliable at the edges of thin objects. The pipeline also estimates diameter, since the claw can only grip branches under about 2 inches, and outputs a calibrated confidence. All of this is published to guidance as a single, well-defined pose message.

The depth camera can't see closer than about 20 cm, so the final contact phase uses a separate close-range sensor. Teammates are finalizing that design.

• Measure before optimizing. I set numeric accuracy targets before training any model. I'm validating the ground truth system before trusting it, and I keep a held-out evaluation set that is never used for tuning. The rule for choosing between detectors is committed to Git before any results exist.
• Interfaces first. The boundary between perception and guidance is a written spec covering coordinate frame, units, failure states, and how old a pose can be before it's discarded. A sign error in a coordinate frame produces output that looks plausible but points the wrong way, so we pin these down up front.
• Hardware-independent pipeline. The same code runs on the live camera, on recorded sensor logs, or on video. Most development happens at a desk on replayed data, and recorded clips double as regression tests.
• Latency, not just frame rate. At 1 m/s, a pose that's 400 ms old describes a branch that has moved 40 cm. I instrument latency per stage, from exposure to publish.

• Done: success criteria agreed with the team and advisor, a tested repository with dataset versioning, and the Jetson brought up with the D435i streaming depth, IR, and IMU.
• Next: sensor characterization, data capture, ground truth validation, and the classical baseline.
• Planned tools: Ultralytics YOLO, TensorRT, and ArduPilot SITL.