Python-powered machine vision modules

Similar projects worth following
The OpenMV project aims at making machine vision more accessible to beginners by developing a user-friendly, open-source, low-cost machine vision platform.

OpenMV cameras are programmable in Python3 and come with an extensive set of image processing functions such as face detection, keypoints descriptors, color tracking, QR and Bar codes decoding, AprilTags, GIF and MJPEG recording and more.

Additionally, OpenMV includes a cross-platform IDE (based on Qt Creator) designed specifically to support programmable cameras. The IDE allows viewing the camera's frame buffer, accessing sensor controls, uploading scripts to the camera via serial over USB (or WiFi/BLE if available) and includes a set of image processing tools to generate tags, thresholds, keypoints etc...

The OpenMV project is a THP semifinalist and was successfully funded via Kickstarter back in 2015 and has come a long way since then.


  • Scriptable in Python3.
  • On board uSD Card or internal Flash storage for scripts, images and video.
  • RGB, YUV and JPEG Omnivision sensors (OV2640 and OV7725).
  • Recording and Streaming GIF and MJPEG to SD or external WiFi shield.
  • Extension Header breaks out UART, I2C, SPI, PWM, DAC and ADC.
  • User-friendly Python IDE to view the framebuffer and upload scripts to the camera.
  • 16MB SDRAM on-board enables uClinux to run on OpenMV2.
  • Image processing library includes:
    • Line, circle, rectangle detection.
    • Face detection with VJ (compatible with OpenCV's cascades)
    • ORB keypoints detector, descriptor, matching and tracking.
    • QR and Bar codes decoding and AprilTags support.
    • Template matching with Normalized Cross Correlation (NCC) 
    • Misc functions: kmeans, filters, scaling, sub-image, blitting and alpha blending.

The Hardware:

  • Processor: Based on STM32F ARM Cortex-M Digital Signal Controllers (DSCs) running at 168-216MHz. Features a single precision FPU, DSP instructions and a DCMI (Digital Camera Interface). The low-cost, the HW camera interface and the FPU and DSP made this particular controller a perfect match for the project.
  • Image Sensor: OpenMV1 supports many single package lens/sensors, such as the OV965x and OV2640 while OpenMV2 and OpenMV3 support a single sensor with an external lens.
  • PCB: Although it costs more, a 4-layer PCB is used for all cameras for better signal integrity and EMI issues. Additionally, using 4-layers made it possible to fit everything on the 1.0x1.3 inches OpenMV1 board. The first PCB prototypes were all ordered from OSHPark.
  • Debugging and Flashing Firmware: The Serial Wire Debugging (SWD) is broken out on all cameras for debugging with GDB and the DFU is easily accessible to upload new firmware images via USB. Additionally, the camera includes a bootloader that can be used from the IDE to easily upload new firmware images.
  • I/O Headers and Shields: The main 2.54mm headers break out SPI, I2C, USART, PWM, CAN, DAC and ADC. These headers allow interfacing extension boards (or Shields) to OpenMV to extend its capabilities.  For example, using SPI LCD with OpenMV camera to view the framebuffer:

  • The WiFi Shield:  Using the WiFi Shield gives OpenMV the ability to connect to the internet. It features an ATWINC1500 FCC Certified WiFi module which can transmit data at up to 48Mbps making it perfect for streaming video:

The Software:

OpenMV uses a lot of cool open-source software including MicroPython, ChaN's FatFS, ARM's DSP/Math libraries etc.. And it's completely programmable in Python 3! OpenMV can run Python scripts that have access to peripherals (SPI/I2C/UART, CAN, PWM, ADC and DAC), uSD filesystem, wireless, and the image processing library.

The IDE:

OpenMV includes a cross-platform IDE (based on Qt Creator) designed specifically to support programmable cameras. The IDE allows viewing the camera's frame buffer, accessing sensor controls, uploading scripts to the camera via serial over USB (or WiFi/BLE if available) and includes a set of image processing tools to generate tags, thresholds, keypoints etc..

OpenMV 1, 2 and 3:

The OpenMV1 was based on STM32F4 running at 168MHz with very small RAM and Flash. The main advantage of OpenMV1 was small form factor (1.0" x 1.3").  OpenMV2 used the newer STM32F429 runing at 180MHz, with more built-in SRAM, external 16MB SDRAM, external lens for the sensor, 2xIR LEDs, 2xServo headers and 20 I/Os. Finally, OpenMV3 uses the latest Cortex-M7 and is currently in production (see full specs below).

OpenMV1 Specs:

  • MCU (STM32F407): 168MHz, FPU, DSP, DCMI.
  • RAM: 512KB SRAM Flash: 512KBs
  • Image Sensor(s): OV965x (1.3MP) and OV2640 (2MP/JPEG)
  • I/O: USART, SPI, I2C and PWM.
  • USB: 2.0 FS.
  • SD Card: SPI.
  • Power Consumption: 120mA typical.
  • Dimensions: 1.0" x 1.3"


Read more »

  • 1 × STM32F4xx MCU ARM Cortex-M4 FPU DSP 168/180MHz
  • 1 × OV2640 CMOS 2MP/RGB/YUV/JPEG
  • 1 × 24LC128 I2C EEPROM 128KBIT 400KHZ 8MSOP
  • 1 × CRYSTAL 12MHz 12PF SMD 2.5x2.0
  • 1 × ADP222ACPZ PM/REG LDO 3.3v/2.5V 16LFCSP

View all 10 components

  • Introducing the New OpenMV-H7

    i.abdalkader09/21/2018 at 01:38 0 comments

    Hey everyone, I would like to introduce you to our next generation cameras, the OpenMV-H7. First, apologies are due for not updating this project more frequently, but it's been really hard keeping track of everything from the website to forums and emails, while keeping the software/firmware releases on schedule.  Anyway, the new OpenMV-H7 is our latest and greatest camera, designed to support prototyping multiple sensors, including the OV7725, MT9V03x Global shutter sensor and the FLIR 1, 2 and 3 thermal sensors! 

    Additionally, we're using a better uSD card socket, a high efficiency switching regulator (up to 1A), a low noise LDO for sensor analog supply and we've added a LiPo battery connector on board. The new OpenMV-H7 is still backward compatible with all the shields designed for OpenMV-F4 and OpenMV-F7. Software-wise, we now have neural network support, WiFi programming support, generally more stable firmware/software and a new UVC (webcam) firmware is coming soon.

    The new OpenMV-H7 will be release in March, if you'd like to support OpenMV and pre-order the new OpenMV-H7 please back our Kickstarter:

  • OpenMV Kickstarter

    i.abdalkader01/26/2015 at 17:54 4 comments

    The OpenMV Kickstarter is finally live! Check it out

  • OpenMV1 Prototypes

    i.abdalkader09/16/2014 at 22:18 0 comments

    We're making a small batch of OpenMV1 prototypes for beta testing, if anyone's interested, they're available now for preorder on Tindie:

    We're only making a few of them (10-30) so the costs are higher, hopefully there will be a bigger run in the future.

  • OpenMV on Quadcopter

    i.abdalkader09/13/2014 at 15:11 4 comments

    Just got my hands on a small quad, I was think this would be the perfect application for a tiny camera like OpenMV, now all I need is an open place to record some videos from the quad :)

  • FAST/FREAK Keypoint Detection

    i.abdalkader09/11/2014 at 12:40 3 comments

    Feature/Keypoints detection is a very interesting and useful tool to have around when doing image processing,  it has endless applications from tracking objects, matching and searching images to more advanced stuff...So far I've been using SURF for this, but other than being complicated and very resource consuming, the algorithm itself is patented in the US and cannot be used for commercial stuff without a license, in addition to that, the only implementation I could find (libopensurf) is GPL'd..

    So I removed all SURF code from the repo and I'm using this relatively new super fast/lightweight algorithm, called FREAK....Note that FREAK is a keypoint descriptor, so it needs something to find keypoints first, for this I'm using a corner detection algorithm called FAST.

    To give you an idea of what you can do with this FAST/FREAK detector, I made this short video:

  • Blob Detection Revised

    i.abdalkader09/06/2014 at 00:37 0 comments

    Made some improvements to the blob detection code, it now assigns unique IDs/Labels to every detected color, based on its index, so you can identify detected blobs with their IDs. It's also faster, and uses memory much more efficiently... Here's a short video of the result:

  • Thermal Imaging/Night Vision

    i.abdalkader08/28/2014 at 00:00 5 comments

    So it seems like there are a few thermal imagers out there that made it through, so for the sake of completeness (and to eliminate the competition :D) I finished up my thermal imaging code...Here's a short video showing thermal/night vision:

    To produce the final image, temperature readings are normalized, then converted to a rainbow (using a lookup table) and then scaled up (using bilinear interpolation) and finally, the thermal image is alpha blended into an RGB image and sent to the LCD...The result looks something like this:

  • OpenMV2 Thermal, LCD and WiFi Shields

    i.abdalkader08/16/2014 at 10:03 0 comments

    So I've been quite busy making some new shields for OMV2, I have not tested everything yet, but it's looking good, so far I made a CC3000, LCD and thermal IR sensor (MLX90620) shields :

    Shields that are small enough, or that have anything to do with imaging (like the thermal shield), are designed to be installed on the front side of the camera, others, like the LCD or battery pack are designed as backpacks. 

    A few of the shields are designed to work together, like the thermal and LCD shields, so it's possible for example, to connect the LCD and have a portable thermo cam:

    Now with the HW out of the way, moving on to more glorious conquests...

  • Running uClinux on OpenMV2

    i.abdalkader08/06/2014 at 19:01 0 comments

    One of the perks of having an SDRAM on board is being able to run full fledged OSes, like uClinux, which require at least a few MBs of RAM to work...uClinux, if you're not familiar with it, is an MMU-less variant of Linux, which means it can run on low-end micros, like the STM32, that don't have an MMU.

    Original support of the STM32 micros has been added by emcraft, and a few contributors on ST forums, the kernel is configured to XIP (execute in place) so it's not relocated to SDRAM and runs directly from flash (the 2MBs of flash hosts the u-boot bootloader, kernel image and the romfs) access to the on-chip flash is pretty fast, it takes, in theory, 0-wait states.

    So with that as my starting point, I made a few changes to u-boot and the kernel, enabled SDIO, and few other interfaces, to make things work on OMV2, I also made a few tweaks to fbtft and built it in the kernel, and here's the result :)

    It takes less than 1 sec to boot, I think that's awesome.. anyway, the LCD is a JD-T1800, I designed this shield for OMV2, it has a light sensor on board which you can read to control the LCD brightness and a few passives...(I'm still waiting for stackable headers, so had to solder the wires to the board):

    I'll keep playing with that for a while, see what more I can do, next, I will probably try to get the DCMI and USB working and maybe I will try to run OpenCV :)...

  • Night Vision, SDIO/SDRAM and Focal Length

    i.abdalkader07/22/2014 at 08:34 0 comments

    So I've been doing some testing with the new OpenMV, I'm very satisfied with the results so far, after replacing the broken sensor, I couldn't wait to test the IR LEDs/Lens, here's a snapshot taken in complete darkness:

    Next, I messed around with the lens trying to see how close I can get to objects (varying the focal length), here's a couple of shots of 402's a few mm from the lens:

    This one is taken under IR:

    With the optics out of the way, I moved on to testing the SDIO/SDRAM.. Unlike OpenMV1, OMV2 uses a 4-bit SDIO running at 48MHz, to interface the uSD, it's pretty fast, I did some testing by recording a video, reading/writing files etc...

    Finally, the SDRAM, fixed the linker script to map the new memory, did some simple tests, writing/reading values, poking with gdb, seems to be working fine, but just to be sure, I'm going to write/find a proper SDRAM test and run it before relocating stuff to SDRAM.

