Monocular classical-CV obstacle avoidance for slow corridor flight — architecture advice

I’m a 2nd-year university student working on an autonomous UAV project, and I’m currently unsure about the perception/navigation architecture. I’d like some guidance on whether the approach I’m considering is technically sensible

The problem statement requires the UAV to autonomously traverse a 3.5 m wide corridor containing static obstacles, which must be detected and avoided. The obstacle type, shape and colour are not specified, so I’m hesitant to rely on stock object-detection models or colour thresholds

The onboard compute is a Raspberry Pi, with a CUAV X7+ flight controller, monocular gimbal camera and forward-facing 1D rangefinder, so the perception approach also needs to be reasonably lightweight. I plan to lock the gimbal at around 35° and use IPM to get a more top-down view of the corridor floor and estimate where obstacles are relative to the drone.

My goal is not necessarily to identify what an obstacle is, but to determine whether some geometry occupies the UAV’s intended free flight space.

Planned pipeline:

  1. Camera preprocessing — calibrate/undistort the monocular camera and convert frames to grayscale.
  2. Feature tracking — detect features using something such as GFTT and track them across multiple frames using pyramidal Lucas–Kanade optical flow.
  3. Ego-motion estimation/compensation — use image motion together with UAV attitude/IMU information to account for camera motion. The camera/gimbal orientation would be fixed or otherwise known.
  4. Multi-frame geometry/parallax — use feature tracks over several frames to estimate relative depth or sparse 3D structure rather than relying purely on instantaneous optical-flow magnitude.
  5. Corridor/floor estimation — use geometric methods such as RANSAC plane estimation, vanishing-point/Hough-line cues and possibly IPM to estimate the expected floor and corridor structure.
  6. Obstacle detection — identify persistent geometry that deviates from the expected corridor/floor structure or appears significantly closer through motion parallax.
  7. Temporal confidence — accumulate evidence across multiple frames before marking a region as occupied, to reduce false positives and help when individual frame-to-frame motion is very small.
  8. Navigation — either use a simple reactive controller that maintains corridor centring while steering away from obstacles, or construct a small local occupancy grid, inflate obstacles by a safety margin and run A* with frequent replanning.
  9. Rangefinder safety layer — use the 1D rangefinder independently as a forward slow/stop/emergency-braking mechanism.

My main uncertainty is the perception stage. With a monocular camera, unknown obstacle appearance and relatively low forward speed, does corridor geometry + ego-motion-compensated multi-frame optical flow/parallax + temporal accumulation sound like a reasonable classical-CV approach?

I am particularly concerned about the low-speed case. Since the UAV moves slowly inside the corridor, consecutive frames may have very little translational displacement, giving weak optical flow/parallax relative to vibration, tracking error and noise. Would accumulating feature tracks over a longer temporal baseline be sufficient, or is there a more robust classical-CV approach for this situation?

I’d also appreciate advice on whether a reactive navigation approach is sufficient for a relatively constrained corridor, or whether building a local occupancy map + replanning would be worth the additional complexity.

This is a sensible decomposition, especially the decision to detect occupied flight space rather than object classes.

I would be careful, however, about making IPM the main geometric representation. IPM is strongest for points that actually lie on the assumed ground plane. An obstacle is precisely a violation of that assumption, so its warped position/shape should not be interpreted as reliable obstacle depth by itself.

For the low-speed case, I would think in terms of observability rather than frame count. Accumulating more frames helps only if the camera has accumulated enough useful translation relative to the scene. Ten nearly identical frames do not necessarily provide a better depth baseline than two frames with meaningful translation.

One useful architecture might therefore be:

tracked features → ego-rotation compensation → accumulated translation/baseline → geometric consistency with expected floor/corridor → persistent obstacle hypothesis

and only promote an obstacle when the geometry becomes sufficiently observable.

I would also explicitly track the confidence of that decision. For example, record:

  • accumulated camera translation since the track began
  • track length and reprojection residual
  • estimated parallax after rotation compensation
  • consistency with the floor model
  • number of independent frames supporting the obstacle hypothesis
  • age of the last reliable observation

Then the system can distinguish “free space observed” from “insufficient geometry to decide”. That distinction is important with monocular perception.

Your independent 1D rangefinder is valuable here. I would keep it outside the vision confidence chain as a simple safety constraint rather than using it to make weak monocular geometry appear more certain.

For navigation, I would initially avoid A* unless the corridor geometry actually requires planning around obstacles. A small local occupancy representation plus a conservative reactive policy may be much easier to validate on a Raspberry Pi. Mapping/replanning can be added once perception is demonstrably stable.

Before autonomous flight, I would also build a very small validation set: same obstacle at several distances, different textures/lighting, slow and faster translation, corridor edges, low-texture obstacle, and deliberately weak-parallax runs. Record not only detections but when the obstacle first becomes reliably observable.

That last measurement may tell you more about whether the architecture is viable than average detection accuracy.