How to interface two RPIs to outsource some tasks

[Markovicz]

Hi Guys, I have a project that is computationally rather heavy and requires real-time object detection with a camera. The execution time is around 140ms. By using another RaspberryPi to just show an image in HD, I could lower it by 70ms, which would double my FPS rate and make me very happy.

The first RPI4 - 4GB should do the detection and the second one, a RPI0 eventually just show the image.

How would you interface the RPIs? By USB, I2C or GPIO?
Thank you!

[bjtheone]

It is not clear if these are parallel tasks or serial. It sounds like they are serial. It is unclear to me how a task that you believe can be handled by a Pi 0 can consume 1/2 of the processing time on a 4B. Are you sure that you are making effective use of all 4 cores on the 4B?

The other issue you need to consider is how much overhead you are going to create by moving the data to the second Pi and what impact that is going to have on your detection process.

[Markovicz]

Thank you for your feedback, I've gone line by line through my code and troubleshooted what caused the increase in computation time and it was cearly the show image command of opencv that added around 70ms:
cv2.imshow(XXX)
Is there a more efficient way to show an image in python or make better use of the 4 cores as you have suggested?

I'm not really caring how fast the imshow updates but it's important that the framerate of the main RPI for the detection stays fast. I've thought about subscribing both RPI4 and RPI0 over some MQTT service and the RPI0 really just handles showing the image and nothing else. That wouldn't add any overhead at all (I'm using MQTT right now anyways).

Thank you!

[pidd]

You would have to DMA it over MQTT to create no significant overhead, I've no idea if that is possible. Nor do if I know that DMA is truly parallel in a Pi, it is on some multi-phase-clock systems.

The other option with two Pis, one does framecapture and detection, the other does framecapture and display.

The detection one sends a simple GPIO signal to other other that basically says "display now".

The detection one will maintain its bandwidth, the display one may hesitate but will probably back up and running by the time the next "display now" signal comes along?

[W. H. Heydt]

Someone who knows Python better than I do should be able to tell you if this is practical... Fork a child process to show the image and see of the scheduler will run it on a different CPU core. Failing that, run the image showing code in a separate process and create interprocess communications to tell it when to show the image. You could even force the two processes to run on specific, different, CPU cores.

What you can also do is look at your detection code to see to what degree parts of it can be run in parallel.

In short, there are lots of possible solutions, depending on how good a programmer you are.

[mooblie]

I am rather "old school" and may be talking nonsense, but anyway:

If you're after maximising throughput, surely as a first step, a compiled language such as C - or a variant - is going to be substantially faster than an interpreted language like Python?

[pidd]

I am rather "old school" and may be talking nonsense, but anyway:

If you're after maximising throughput, surely as a first step, a compiled language such as C - or a variant - is going to be substantially faster than an interpreted language like Python?

If both C and Python are mostly using compiled libraries then there may not be a lot of difference, writing everything in C without libraries would be a hard going. I used C libraries with both Basic and PHP before now, not out of choice but the only way to make it feasible.

But saying that, some higher level languages have unaccountable delays in them sometimes - I've no idea how optimised Python is.