Syncing Image Capture on Raspberry Pi 3 Using Picamera V2

Question

I am currently attempting to synchronize four raspberry pi 3s using Pi Camera V2s to take photos of a stopwatch at the same time. I am using a function generator to send a signal to the GPIO pin. The images are occasionally .033 seconds apart. I believe I have pinpointed the source of this. I used a profiler on a python script that simply captures an image. Looking at the processes, a "sleep" function of duration .033 seconds is being called usually 14 times. It sometimes, however, is called 15 times, which would account for the discrepancy. I believe this extra instance of sleep is occurring before the shutter begins to open, which would make the cameras images captured .033 seconds apart. I cannot, however, for the life of me, find how/where the shutter is triggered to open in the picamera python library. My thought is that if instead of it trying to decide how long to wait, I hard coded a wait period long enough to ensure everything is in order, the cameras will all capture the image at the same time. If anyone knows of where to find when the shutter is being opened or any other insight into the matter, that would help a lot. Thanks guys. I can attempt to further clarify or provide further information if needed.

Answer 1

When you call the capture function of the picamera object it is starting the encoding and waiting for a callback to reset wait and so indicate it is complete (or for CAPTURE_TIMEOUT to be exceeded):

        encoder.start(output)
        # Wait for the callback to set the event indicating the end of
        # image capture
        if not encoder.wait(self.CAPTURE_TIMEOUT):
            raise PiCameraRuntimeError(
                'Timed out waiting for capture to end')

the encoder.wait function looks like this:

    result = self.event.wait(timeout)
    if result:
        self.stop()
        # Check whether the callback set an exception
        if self.exception:
            raise self.exception
    return result

and if you look at how event.wait is implemented (here's a great SE question that goes into detail on it), it is made up of a number of smaller (than the timeout) delays (getting longer as time goes on) and after each one checking if the lock can be acquired.

I would expect there to be very small variances in the time that each Pi takes to acquire the lock, and possibly one occasionally rolls over to a 15th sleep.

So, in summary, not something that you have any control over...