I would like to know if it is possible to run the OpenCV HOG Detector using a Raspberry Pi in real time using the Raspberry Pi camera.
Unfortunately not, even overclocked to 1000MHz and with 64MB for video it's not enough.
On my old mac with a 2.1 GHz Dual Core Intel CPU and 2GB of ram I could barely get between 8-12 FPS for a 640x480 stream.
I haven't tried OpenCV 3.0 (just 2.4.8) on Raspberry PI so don't have any softcascades test results to share, but it sounds promising.
Another idea I can think of is using LBP cascades. You could start with a HAAR since there's one already for detecting bodies so it would be easy to test, but LBP should be a bit faster. Perhaps you could train a cascade that works really well for a set environment.
Also, if it helps, you can use my little OpenCV wrapper for the PiCamera for tests. It basically returns frames from the Pi Camera module as cv::Mat.
I've had openCV running on a PI, using a USB video grabber, as I am using a CCTV camera. I use Python.
It runs fine (for what I want to do), but you need to limit the resolution.
It's slower than a PC (2ghz dual core) but still works.
Related
I need to build standalone module which records video from rasberry pi camera to sd card (through external module) when the motion on video is detected.
So, I need to run OpenCV that I will use for motion detection. Is it possible to run it on Raspberry Pi Pico on board? How much FPS will it have in case for i.e. background subtraction?
The RPi Pico uses an RP2040.
RP2040 is a dual-core ARM Cortex-M0+. It comes with "264kB on-chip SRAM". You shouldn't expect this to have any power that's useful for image processing. It doesn't even run Linux. Were those 264 kB fully available to you, you could fit a single grayscale image of size 593x445 in there.
OpenCV can target ARM but not such tiny microcontrollers.
Here's some evaluations by OpenCV itself: https://opencv.org/arm/
You should investigate "OpenVX".
Im using raspberry Pi 4 B and have installed ROS melodic. I have Raspberry Pi Camera V2.1. Would like to send a compressed video with a low latency as much as possible to the Microrcontroller (ESP32) via sonar. So its important to have a very low latency as the sonar has a low bandwidth. I look at this github camera node raspberry pi camera node for Pi Camera V2 but the compressed video has a latency of more than 2 seconds. Any other way or other approaches or other help to overcome the issue with the latency?
Thanks
High latency won't necessarily affect a system with low bandwidth so long as the transmission is consistent. With any camera being processed through ROS there will almost always be some delay. The above node will probably be one of your best bets, however, there is the usb cam node. If neither of these are sufficient you'll probably need to sit down and crunch the numbers to make sure you actually have enough bandwidth/processing power. Then you might want to look into creating your own video streaming node that's a little more tailor made and lower overhead; I'd suggest gstreamer for this.
I've been researching for a while and found tons of helpful resources on this subject, but I figured I would lay down my specifications here so I can get some recommendations from people experienced in this area. It seems like Beaglebone and Raspberry Pi with a Logitech or Microsoft camera are my best options at this point.
My target speed is 50 fps (20 ms per image) with the processing involved. From what I've looked at, this doesn't seem feasible considering most webcams don't go much past 30 fps. More specifically, I need to take the endpoints of an object (like a sheet of paper) and calculate where the midpoint is. Nothing incredibly fancy. 1080p isn't a requirement, I can most likely go much lower. Python is preferable over C and C++ since I've already done a lot of image processing with Python.
It looks like a lot of the code I'll be needing is mostly open-source already, so I really just need to figure out what controller/camera combo I should be using.
It's still a bit of a toss up between the two however here are my views.
The BBB will use a USB web cam and that will take a certain amount of processing power just to get the image. After that you can then manipulate it with SimpleCV
The RPi has a camera board that they say will only use < 3% of the cpu and the rest can be used for processing your image. Plus you can over-clock the RPi to 1Ghz.
Using the RPi with a basic webcam does not give a very good result, whereas the RPi camera works directly on the CSI bus and is set to do 1080 dpi natively. Plus they now have drivers for the camera that work with SimpleCV too.
IMHO I would say that the RPi B and Camera board would be technically faster that the BBB, but it also depends on what manipulation you plan to do :
Marc
I have some code that I have adapted to run on a headless Rpi using a usb webcam, it is running a bit slow, so my questions are:
If I were to use the GPI pins with a dedicated webcam would that be faster?
Is there any way to speed up my code for Rpi?
Where can I get a Rpi webcam?
My code is here, I struggle to paste inline so its a link
For your question about where to get a Pi camera, a new camera has recently been release. I don't know about speeding up you code, but you might want to overclock your Pi. Good luck,
Like Quentin suggested, a dedicated Camera (in our case, Rpi camera link : http://www.raspberrypi.org/camera) should work much faster than USB webcams as it is known to use GPU for encoding / decoding process instead of using CPU.
(Source : http://www.raspberrypi.org/phpBB3/viewtopic.php?t=55798)
You can try reducing width and height of the frame for better performance in terms of speed.
Also you're using Iplimage* which is no longer supported in new OpenCV versions and replaced by cvMat.
(source: Difference between cvMat, Mat and IpImage)
Hope it helps.
For the people that have experience with OpenCV, are there any webcams that don't work with OpenCV.
I am looking into the feasibility of a project and I know I am going to need a high quality feed (1080p), so I am going to need a webcam that is capable of that. So does OpenCV have problems with certain cameras?
To be analysing a video feed of that resolution on the fly I am going to need a fast processor, I know this, but will I need a machine that is not consumer available...ie, will an i7 do?
Thanks.
On Linux, if it's supported by v4l2, it is probably going to work (e.g., my home webcam isn't listed, but it's v4l2 compatible and works out of the box). You can always use the camera manufacturer's driver to acquire frames, and feed them to your OpenCV code. You can even sub-class the VideoCapture class, and implement your camera driver to make it work seamlessly with OpenCV.
I would think the latest i7 series should work just fine. You may want to also check out Intel's IPP library for more optimized routines. IPP also easily integrates into OpenCV code since OpenCV was an Intel project at its inception.
If you need really fast image processing, you might want to consider adding a high performance GPU to the box, so that you have that option available to you.
Unfortunately, the page that I'm about to reference doesn't exist anymore. OpenCV evolved a lot since I first wrote this answer in 2011 and it's difficult for them to keep track of which cameras in the market are supported by OpenCV.
Anyway, here is the old list of supported cameras organized by Operating System (this list was available until the beginning of 2013).
It depends if your camera is supported by OpenCV, mainly by the driver model that your camera is using.
Quote from Getting Started with OpenCV capturing,
Currently two camera interfaces can be used on Windows: Video for Windows (VFW) and Matrox Imaging Library (MIL) and two on Linux: Video for Linux(V4L) and IEEE1394. For the latter there exists two implemented interfaces (CvCaptureCAM_DC1394_CPP and CvCapture_DC1394V2).
So if your camera is VFW or MIL compliant under Windows or suits into standard V4L or IEEE1394 driver model, then probably it will work.
But if not, like mevatron says, you can even sub-class the VideoCapture class, and implement your camera driver to make it work seamlessly with OpenCV.