RPI wired network

A few remarks...

Others suggest looking into  "ssh". SSH is an encrypted protocol that takes a few hundred miliseconds to initialize the protocol. For a human barely noticeable, but becomes important when you want twelve cameras to snap a picture at the same time. If the master-pi is CPU-clogged starting up all the SSH connections, you'd effectively start them one-after-the-other, resulting in more than  a second spread in time-when-picture-taken.

Others suggest using ethernet to connect them together. A 16 port hub is a heavy thing to carry around. You want it portable. For that situation I would recommend using pi zero's. Maybe have the master be a pi3. Depending on how "convenient" you want things, you could get the original zeroes.

Then you would connect a physical wire along all the slave pi's and when that signal goes high, all pi's take a picture as fast as they can.  With no networking between all of these, getting the pictures "back to base" is going to be a problem.... You'll have to remove all 12 SD cards and read in the pictures from there.

More convenient would be to use the zero-W as the raspberry pi's for the cameras. Now you have a network and you can gather all the images in one place through the network that they share. I would not use SSH to tell other pis to take a picture. I would configure the master as a WIFI access point, have all the slaves connect to that, and then have the master broadcast an UDP packet to a port that you've assigned.  This requires just one thing-to-do from the master, and all the slaves are free to do their now-go-get-a-picture in parallel.

I would use "nc" netcat, to recieve the trigger command.

If you are sure that nobody can access your access point, (i.e. the password is really secure, e.g. generated by pwgen -s 16 1), then the "accept a trigger" can be as simple as: nc <options>  | sh . Now the slaves will execute all the commands you'll send to them. Controlling WHAT EXACTLY they do is easy to manage in one place on the master. On the other hand, this is  a security risk. It would be better to at least do something like "while read a ; do ; take-a-picture; done" in a script (fed with the output of nc), so whenever you get SOMETHING from nc, you will just take a picture instead of executing whatever command  was sent. A hacker may now trigger your camera instead of immediately having complete control over your raspberry.

Finding a power-system for all of this might prove tricky. Twelve cameras going into "take a picture" mode at the same time might pull a quite significant surge that is no problem if it is just one, but it might become a problem with twelve at the same time.

Consider using hugin to stitch the images together.

Although an overlap of 50% is recommended, when your cameras are at a fixed position you can probably get away with a bit less. As the FOV vertically is 48 degrees, I would rotate the cameras 90 degrees so that the 62 FOV ends up being vertical. And the 48 degrees FOV times 12 is over 580 degrees, about 40% more than 360, so you'll have 40% of overlaps. This means that you will use at least SOMETHING of each camera so you can't tolerate having one camera fail. That's too bad. At least I think you can get great pictures without any complicated trickery with the optics. If you think you can improve on the setup, you can still go ahead.... If you experiment with one camera you might end up figuring out that changing the lens causes a reduction in quality because of dust on the sensor or distortions you didn't expect.

Good luck! Let us know how you're going! We'd like to see some of your pictures once you are starting to take pictures!

Hi,

Thank you very much for your detailed suggestions.

I am not sure to uunderstand correctly everything.but your remarks about synchronization and lens  may be crucial for my project.

SSH connection it is impossible to use due to delay in initializing the protocol.

The ethernet connection has the issue in weight and size you mentioned. I do not know weight and size of RPi and of a 16 port hub.

For me "portable" would mean about 1 or 1.5 kg in weight and about "half of a shoebox" in size.....

Having the pictures in 12 different sd cards would not be an issue.

I do not know anything about wifi connection so I can not understand the way to connect you suggested. But I could instruct myself on that. I did not consider wifi connection in the beginning because in a forum about a rig of 6 (or more) action cams I read that wifi connection is not reliable and may imply a delay in synchronization more than tolerable...Not sure I understood it correctly.

The lens: I would like to take pictures 360° x 120° (i.e. a sphere without a 60° "black hole" on the ground).

Using the standard lens implies more than 20 cameras: too much...

I will order one RPI and one cameraboard v2 to test and learn, anyway. Then, I will decide what to do...

All that will take some time I am afraid.

Any hints, remarks and suggestions will be much appreciated and a great help.

Thank you.

Best regards,

Giuseppe

For your first raspberry pi, I would recommend a fullblown RPI3. You could put that one as the master later on if you can't afford to keep the first one on your desk.

If you photograph DOWN too, then you usually have whatever the stuff is standing on (the tripod) in view too. Unless of course you put the stuff under a drone or balloon. Because the ground under the picture is not that interesting, I was assuming you would not need to photograph it.

You can practice stitching by going out and taking pictures with anything that can take a picture. Like your smartphone.

If the WIFI turns out not to be reliable enough, you can always still use a GPIO to trigger all the slaves.

For your first raspberry pi, I would recommend a fullblown RPI3. You could put that one as the master later on if you can't afford to keep the first one on your desk.

If you photograph DOWN too, then you usually have whatever the stuff is standing on (the tripod) in view too. Unless of course you put the stuff under a drone or balloon. Because the ground under the picture is not that interesting, I was assuming you would not need to photograph it.

You can practice stitching by going out and taking pictures with anything that can take a picture. Like your smartphone.

If the WIFI turns out not to be reliable enough, you can always still use a GPIO to trigger all the slaves.

Thank you very much.

i will buy a RPI3 with cameraboard v2 and practice and figure out most of the things I need 8included GPIO which I had never considered)

I do not need to photograph the ground with the tripod: that would add many problems and it is not interesting.

But I would need (not always but in many scenes) to photograpph the ceiling or at least to have a vertical field of view of  about 100 ° or more.

Using the standard lens that means I need two camera in portrait mode (they have 62° FOV which I could overlap 20° and obtain a 100° Fov when stitched, not sure it is enaugh) x 10 (to cover 480 degrees less the overlapping areas, not sure it is enaugh). At least 20 cameras. Too many to manage.

I have found this one: https://www.bluerobotics.com/store/electronics/cam-rpi-wide-r1/ which has a mount that, additionally, allows to change the lens with other M12 lens, but that will be expensive and nothing I know about quality.

I will first get to know a bit about RPI and the cameraboard and then I will decide...