Close
0%
0%

OpenMV

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.

Overview:

  • 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"

OpenMV2...

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: https://kck.st/2ps2Pgx

  • OpenMV Kickstarter

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

    The OpenMV Kickstarter is finally live! Check it out http://bit.ly/openmvcam

  • 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:

    https://www.tindie.com/products/bot_thoughts/openmv-cam/

    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?

Share

Discussions

gshmakov wrote 01/02/2015 at 11:17 point

Hi, great project.

I wonder if you managed to find detailed description of OV2640 registers. All I could find is preliminary data sheet with very limited info and nothing on JPEG.

  Are you sure? yes | no

i.abdalkader wrote 01/03/2015 at 05:19 point

Search for ov2640 software application notes

  Are you sure? yes | no

J Groff wrote 12/12/2014 at 11:40 point
I would like to see something that just pumps DCT and IDCT on the parameter space of my choosing and hands me an array of correlated cosines

  Are you sure? yes | no

Robert wrote 11/29/2014 at 05:18 point
'">

  Are you sure? yes | no

deʃhipu wrote 11/22/2014 at 22:29 point
I can't wait to get my hands on one of those, and put them in my walking robots. This would be the perfect robot brains for me: not only small and already including a camera, but also programmable in Python! I'm trying to hack together a board with camera using VoCore and a laptop camera module, but it's not going very well, and it will probably never be able to actually process the image much.

  Are you sure? yes | no

Rebelj12a wrote 11/20/2014 at 20:35 point
Loving the progress on this. Seeing this as having a lot of potential. Have you looked into branching out to direct sensor driving with this separate from the camera board you have there?

  Are you sure? yes | no

99guspuppet wrote 11/14/2014 at 23:44 point
Wonderful Project the comments are full of valuable information Thanks for your efforts

  Are you sure? yes | no

candidomolino wrote 11/14/2014 at 00:13 point
Hi, really new here!

Great project!

Have you tried to used it as a microscope to identify and count cells? Would have a lot applications in biotech!

Good luck!

  Are you sure? yes | no

i.abdalkader wrote 11/14/2014 at 06:18 point
No, haven't tried that before, it could work.

  Are you sure? yes | no

99guspuppet wrote 11/14/2014 at 23:46 point
Great idea..... I have used webcams to make digital microscopes... the OpenMV would work great for that I think.

  Are you sure? yes | no

hashg wrote 11/04/2014 at 21:43 point
Where do I buy this board?

  Are you sure? yes | no

i.abdalkader wrote 11/14/2014 at 06:13 point
It will be available soon, hopefully :)

  Are you sure? yes | no

Ali Vadoud wrote 10/31/2014 at 21:52 point
Hi, I also wanted to know if you used the BSP for stm32f429 discovery from Emcraft because I was able to run uclinux on my stm32f429 board but I am not able to display anything on the tft, I have just access to busybox.

  Are you sure? yes | no

i.abdalkader wrote 11/01/2014 at 16:42 point
Probably need to enable the driver somewhere, I'm using FBTFT for the small LCD.

This fork has better support for discovery and binaries too https://github.com/robutest

  Are you sure? yes | no

Ali Vadoud wrote 11/06/2014 at 17:54 point
Hi, thanks again for your subgestions, I was finally able to see the linux pinguin on the tft. Just a last question, how did you import the files from https://github.com/robutest to a project in your IDE compiler ?. I am trying to export the files for uboot to a Thunderbench project in order to compile and edit them.
regards
p.s sorry for all those technical questions but it seems that it is the only way that I can learn something about uclinux.

  Are you sure? yes | no

Ali Vadoud wrote 10/13/2014 at 17:20 point
Hi, I really like your projec. I wanted to know how you have put linux into the microcontroller, did you used a linux based computer?

  Are you sure? yes | no

i.abdalkader wrote 10/14/2014 at 06:23 point
Thank you. No it's actually running on the STM32 there's an external SDRAM. uClinux supports cortex-m and work to support STM32 is done by emcraft.

  Are you sure? yes | no

i.abdalkader wrote 10/15/2014 at 06:24 point
I missed your other reply, just saw it in feed, the kernel is XIP (execute in
place) kernel, so code is running from flash (not relocated in RAM) kernel+fs
reside on flash, data goes into RAM. This works out great because SDRAM is slow
compared to the on-chip flash access time (which is cached and accelerated).

  Are you sure? yes | no

Ali Vadoud wrote 10/17/2014 at 18:40 point
Ok thanks

  Are you sure? yes | no

seme1 wrote 10/06/2014 at 09:26 point
Hi, This project sounds very interesting. In the rc vehicles domain, it would be very useful for First Person View (FPV), in addition to sense and avoid. However, it is important to for the module to have a very low latency. I see that another user (matt venn) has already asked about the latency. Did you have a chance to measure it yet ?

  Are you sure? yes | no