View all 19 project logs

Enjoy this project?



N. Christopher Perry wrote 07/19/2019 at 03:42 point

Take a look at what I did with my M7:

Can't wait to start playing with my new H7!

  Are you sure? yes | no

MANASH PRATIM KAKATI wrote 11/11/2018 at 06:10 point

Can you provide me the code for  the live streaming? and which application would be better to view the live video?

  Are you sure? yes | no

Bruce wrote 05/07/2018 at 12:14 point

Hi, is this device used to count people?

  Are you sure? yes | no


[this comment has been deleted]

Kwabena W. Agyeman wrote 10/08/2017 at 20:52 point

We do that if the algorithm is hard to write. Like for FFT support for optical flow. That was debugged on a PC.

Lot's of extra memory and speed of a processor aren't really useful however if you need to run the algorithm on low end hardware. Having a PC is mainly nice for debugging since you can compile/update faster.

  Are you sure? yes | no

Ember Leona wrote 03/31/2017 at 23:03 point

wwhich is easier for your robot to attempt autonomous Object Recogition or stream video to a few desktops for processing. I would limit my bots to basic sensory communication and movement then they can be upgraded with render farms and futuretech (ps I like FutureTech VideoJockey stuff)

  Are you sure? yes | no

deʃhipu wrote 03/31/2017 at 23:46 point

