Using IP connected arduinos to trigger cameras

Question

I am looking to build a 5 DSLR camera triggering system using arduinos over our network.

Currently we have physical trigger cables so that we can trigger each DLSR camera without delay. Even though all the cameras are on the network and running Nikon capture pro, there is a small delay from hitting the "shoot button" in the software, and the camera actually capturing the image. The physical trigger is instantaneous.

Basically I'd like to eliminate the need to run dedicated triggering cable to the cameras, as all I want to run is power, and a couple of ethernet to each camera. I want to have the ability to trigger, and intelligently change camera timings through an arduino or similar ip connectible device, sometimes we may have a single trigger, but slight delays to each shot, like, take one immediately, then two slightly later....

The triggering needs to be done physically, but may be done via sensor, so having an arduino with each camera will give us lots of options.

In the control room we want to be able to trigger any of the cameras with physical buttons, much like you'd see in industrial applications, something that can really take a beating. So from these buttons I would expect to run them all into an arduino, and then that arduino communicates with the others to trigger them.

Signal flow is like this

Button in control room > arduino > internet > arduino > Nikon external trigger cable > Nikon Camera.

Some cameras will trigger at the same time, others with delays.

So my key question is: What is the latency of one ip connected arduino, triggering another?

Answer 1

TCP/IP on Arduinos isn't exactly the best choice for anything real-time. Ethernet timing isn't deterministic, so regardless of any method that attempts to remove jitter or compensate for latency, it will never be spot on.

You mention "Arduino -> network -> Arduino" as your desired topology, in which case I would throw away the idea of using the (very expensive) Ethernet boards and use something designed for embedded systems, like RS-485. As you have total network control, your master module could send a 'shutter' message for every slave to pick up and act upon after message completion. They would all receive it at the exact same time (+/- 1 ns/foot), so jitter and lag would be negligible for any camera application.

Here's a shield that has RS-485 on it, but it's just a single chip (e.g. MAX485 & friends) that you could breadboard.

---

Edit:

How far apart are these cameras? If they're only ~10 meters apart and you want a (light?) sensor that goes to each one, just wire up a sensor+shutter+power cable and run them to the same Arduino. It should only be 4-6 wires; buy some good connectors and it should be painless to tear-down and set-up. You might be able to get away with significantly longer cables even, depending on the sensor, etc.

Answer 2

To answer your key question, the latency of one IP connected arduino to another is almost completely dependent on your computer network. The arduino hardware and trigger will add some latency, but it can be treated as 0 compared to the amount of latency that a computer network and physical trigger hardware will add.

Typically in medium to large size corporate networks I have seen a latency of anywhere between 3ms and 50ms.

If you are wanting all of your cameras to trigger at the exact same time you might want to consider a more sophisticated approach to deal with unpredicted delays on the network. Every so often you can send timing information to your trigger arduino. Over time you can start to average out the jitter on the network. Jitter being the difference between the latency of one packet to the latency of other packets at different times. You should be able to get "ok" time with this method, then when you want your cameras to trigger, you send a packet saying what time stamp you want them to trigger at.

You can also add a return packet which the user control side ardunio would receive. With a bit of work you can use the round trip time to perfect your timing even more.

If you don't care about having them all go at the exact same time, you will just need to keep your trigger packet, and any associated overhead, as small as possible.