As usual, it depends on the application.

The Raspberry PI has advanced in recent years, and with the latest Raspberry PI 5, its current performance with 4 cores, 8GB RAM, and ARM v8 (Cortex A76) could be enough for a small vision task.

Considerations that make it a good option:

• It is small and lightweight, and the cost is low.
• A small vision task that is self-contained.
• It is easy to replicate multiple systems by creating an image of the Raspberry PI.
• Short lead times in case one breaks.
• Easy to be battery-powered.
• Most camera manufacturers that provide a streaming SDK will support ARM v8 (such as IDS Peak/Halcon/Basler Pylon/CVB).

Drawbacks:

• Heat dispersion can become a problem, and the CPU will be throttled if the temperature reaches 85 degrees (which will decrease performance).
• End of life support (10 years: 01.01.2035)
• There is insufficient CPU/GPU power for drawing images at full resolution/speed (e.g., via X11 when rendering the application on a different machine).

Alternative boards with more performance and GPU power are available and are more suited for machine learning applications. The Nvidia Jetson is well known for its GPU power. Different companies provide carrier boards or their own solutions, such as The Imaging Source or Toradex.

How did the Raspberry PI 5 perform?

A recent client project allowed me to evaluate the performance of the Raspberry PI 5 using an older IDS uEye camera and a GigE Vision camera. Their previous evaluation of the Raspberry PI 4 was unsuccessful as the device overheated.

Both cameras’ respective SDKs are used. The IDS Peak adds additional overhead as it has to use the uEyeTL to convert the data prior. The uEyeTL was used due to backwards compatibility. Newer IDS GigE Vision cameras will not have this overhead as they use the pure IDS peak interface. Both SDKs do not allow the use of a nonproprietary camera. This makes the SDKs free, but it comes with a cost of additional development if multiple manufacturers need to be supported.

The following setup has been tested:

Manufacturer	IDS uEye	GigE Vision Camera
Framerate	50.446451 (max)	20.4
Bandwidth (used)	65.92 Mbyte/second	97.5 Mbyte/second
Resolution	1280 x 1080 (1.4MP)	2448 x 2048 (5MP)
Number of buffers	15	40
Note:	The network is not optimised for package sizes. The maximum possible processing time is 20ms.	The network is not optimized for package sizes. The maximum possible processing time is 20ms.

There were three main concerns about this: CPU load, the temperature of the Raspberry PI 5 during operation, and processing time. Measurements were taken every 10 seconds.

Test 1: Acquisition Only – IDS

The test ran for just under 5 hours. No images were lost, and the temperature stabilized around 53 degrees.

The CPU load for the IDS uEyeTL (top line) is ~16%, while the application itself (bottom line) uses ~5%, for a total of ~20% CPU usage.

Test 2: Adaptive Thresholding – IDS

The next step included adaptive thresholding with an 11 x 2 kernel, which increased the temperature and CPU processing. The Raspberry PI 5 has a metal housing connected to the CPU. Interestingly, the temperature went up first. Lying it on a piece of metal for additional heat dispersion dropped the temperature, and it stayed stable. Regarding the CPU processing, the top line shows the processing (yellow), and the bottom line shows the IDS uEyeTL over time.

Test 3: Simple Thresholding – GigE Vision Camera

A simple threshold was applied while using the Basler camera. The temperature and CPU load stayed stable.

Final thoughts

• The adaptive threshold using the GigE Vision camera @ 5MP exceeded the available processing time and led to packet loss.
• Saving 2 images and no processing (IDS camera) increased the total CPU load to 84%, while the uEyeTL used 18.3%. It took 54ms, at least twice the available time at 20 fps. This should be used with caution.
• Having a passive heat sink (e.g., mounted to a metal bar) is beneficial for keeping the temperature stable. It hasn’t reached any critical temperature, which would lead to throttling.
• All the processing was split between 1-2 cores. This leaves additional cores free for more processing.