I started a company that constructed booths which used 70 accurately sync'd Pis with custom PiCams (fitted with lenses) to take pictures of human subjects, for turning them into avatars like this:
At the beginning of the project, I'd barely powered up the Pis I had collecting dust in my drawer. By the end, I was a legitimate domain expert in several niches within niches of Pi dark arts. For example, since Pis do not have hardware clocks, you have to rely on NTP. However, you need to take pains to make sure that each Pi is getting the same amount of voltage or else they will run at different speeds. If you want to power 70 Pis in a constrained space, you need to devise a customized power distribution system with adequate heat venting.
Due to the thin effect, voltage drops over distance, so the distance a Pi was from the power would impact the voltage and therefore the speed. The major breakthrough came when I realized that I could start with a high end power supply outputting 14 volts and terminate each parallel line with a device known as a UBEC. They are used primarily by drone enthusiasts to make efficient use of battery packs.
A UBEC is designed to drop down a supply voltage to 5v without bleeding off the excess voltage as heat. Since this could also describe a fuse, we felt comfortable bypassing the Pi's MicroUSB power supply and attaching the UBEC's pins directly to the top pins on the Pi's GPIO breakout.
That's just a tiny example of the hijinx. The Pi is an incredible tool if you're patient and clever.
What you call UBEC is just a switch mode DC-DC buck converter. They are used everywhere in electronics, and you could probably save money buying general puprose 5V buck converter modules instead of modules made specifically for RC.
Anyway, that's very interesting info about supply voltage affecting Raspberry Pi speed and timekeeping, thanks!
As @Kadin suggested, the UBEC we purchased in bulk was, at the end of the day, a packaged product that had two things going for it. First, it had undergone some degree of QA and we found the results to be consistent, which was a huge deal for us. Second, it came with a 3-pin connector that could not have been more perfect for plugging directly onto the GPIO pins.
It's entirely possible that you could get a cheaper buck converter, possibly for pennies. However, this was not where the money was being spent in our project... and if we had to do literally anything to it to prepare it for use (such as soldering on a pin socket) it would have destroyed any cost advantage.
This is true, although UBECs are also packaged with some filtering caps, and are in a nice heatshrinked package usually -- so I look at it the other way around; packaged UBECs are so cheap, if you can make do with them, it's too easy to just grab them off the shelf and move on with life rather than DIYing it from components.
All depends how many of whatever you're building, I suppose.
However, I cannot state enough that the price of this small component was simply not where the costs accumulated on this project. We geeks have a nasty tendency to over-optimize things that just don't matter in the big picture. You totally nailed it when you mentioned that this device is a packaged (and QA'd) product. The fact that it just slips right onto a Pi's GPIO pins without requiring any further modification is what makes this such a win. If you have to do anything to [70 units of] a component to make it work, you're blowing up any miniscule price arbitrage anyhow.
I think the problem here is not that the clocks are out of sync, but rather that the actual clock frequencies are voltage-controlled.
With the firefly analogy, it's like having one firefly flashing at 1.73513x (random number) faster than it's neighbor - can't easily have them persistently synchronized.
It is visualisation of simple technique to synchronise many clocks without central authority, algorithm is explained on left side of website. You need to turn on 'Nudge thy neighbour" and then wait for fireflies to sync.
Cool idea, but not applicable to our scenario. People would step in and there would be a 3-2-1 count and then step out. There was no flash to sync against. And even if there was, if the devices are all running at different speeds, the sync is moot.
Second: I worked alongside a brilliant team with rare knowledge of geometry reconstruction. We took the 70 images of people, algorithmically removed the backgrounds and then used a proprietary process to create a mesh geometry from the intersection masks of those shapes in 3D space, which all had to be carefully calibrated on the regular. That geometry was smoothed to create a valid smooth human mesh. We then created a texture which would be mapped to the physical geometry of the mesh. All lighting and camera sensors had to be carefully measured and corrected, with ample algorithmic color smoothing along the seams of this texture. Then we ran our proprietary auto-rigging algorithm on the mesh, and exported both a 3JS compatible obj+jpg as well as a Unity bundle. The entire process was optimized to take under 60 seconds. This meant that you could step out of the booth, watch the magic happen, and then immediately put on a Vive and interact with yourself in a mirror using your fully articulated new avatar.
Third: VCs were unwilling to fund something with a hardware component
Sorry to hear that it didn't work out, but it's still an impressive achievement. 60s to produce something that lifelike is incredible. I'm surprised no game companies were interested.
Was any of the geometry reconstruction or texture mapping done on the Pis themselves? I can imagine with 70 of them you’d have a nice little cluster to work with. Cool project, either way!
We definitely tried to do on-board processing, as we were still bottlenecked by the blazing “gigabit over USB 2.0” NIC speed. However, while I have a hunch that the new Pi 4 might be more than up to some of the crunching, the real problem is that the spatial nature of the domain means that each Pi would need access to the sparse clouds and shape masks generated by the rest in order to proceed. We could do color correction and remove lens distortion on the Pi, but that’s it.
Reflecting on this conversation, it occurs to me that I should strongly consider publishing a string of #1 on HN deep dives on what I learned to pay it forward. ;)
I'd definitely read those if you wrote them. I build small machines that use Pi Zeros as motor controllers and I'm a sponge for domain knowledge about using them in practice.
Your point about voltage fluctuation affecting clock speed already has me re-evaluating my current solution. Also I'm really curious about your custom cameras. Thanks for sharing!
Happy to answer any specific questions about the tech that I'm able to answer. I was not responsible for the proprietary algorithms that generated the avatar.
Unfortunately, things didn't end well. I can't actually talk about it.
The business plan morphed significantly during our 4-year run, from 3D pet scanning to location-based branded marketing to what was going to be a big gaming focus (my vote) or glorified 3D emojis (their vote).
I wanted any game/experience that featured characters/avatars to be able to allow people to play as themselves. I didn't get a chance to see that concept through.
https://sketchfab.com/3d-models/pete-swagger-walk-a55d807de1...
At the beginning of the project, I'd barely powered up the Pis I had collecting dust in my drawer. By the end, I was a legitimate domain expert in several niches within niches of Pi dark arts. For example, since Pis do not have hardware clocks, you have to rely on NTP. However, you need to take pains to make sure that each Pi is getting the same amount of voltage or else they will run at different speeds. If you want to power 70 Pis in a constrained space, you need to devise a customized power distribution system with adequate heat venting.
Due to the thin effect, voltage drops over distance, so the distance a Pi was from the power would impact the voltage and therefore the speed. The major breakthrough came when I realized that I could start with a high end power supply outputting 14 volts and terminate each parallel line with a device known as a UBEC. They are used primarily by drone enthusiasts to make efficient use of battery packs.
A UBEC is designed to drop down a supply voltage to 5v without bleeding off the excess voltage as heat. Since this could also describe a fuse, we felt comfortable bypassing the Pi's MicroUSB power supply and attaching the UBEC's pins directly to the top pins on the Pi's GPIO breakout.
That's just a tiny example of the hijinx. The Pi is an incredible tool if you're patient and clever.
What a rollercoaster.