Detection of Obstacles from Moving Bike

A couple of years ago, while riding my bike home from work and in a moment of inattentiveness, I collided with the back of a parked, low slung trailer. It was not a particularly pleasant experience and inspired me to create an obstacle alert monitor that could be mounted on my handle bars and sound an alert when an object is approaching (from the vantage point of the camera). My research for a suitable platform led me to the openmv H7.
Here are the things that I think need to happen for each frame:

  • Identify any objects in the field of view and mark their location, size, and angle with regard to a cone spreading from the camera lens
  • Compare the objects from the current image with those from a previous and attempt to match them. If the objects are approaching, I would expect their proportions to change and internal angles to skew so I am not certain that rectangular detection would work best
  • If an object is approaching, sound an alert and/or flash a signal.

I have no previous experience with the H7 and have some questions:

  • What would be the best object detection method? I have been looking at Rectangular, Circular, and Blobs.
  • Can the IO pins source enough current to drive a speaker or piezo buzzer or would I need to add a buffer to drive them?
  • What would be the best method for matching objects detected from previous iterations?

Hi, actually, you should use the OAK-D from Luxonis for this. It was literally invented for the same problem.

Brandon, my friend, had the same problem and sought to fix it.

I was not aware of that product and it looks interesting. However, I was not able to find any spec regarding power requirements. I did see that it includes a heat sink so the power must be substantial. Combined with needing to use something like a raspberry pi zero or something like that, I worry that the power requirements would limit the operation time.
I definitely see the advantage in binocular vision and it also appears to be higher resolution than the default openmv camera.
All that said, I would still like to attempt my own project with the openmv if, for no other reason than the potential for learning.

1 Like

Okay, but, we really don’t have the features you kinda need for this. General purpose AI on detecting objects in an uncontrolled scene is not something we do well.

E.g. Rectangular, Circular, and Blobs will fail for these types of detection situations. Even if you were to do frame differencing it will just produce rather hard to parse output.

This is the final version of the Oak-D: OpenCV AI Kit : OAK—D– OpenCV.AI

That said, it’s going to draw more power and it also needs a host computer which will require even more power.

As for doing this with the OpenMV Cam… why not just use a lidar sensor with a long range? Like 10 meters plus? Several of these should do the job.

Trying to be more helpful here than selling you on hardware that can’t meet your requirement right now.


I meant to reply this weekend. Thanks for the recommendation, Kwabena! So the power of OAK-D about 5W max.

We also do have a variant of OAK-D that has a microcontroller built-in and also has a LiPo battery protection/charge/power circuit built in. Design files are here. So that can run completely standalone off its own managed battery, and has BlueTooth and WiFi for connectivity to a phone. We don’t sell that one (mainly because shipping batteries is hard), but we do sell a version without the battery circuit, which is otherwise the same, called LUX-EPS32.

So this similarly can be run standalone.

Thanks again, Kwabena. As always, a huge fan of OpenMV!

And agreed, for basic “don’t run into things”, a long-range lidar sensor would probably be the easiest. Oh and in case I don’t reply here (not sure if I’ve set up notification properly) feel free to ping me at support at luxonis dot com if you have any more questions on DepthAI stuff.


I realized that this is pertinent. A quick demo that noroc dot co put together using 2x OAK-D and a Pi.

Note that we accidentally plotted the wrong variables on the birds eye view. The up/down position of the car was plotted as the left/right. That’s why it’s so wrong and jumpy. The actual positions are more accurate than this.