i.abdalkader wrote 10/07/2014 at 03:26 point
I've been focusing more on documentation, videos, adding new features, fixing old issues, improving the IDE etc. This week, more people will have OpenMVs so I expect there will be more testing going on, and more issues, but like I said to Matt, latency depends on the algorithm + frame size, it can take any where between 30ms-100ms to output the results. That's acceptable to me for now, if I can optimize it more, or do some upgrades in the future I will.

  Are you sure? yes | no

DZ85 wrote 10/06/2014 at 07:35 point
Hi, I have been trying a lot to get the OV2640 click (1600x1200)2MP image but I
haven't been able to do so.In your code you have not used the uxga_regs in
ov2640.c.Is this array supposed to be used instead of svga_regs in reset() ? I
would appreciate your help in this matter.Thanks in advance

edit - I am using a 16Mhz MCO out on a pin to clock the camera instead of the
12Mhz pwm signal that you are generating in source code.Should this make a
difference?

edit- Line 302 of ov2640 shouldnt it be UXGA_HSIZE instead of SVGA_HSIZE?

  Are you sure? yes | no

i.abdalkader wrote 10/06/2014 at 16:01 point
Yes, you should use svga_regs when (res <= SVGA ) and uxga_regs when (SVGA
<res<= UXGA) you could also use cif_regs and subsample from there down to QQCIF
(I subsample from SVGA so I didn't actually bother implementing the cif_regs).

Line 302 is a typo, I don't use high res much, so the code was outdated, sorry
for the confusion, but I fixed it now (checkout github, ENABLE UXGA commit) and
I captured an SXGA and UXGA images.

You can use higher clocks, but I don't see the point since there's an internal
PLL so you can double the 12MHz internally if you set CLKRC=0x80 you'll get
24MHz, which is what I do for low resolutions and I use 12MHz (0x81 or 0x00) for
high resolutions, in fact I think it's better this way to keep high freqs inside
the sensor. Also, you will need to change some registers.

One final note, you might want to lower the quality when using UXGA to avoid
overflowing the frame buffer, the code doesn't detect/handle that yet.

*If you find any other issues, please report them on github, and nice catch :)

  Are you sure? yes | no

DZ85 wrote 10/16/2014 at 13:01 point
Thank you for your response , why have you used external eeprom when you could
have stored settings on stm32f4 using IAP, wouldn't it save cost?
Can you also share sourcing for the Ov2640 BGA camera and lense?

  Are you sure? yes | no

i.abdalkader wrote 10/16/2014 at 13:56 point
The EEPROM is not currently used, I just left there just in case it's needed, the idea was to use it to manage the internal flash FS, which would save some RAM.
More details here:
https://github.com/micropython/micropython/issues/341

The Lens (20mm/22mm) and BGA chip (actually called CSP2) in eagle/omnivision.lbr

  Are you sure? yes | no

DZ85 wrote 10/16/2014 at 16:23 point
I'm sorry what I meant to ask was from which vendor have you sourced the BGA camera ?

  Are you sure? yes | no

i.abdalkader wrote 10/16/2014 at 17:48 point
That's available from many suppliers on aliexpress just search for ov2640 ($2-$3), like this one:
http://www.aliexpress.com/item/OV2640-BGA/1016825336.html

I had the lens, but you can find one there too (M12 I think)

  Are you sure? yes | no

DZ85 wrote 10/21/2014 at 08:30 point
Thanks again for your response , it takes 500 milliseconds to capture 2MP JPEG, is this due to the processing inside the camera DSP? Can I increase this speed by setting DVP prescaler to 0 in R_DVP_SP(0xd3) register?Are there any other settings that will help me reduce JPEG capture time?

  Are you sure? yes | no

i.abdalkader wrote 10/22/2014 at 07:26 point
It should be able to do 15FPS @2MPs according to the datasheet, so DSP is probably not the reason. I haven't tried much I'm not really concerned with high FPS at this resolution but you could try setting CLKRC=0x80 that's 24MHz or using a higher xclk.

  Are you sure? yes | no

DZ85 wrote 10/24/2014 at 21:50 point
Can you please check if you are able to click an image with CLKRC=0x80, in my current set-up with the discovery board and wires I am able to go until CLKRC=0x81.In CLKRC=0x80 I recieve some JPEG data but do not get DCMI_IT_FRAME interrupt.
Are you able to click a JPEG image immediately after setting the I2c registers?
I have to wait 3-5 seconds for the brightness of the image to settle.If I click an image before that I get much darker images.Thanks

With CLKRC=0x81(12Mhz) I am able to capture image in 200m secs thats about
(5-7 fps)

Is running CLKRC=0x80 with external 12Mhz same as connecting a 24Mhz external clock with CLKRC=0x00 due to internal multiplier/pll?

  Are you sure? yes | no

i.abdalkader wrote 10/25/2014 at 10:48 point
Maybe the I/O speeds need to be higher at this frequency, and yes the first image(s) are darker it takes time for the auto functions (AGC,AWB etc..) to work/settle down (I think you can change the speed of some functions check the datasheet)..
24MHz External clock and 0x00 *should* be the same as 12MHz and 0x80.

  Are you sure? yes | no