It really depends on where you are deploying the robot and how (un)reliable its communications are there. And of course also on how much lag you can tolerate -- a fast line-follower robot will go off-road fast if you try to control it from a remote server. Also, communication is forbidden on most tournaments.

  Are you sure? yes | no

i.abdalkader wrote 04/01/2017 at 00:11 point

You're really talking basics here, processing have been moving away to edge computing for a very long time now. There are many good reasons to do so, like avoiding single points of failure, saving communications power or not having or wanting any communications at all (think distributed tracking and security applications and military applications) . Additionally, it's more practical and more cost-effective to make a 1000 smart robot/drone (even if they're not very smart) than make something that can process a 1000 video streams, make decisions and then send them back all in real-time, at least some minimal amount of local pre-processing on the videos is needed for this to have a chance of working.

  Are you sure? yes | no

Nathaniel wrote 03/29/2017 at 08:44 point

This is really awesome, nice work. 

  Are you sure? yes | no

chansdad wrote 03/25/2017 at 04:28 point

Can we use this as a people counter ? I have seen some python + Raspi based openCV based people counters ..

  Are you sure? yes | no

i.abdalkader wrote 04/01/2017 at 00:13 point

All the stuff needed is there, it's just not implemented yet.

  Are you sure? yes | no

deʃhipu wrote 02/14/2017 at 22:30 point

I wonder why you are not posting any updates here anymore. The project made a huge progress since the kickstarter, it would be nice if the readers of could learn about it too!

  Are you sure? yes | no

i.abdalkader wrote 02/22/2017 at 19:18 point

You're right I should post a few updates here too, just too busy right now with the new cam and other stuff, will get around to it soon.

  Are you sure? yes | no

EngineerAllen wrote 02/08/2017 at 11:03 point

i like the uquadcopter

can you run state estimation from an inertial measurement unit + brushed motor drivers (PWM) + openCV all on the MCU this board comes with fast enough?

  Are you sure? yes | no

deʃhipu wrote 02/08/2017 at 16:48 point

This board doesn't run OpenCV.

  Are you sure? yes | no

EngineerAllen wrote 02/16/2017 at 11:23 point

OpenMV .. same thing

  Are you sure? yes | no

deʃhipu wrote 02/16/2017 at 11:59 point

OpenCV is a library for doing vision processing algorithms.

OpenMV is a development board running MicroPython.

Hardly same thing.

  Are you sure? yes | no

Ryan Bailey wrote 02/03/2017 at 17:18 point

Great project - really enjoyed following it over time. 

Question re: the OV2640. From my experiments with this sensor, it looks like the UXGA and SVGA register settings disable VSYNC - I assume because it's not needed for JPEG capture. My application uses VSYNC to define the beginning/end of the frame in uncompressed mode (JPEG off). Any suggestions on turning it back on? My guess so far is that it's buried somewhere in the reserved/magic registers.

  Are you sure? yes | no

i.abdalkader wrote 02/04/2017 at 01:00 point

VSYNC is always needed, It's actually HSYNC that gets ignored for JPEG (HSYNC is actually not needed at all, I modified the HAL drivers to disable DCMI_LINE_IT and save the interrupts overhead). Anyway I think the sensor might be misconfigured and just stops working, checkout my driver see if you're missing something.

  Are you sure? yes | no

Ryan Bailey wrote 02/04/2017 at 20:25 point

You're right - I had those backwards. I'll take another look at your drivers. Thanks!

  Are you sure? yes | no

bill0 wrote 01/23/2017 at 15:53 point

Hei! May be your link has a wrong."System Design Document"

  Are you sure? yes | no

i.abdalkader wrote 02/04/2017 at 00:46 point

Yes I need to update all the links.

  Are you sure? yes | no

AVR wrote 12/21/2016 at 19:15 point

Hey awesome project!!!!! I'm looking into dong something similar but with a Zync 7000. I want to use the same camer module you are using, its got good specs but I can't find a supplier for the camera itself, just boards that use it sold by Digikey and Mouser. Would appreciate your insight.

  Are you sure? yes | no

i.abdalkader wrote 12/21/2016 at 20:39 point

It's obsolete, we switched to OV7725 (PN OV07725-V28A)

  Are you sure? yes | no

AVR wrote 12/21/2016 at 21:01 point

I've got your design files open, I was actually referring to the OV7725. Just having a hard time finding a Supplier. 

  Are you sure? yes | no

i.abdalkader wrote 12/21/2016 at 22:38 point

Search for "OV07725-V28A" that's the actual part number. Arrow has some, or Aliexpress not.

  Are you sure? yes | no

AVR wrote 01/09/2017 at 05:57 point

sweet thanks! Anywhere I can find the full datasheet? The one I located says preliminary on it 

  Are you sure? yes | no

i.abdalkader wrote 01/09/2017 at 14:53 point

Google, you'll find the full datasheet and there's an app note too.

  Are you sure? yes | no

AVR wrote 01/06/2017 at 06:20 point is effectively the FPGA linux edition of your project, you are welcome to collaborate with me when I get some hardware together :)

  Are you sure? yes | no

