Creo que es mejor responder a esta pregunta dando una idea de cómo funcionan las cosas un poco más abajo. Sin embargo, primero una advertencia: no soy un experto en firmware por ningún tramo de la imaginación; mi comprensión bastante aproximada de cómo funciona el módulo de cámara Pi se basa en mi experiencia de escribir la biblioteca picamera e interactuar con los desarrolladores de firmware mucho más conocedores en los foros de Pi. Si escuchas información contradictoria de los desarrolladores de firmware, ¡ellos son la autoridad en esto, no yo! Con eso fuera del camino ...
Tan pronto como se inicializa el módulo de cámara de Pi, está capturando fotogramas. Estos marcos son (en lo que respecta al usuario final) arrojados, pero dentro del firmware de la cámara hay mucho más en juego. Los cuadros se miden para determinar la ganancia que se aplicará al sensor (AGC), el balance de blancos para alimentar el algoritmo de corrección AWB, etc. Por ejemplo, si enciende la cámara e inmediatamente comienza a grabar, normalmente verá el el balance de blancos se corrige solo durante los primeros fotogramas de la grabación:
import picamera
import time
with picamera.PiCamera() as camera:
camera.resolution = (1280, 720)
camera.start_recording('video1.h264')
time.sleep(5)
camera.stop_recording()
Sin embargo, si coloca un retraso antes de comenzar a grabar, verá que el balance de blancos es estable para cuando comience la grabación:
import picamera
import time
with picamera.PiCamera() as camera:
camera.resolution = (1280, 720)
time.sleep(5)
camera.start_recording('video2.h264')
time.sleep(5)
camera.stop_recording()
Entonces, dado que la cámara siempre está capturando fotogramas, incluso cuando no estamos capturando imágenes o grabando videos, ¿qué sucede realmente cuando elegimos capturar una imagen? Le decimos al firmware que active la captura, y el firmware espera a que se complete el siguiente fotograma antes de pasárnoslo (en realidad, si está capturando imágenes desde el puerto fijo en lugar del puerto de video, hay muchas más cosas que incluyen cambia de modo, pero le preocupa el puerto de video, así que ignoremos eso).
Considere lo que esto significa para la sincronización (su caso de uso particular). La cámara no está "lista" para capturar un cuadro en ningún punto en particular. Ya está capturando un marco y cuando solicite uno, le entregará el siguiente completo que esté disponible. Para sincronizar los marcos de las cámaras, todas las cámaras tendrían que inicializarse exactamente al mismo tiempo, y luego sus relojes internos tendrían que funcionar exactamente en sincronía (las cámaras tienen su propio reloj interno; no confían en el El reloj de Pi).
Lamentablemente, no creo que esto sea realmente una perspectiva realista. Si no recuerdo mal, el módulo de cómputo Pi (que tiene 2 puertos de cámara integrados y admite 2 módulos de cámara simultáneamente) usa algunas llamadas especiales en el firmware para que los 2 módulos usen una señal de reloj única (no tengo idea de cómo funciona) funciona a nivel de hardware pero supongo que está usando algo específico para el módulo de cómputo); No puedo imaginar cómo harías algo similar en 4 Pis.
Actualizar:
Debo agregar que es posible realizar una sincronización aproximada con algunos conocimientos de red razonables (por ejemplo, paquetes de difusión UDP). En otras palabras, es posible obtener todos los Pi en una red para activar una captura dentro de un milisegundo uno del otro (suponiendo una red decente de baja latencia como Ethernet), pero como se describió anteriormente, eso todavía no garantizará que todas las cámaras realmente capturar un cuadro al mismo tiempo; habrá un retraso de hasta un cuadro (más la latencia de red) entre los tiempos de inicio de las capturas resultantes.
Si ese nivel de sincronización es suficiente para las personas, es posible que quieran consultar el proyecto compuestopi, que es otro proyecto que escribí sobre picamera para este propósito.
