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

**URL:** <https://discuss.px4.io/t/monocular-classical-cv-obstacle-avoidance-for-slow-corridor-flight-architecture-advice/49522>\
**Category:** PX4 Autopilot\
**Created:** [September 20, 2026, 5:11am UTC](https://discuss.px4.io/t/monocular-classical-cv-obstacle-avoidance-for-slow-corridor-flight-architecture-advice/49522 "2026-09-20T05:11:00Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![KailashVS7](https://discuss.px4.io/user_avatar/discuss.px4.io/kailashvs7/32/22064_2.png) [@KailashVS7](https://discuss.px4.io/u/KailashVS7)\
**Post date:** [September 20, 2026, 5:11am UTC](https://discuss.px4.io/t/monocular-classical-cv-obstacle-avoidance-for-slow-corridor-flight-architecture-advice/49522/1 "2026-09-20T05:11:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![yigitcan-ozturk](https://discuss.px4.io/user_avatar/discuss.px4.io/yigitcan-ozturk/32/22039_2.png) [@yigitcan-ozturk](https://discuss.px4.io/u/yigitcan-ozturk)\
**Post date:** [October 3, 2026, 4:26pm UTC](https://discuss.px4.io/t/monocular-classical-cv-obstacle-avoidance-for-slow-corridor-flight-architecture-advice/49522/2 "2026-10-03T16:26:27Z")

</div>

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.