We are working on an application that requires the continuous monitoring of camera output implemented on a stand-alone embedded system, without using a PC
The video shows a powder kept in a tube that liquefies due to its internal reactions over a period of time.
We wanted to analyze this change in state of the powder.
The processor should be able to capture and analyze the images (video stream), during the reaction period, for the change in state taking place.
We want to track the changes in the video frames to analyze the change in the state of the powder without using an additional PC
If Beaglebone Black will be suitable for such application?
Yes, this sounds like a perfect use case for the BeagleBone Black, a webcam, and OpenCV. Take a look at this: http://derekmolloy.ie/beaglebone/beaglebone-video-capture-and-image-processing-on-embedded-linux-using-opencv/
A few things to consider:
-Depending on the duration and resolution of the video, you may need to hook up something like an external HD or high-capacity SD card to store everything. The BBB Rev C only has 4GB out-the-box, which is shared with the operating system.
-The BBB has a 1GHz processor, which could have trouble performing computer vision algorithms in real-time. You may need to write the video straight to disk, then have a separate process perform the algorithms on the recorded video.
Hey thanks for immediate reply,
Also to mention the same camera streaming need to shown in an front-end application.
Also a touchscreen will be interfaced and a few GPIIOs will be used.
Thus adding to the CPU overhead
If BBB will still be suitable for this application.
Hey thanks for immediate reply.
But to add the same camera streaming data need to be shown in an front-end application.
Also the display would be a touchscreen one.
And a few GPIOs also will be used.
All these also add up to the CPU overhead.
If BBB still be able to perform well?
I think there are too many unknowns, and a lack of benchmarks on the BBB, to give you a “yes” or “no” answer.
My suggestion would be to get a BBB. (Or if you only have one chance, get the fastest embedded system you have budget for). Then you develop your algorithm until it works. If it’s slow, then try the following:
-Modify your algorithm to reduce costly steps
-Reduce the video resolution for image processing.
-Reduce the video framerate for image processing
-Create a buffer where you process a chunk of video, and only stream the video to the user once X seconds of processed video is available.
Note that GPIO is not an issue for the CPU if you use the built-in PRUs, which are two 32-bit microcontrollers embedded in the main BBB processor. They operate at 200MHz and are independent from the host and each other(but can still communicate with each other and the host).
Another option is to develop on your computer and draw conclusions from there. EG. If your 2.4GHz multicore laptop is at 98% utilization when processing the video in real-time, then you know that the BBB will not be able to handle it real-time.