DZ85 wrote 10/25/2014 at 16:00 point
I tried over-clocking the STM32F to 240Mhz and also supplying 48Mhz clock to camera, however it only works for clocks below or equal to 24Mhz.I am able to capture image in CLKRC=0x80 however I get a lot of green pixels on the top left of the image. Could'nt find any functions to speed the auto functions please let me know if you have come across any.
I am able to capture within 300miliseconds using manual exposure mode and setting a high shutter speed however picture as whole is a bit dark.I need to check how exposure and shutter is calculated I guess.
Strangely in manual exposure mode the size of the image increases and I had to reduce the quality factor

  Are you sure? yes | no

i.abdalkader wrote 10/27/2014 at 16:05 point
You don't need to overclock for that, just try increasing I/O edges (I/O speeds) or check with scope make sure it's actually 24MHz (which is the typical clock btw, so you don't need to supply 48 either)
For the AEC/AGC speeds check "VV" register in the datasheet (I played with that once on the OV965x)

  Are you sure? yes | no

i.abdalkader wrote 10/05/2014 at 13:20 point
To everyone who commented on my project logs, I just saw your comments today! it seems that notifications for comments on project logs wasn't working until recently, so I'll try to reply to all comments starting with the oldest ones, I hope you see this and I'm really sorry about that.

  Are you sure? yes | no

justinStitches wrote 09/16/2014 at 05:53 point
Very cool work. FYI groupgets.com exists to group buy parts and BOMs in case that you can't get on a different platform. We just kicked off a FLIR Thermal Imager campaign here in case you want to a thermal version of openMV: https://www.groupgets.com/campaigns/27#details

  Are you sure? yes | no

Viper-Gtr wrote 09/04/2014 at 10:19 point
Great project! I saw that you used the "MLX90620". How many fps you get with it on the screen?

  Are you sure? yes | no

i.abdalkader wrote 09/04/2014 at 12:57 point
About 13-14FPS, this includes reading an RGB image, scaling it to 128x160 (lcd resolution), reading and normalizing temperature data, scaling the IR image and blending with RGB, the final step is writing to LCD.

  Are you sure? yes | no

Pixel Pirate wrote 09/01/2014 at 22:34 point
Really cool project! Perhaps you could squeeze an ARM9 on there and get buildroot running, once you've done that you could run python scripts from the SD card!

  Are you sure? yes | no

i.abdalkader wrote 09/01/2014 at 22:50 point
Thank you.. actually I managed to run uClinux on the big camera, but it's still missing some core drivers, might work on that when I have more time.

http://hackaday.io/project/1313/log/6346-running-uclinux-on-openmv2

  Are you sure? yes | no

Pixel Pirate wrote 09/01/2014 at 23:16 point
Yeah, uClinux is a really stripped down version of Linux, and therefore is limited in what it can do (Plus it's missing a MMU!), so I don't really think it would be suitable for what you're doing.
But if you're willing to mess around with BGA components, you could squeeze a 64MB RAM chip, 400MHz CPU, and 512MB flash chip all in roughly the same area as the 144-LQFP, for around the same price as the uC, too!

  Are you sure? yes | no

i.abdalkader wrote 09/01/2014 at 23:53 point
It has its limitations, but all I need is just a single process running MicroPython with OpenCV bindings and the MCU's built-in flash is enough for a romfs so no need for an external flash... I am willing to do something more powerful, I was actually considering a cortex with a serious SIMD/FPU, but I don't have all the resources I need right now :)

  Are you sure? yes | no

Pixel Pirate wrote 09/02/2014 at 01:55 point
True enough, I've just been 'that guy' recently because I've been experimenting with ARM9's.

  Are you sure? yes | no

sophi--e wrote 08/24/2014 at 01:33 point
Dude amazing ! i have to build one at some point. Are you open for questions if run into any problems?

  Are you sure? yes | no

i.abdalkader wrote 08/24/2014 at 06:32 point
sure :)

  Are you sure? yes | no

visualkev wrote 08/23/2014 at 14:40 point
I have to build one. It looks to be a very cool device. I have ordered some boards from Osh park. I may have missed some details, but the parts list from the schematic does not seem to describe tolerances for the values of the passives nor the value for Y1 nor the type of diodes for D1 and D2. I look forward to using openmv.

  Are you sure? yes | no

i.abdalkader wrote 08/23/2014 at 19:12 point
Some values/tolerances are usually not shown on schematics, because they can change later, but anyway, I will share the most recent BOM in the links section, it has DigiKey part numbers, except for the sensor, which you can get from ebay...

  Are you sure? yes | no

mistertime wrote 08/22/2014 at 17:44 point
Holy frack. I want one.

  Are you sure? yes | no

Ricky wrote 08/20/2014 at 18:21 point
I would love to build a low cost themal cam if the HW/SW were available

  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