manjuprasadmbasangi wrote 10/11/2016 at 09:51 point

Hi, Can you do this on fpga zynq7000 or similar

? it will have more processing power 

  Are you sure? yes | no

Petar Petrov wrote 06/20/2016 at 18:53 point

Amazing, I could use that on my projects instead of consumer cameras.

  Are you sure? yes | no

Jana Marie wrote 04/10/2016 at 18:57 point

Awesome project, thanks for sharing, i rely need to get one of these modules!

  Are you sure? yes | no

Martin Vincent Bloedorn wrote 04/08/2016 at 22:42 point

Hello Ibrahim! Congratulations on the project (and thanks for the wonderful source material). 
I'm currently looking for a solution to stream video from two OV2460 sensors (still haven't decided completely on them, though) to a computer via USB - where I'll run some stereo-matching algorithms. Something like SVGA at 15fps would suffice, I guess. 

I am looking into a dedicated USB controller such as the CYUSB3014, but I keep wondering if the STM32F4xx would be up for the task. In your experience, do you believe that it can handle it? 

Sorry for this sort of off-topic question, but you seemed like the ideal person to ask it. 


  Are you sure? yes | no

i.abdalkader wrote 04/09/2016 at 14:44 point

Hi, I was working on a similar project, I ended up using the CYUSB301X. There's an app note on connecting two sensors.

  Are you sure? yes | no

