5
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ Are you wanting multiple cameras to take a picture at the exact same instance? Or are you just looking for a low latency trigger over IP? \$\endgroup\$ – Kellenjb Oct 22 '10 at 5:19
  • \$\begingroup\$ What are these "slight delays"? Are you trying to synchronize them so that, e.g. all the shutters are open for a strobe? \$\endgroup\$ – Nick T Oct 22 '10 at 14:00
  • \$\begingroup\$ What dedicated triggering solution are you using now? It seems odd that you would be getting delays like what you mentioned on a dedicated trigger line. \$\endgroup\$ – Kellenjb Oct 22 '10 at 15:20
  • \$\begingroup\$ Kallenjp: The cameras don't have to take the picture at the same instance, but just need to be responsive so that they capture the action as fast as possible after the button is triggered. Nick T: The slight delay is when you trigger the camera through remote capture, when you click the "release" button on the software it doesn't take the picture instantly, but if you trigger the shutter release manually (or as we do at the moment with an extension to the cable trigger release). \$\endgroup\$ – Simon Oct 25 '10 at 8:43
3
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ The cameras are a variety of distances from the control room, some are 10m, others are about 75 meters away, line of site, but more like 100-150 meters cabled. \$\endgroup\$ – Simon Oct 25 '10 at 8:41
  • \$\begingroup\$ I like the idea of using 485, but wanted to get around having to run dedicated network, just for triggering. I'd like to be able to put a camera almost anywhere and either plug it into network at that location. Some of the locations have fiber to them, and power, but no copper. If I end up having to install copper to each camera location, I would probably use the same method that we currently use to trigger, but have an arduino sending delays and pulses to relays to trigger the cameras. \$\endgroup\$ – Simon Oct 25 '10 at 9:04
  • \$\begingroup\$ +1 on using RS-485. I've used the MAX485 chips with arduino before and it was quite easy. I also wrote a blog post about it: tmatthew.net/blog/long_distance_serial \$\endgroup\$ – tybro0103 Jun 27 '11 at 19:36
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I think it would be better if the devices referenced a world time through a protocol like NTP and then you broadcasted a future time(just need to give a half second for message propagation) and then they could sync very closely. \$\endgroup\$ – Kortuk Oct 22 '10 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.