Me and Ibrahim saw that. They are going in a different direction that us. Our goal is to make cheap, easy-to-use, low power machine vision so you can use it in all kinds of tasks. We actually want to make the core IP of the product even smaller in the future so you can easily embed the system in products. They made a power house system for robotics I guess? It draws 1A and takes 5 seconds to boot. So, I don’t think making it embed-able was a design goal.
Anyway, I wish them luck on delivering that system. I think they set their price too low however. The OpenMV Cam is priced such that we can sell to distributors in low volumes and grow the company.
The visual attention/saliency detection has many other applications, but used in machine vision is way cooler.
I also have great respect for Prof. Laurent Itti’s work. He basically pioneered saliency detection AFAIK and understand.
What I don’t like about JeVois:
The power consumption obviously, the camera is tiny but you need a power bank and a fan to go with it, doesn’t sound practical.
The fact that it’s Not opensource, no HW schematics, and using Allwinner chips almost always ends in a sad story.
Again Allwinner, other than kernel blobs, zero-docs the company is just too aggressive towards opensource/makers (try to contact them they’ll literally shoo you away ).
As far as I can tell there’s No way to interface to the camera, like how do I make it detect something and give me back the results ? Seems you have to install a toolchain, write in C++ and link to OpenCV, cross-compile for ARM, and copy the binary somehow to the camera, yeah no thanks. That’s just too much to ask from a developer not to mention users, not to mention beginners who just want to make a robot follow a line or detect a face.
There’s a reason we didn’t do an SBC camera, even though I did that for fun years ago (OpenMV-DSP | Hackaday.io) there’s just (so far) no efficient (cost-wise) way to do an SBC unless you’re a really big company with tons of resources. At the current JeVois prices you can’t sustain a company, by that I mean don’t expect too much work done on the software post-ks if any.
Finally, JeVois and OpenMV come from a totally different worlds, each has its place I guess but that doesn’t mean we won’t be doing a higher-end cam with the same level of usability as the current OpenMV we’re just getting started
Another advantage of OpenMV is that it’s got usable GPIO pins, including three PWMs for servos/motors. So you can actually operate a robot with an OpeMV by itself, while a JeVois would require the addition of an Arduino as an IO interface.
My JeVois just showed up. It’s the craziest thing.
HW: Tiny (smaller than OpenMV, even including the fan) with a cheap 1.3MP camera sensor and software loaded on a SD card that you have to burn, like a RaspberryPi. You can connect via Serial-over-USB for video streaming, but to get other data out, you need to make your own cable with the included connector and bare wires.
SW: You have to select different video resolutions to trigger different built-in CV programs. For example, to load the Road Navigation code, you’d tell your video client to switch to YUYV 176x144 resolution. This is bizarre beyond belief: JeVois: Advanced topic: Video mappings and configuring machine vision modes
They say it’s running Linux, but I can’t figure out how to get to a Linux command line. All you can get to is a serial connection where you can enter what amount to AT commands for settings.
I think JeVois is actually a software framework, which has just been embedded on a camera for the sake of this product. If you like OpenMV’s MicroPython approach, you’re going to hate this. It’s much more like Pixy (a proof of concept, not a tool) than OpenMV
TL;DR: You have to do that if you don’t want to write your own software.
This actually makes sense, I’m pretty sure UVC (like any other USB class) allows some vendor-specific requests, which can be used to implement things like calling different functions, but then you’d have to write and maintain a cross-platform userspace USB driver/software. This is really easy to do on Linux with libusb, but libusb support on other platforms is not that good. So the only way to use standard/existing software (like VLC) is to trap standard requests (like resolution change) and do something else.
The really old versions of OpenMV IDE (GTK based) used libusb, I tried to make it work on all platforms, it was a nightmare (especially on Windows, not sure if libusb support has improved since). The main problem was the limited number of endpoints in STM, had to use 2 configurations to support an additional debugging interface, which didn’t work nicely on Windows…Then I had a really nice idea to “tunnel” debugging commands in serial, so I switched to serial debugging. This allows anything that speaks serial/CDC to control the cam, in theory you should be able to control it from Android phone using USB OTG.
Maybe if you remove the case you’ll find a serial port.
BTW in addition to upgrading to H7, we’re going to prototype a new Linux cam very soon, it’s not going to be as powerful as Jevois (hardware-wise) but it’s going to have the exact same form as current OMV, will allow different sensor options (Global shutter, high-res, monochrome etc…), built-in WiFi, tons of GPIOs and with the same level of usability, IDE, scripting as the current OMV. We’ll be looking for beta-testers very soon
I think JeVois does higher res for some stuff and a higher FPS. Also, I think it has meagbytes of ram. Not Kb. Nice review however!
Oh, in other news, I’m almost done with your fast line following request. 30 FPS RGB565 line detection at 160x120 is a reality. The lines are a bit jumpy given the hough line detection space is somewhat quantized. But, other than that it’s pretty impressive.