Having actually set up multiple webcams on a rpi (2 each on 2 pis, costs the same as one drop cam), the most surprising thing is the power consumption. Either use a powered hub or settle for slow rates/low res. It's hard to find, as the cameras just stop working. Unless you know where to look there are no cues as to what went wrong on raspbian. That and many of the command line tools to upload to gdrive are broken by lack of maintenance, iirc the go tool gdrive was the only one that worked for me.
I personally didn't run into any issues with power consumption or slowing down. I've let this setup run for multiple days at a time when I'm on vacation and use it to monitor my apartment. Overall, it works well (but can obviously be improved).
Also, if your using wifi, that just exacerbates the problem. My camera would work without my wifi, and my wifi would work without the camera. Replaced the power-cable, and all was well.
Thanks for posting this. I built something similar using a single camera. It runs decently at first and seems to slow down over time. I'll give a powered hub a try.
This guy is a beast and made it incredibly easy to implement. After having taken 15 years off from writing code, I started programming again using RaspPI and Arduino a couple of months ago. Using Adrian's examples, in a day I put a motion detection system in place for a treat dispenser I built for my dog (playwithpickles.com for background if anyone cares) that records video only when the dog is in view.
It is, however, expensive both computationally and storage (OPenCV is ~3 GB on it's own) so if you dont' need perfection there are other techniques that just compare entire frames rather than segmenting the frames.
Thanks so much for the kind words, and I'm happy the posts have helped! And as a fellow dog lover, it's awesome to see how you put together a real application for treat dispensing.
I was expecting something with "apt-get install motion" with a few config changes, but the author writes his own image capture scripts in Python including motion detection. Nicely done.
It seems like it can switch between multiple cameras, but it doesn't handle multiple cameras at the same time. Still, cycling between cameras every 10 seconds might be acceptable for some people. Or there's the option of configuring the system so that it'll follow motion through the area by overlapping the cameras' fields of view.
demo clip seems to suggest you can switch between streams with ~3ms delay (two cameras filming same laptop screen with a clock running), but its not spelled out anywhere clearly so might be a marketing trick of showing you what you want while selling something else
Looks like 30-50ms, after pausing on a bunch of the frames (the last number is in hundredths of a second). That makes it look like it may just be 1 frame behind (video at 720p, recording at 30fps, 33ms per frame).
Later in the demo video, some of the frames are purple as it switches; it looks like invalid data for the end of the frame, and the Pi sync'ing to the output of the next camera when it starts transmitting its next frame.
I wonder if the commands for the module are covered in the MIPI docs, or if they just pass through anything the Pi sends. It seems like a cool device, and probably more practical for most people than the dual-CSI interfaces on the Pi Computer Module.
CSI is uni directional, camera is controller over separate interface (I2C)
dual csi on compute module is cool because you get four mipi lanes, and one of (former) broadcom engineers, 6by9, was kind and awesome enough to write _generic fully open source_ CSI driver, meaning you can use FPGA(for example MachXO2, lattice offers free MIPI cores) to pump up to 400 MB/s into Pee Linux userland
For those that are thinking of setting up USB webcams for security, beware that low-light capture with most USB cams is pretty dang terrible. My experience is that it worked great during the day but was nearly unusable at night.
Adrian here, author of the post and book. Thanks for picking up a copy of Practical Python and OpenCV -- and it's really awesome to hear you liked it so much.
If you have any questions about computer vision, feel free to reach out!
It seems to be a simple multiplexer. They can only be used alternately, the example script on the page lists code to first select one of the (up to 16) cameras using GPIOs, then capturing with the normal Arduino utility.
Not necessarily. This is a pretty tough problem. Naively yes you can just compute x-plane distance but what if the target is moving diagonally through the visual plane? Then it is very distorted. Or what if the object is rotating, moving through at least one plane where the two cameras can't track?
Direct Linear Transformation is the standard way to do this using a control object (object of precisely known size and measurements) and cameras that don't move. Cameras film the object (usually a big cube), the object is removed, the cameras stay stationary, and anything that goes through that object's field of view can be tracked in all three dimensions. However, the cameras must not be co-linear and must be able to see a point on the object with both cameras, so this means no two front facing cameras, and realistically 4-5 cameras (though 3 can be done sometimes).
A simple way to solve this. Have two cameras (C) facing straight ahead with a known distance (D) between them. When the spot they normally see (X) is blocked, mark the time. (t1-t0) / D
Could you use two vertical strips, calculate the length of strip covered [segment image and use number of pixels as first approximation], assume the articles are discs [or some other assumption depending what you're expecting to measure] and use that to naively alter for objects not moving parallel to the plane of the cameras? Would be interesting to see how accurate you could get given the massive assumptions in play. Known objects would be easier to handle.