Martin Vincent Bloedorn wrote 04/09/2016 at 23:10 point

I'll look into it. Thanks for the prompt response! 

  Are you sure? yes | no

Bryan Lyon wrote 06/21/2016 at 20:28 point

I'm really interested in Stereo camera systems as well, I've got a project up where I'm going into Stereo Camera work I'm doing (( ).  Since stereo vision is such a new field, I'd love it if you would keep me updated on how your project goes (though for my own needs, I know the OV2460s are insufficient).

  Are you sure? yes | no

i.abdalkader wrote 03/17/2016 at 18:26 point

Hey everyone, you can now pre-order the new OpenMV (OV7725), new WiFi shield, BLE, LCD or FIR from our online store here:

  Are you sure? yes | no

manjuprasadmbasangi wrote 03/04/2016 at 04:28 point

Does this camera module has IR cut filter

  Are you sure? yes | no

deʃhipu wrote 03/04/2016 at 08:24 point

There are several lenses you can choose, one of them doesn't have the filter, the rest do (see

  Are you sure? yes | no

issouf wrote 01/23/2016 at 00:37 point

hello i need to collaborate with you about your project let me know what is the final step

  Are you sure? yes | no

farrelan wrote 01/01/2016 at 17:37 point

I would love to have this without the camera attached. Rather allow me to plug in my own micro camera say from my quad fpv.

  Are you sure? yes | no

ipaq3115 wrote 01/20/2016 at 15:33 point

That would probably take some work, most FPV type board cameras put out analog video and this has direct (digital) communications with the camera. I imagine it'd be a whole 'nother project to pull the analog video into the cpu.

  Are you sure? yes | no

farrelan wrote 01/25/2016 at 13:23 point

You are correct that most FPV cameras are analog but there are a number of them currently that are digital. With headgear like FatShark producing better headsets, digital is not far behind on the cameras. I would be just as happy with this project if the camera was not perm attached in general. The current camera, remote mounted would work for my projects the same. In turn the board could also possible be smaller footprint.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates