Skip to content

I couldn’t resist

Well, yesterday was my last flapping day. So Thursday night I came in and decided to fully automate the thing, as was my original dream. I inspected the new belt and it seemed to be holding up much better than the previous one.

They are different types of rubber; both with fibers embedded in them for extra strength. Of course I don’t know what the rubbers are called, but the one that broke looked like black rubber whereas this one looks like shiny plastic.

Anyway, if you’ve seen the movies, you can see that the first half stroke of the “C2” program ejects some sort of vortex. For my ultimate automation experiment, I figured I should try to capture this ejection of vorticity in as much detail as possible.

As before, I wanted to average several “runs” together to get a higher resolution data set. I can in theory do this because the mechanical movement of the flapper is more or less repeatable and because the motor controller I “made” out of an Atmel AT90USBKEY was designed with this in mind. When I tell the controller to “go”, it sends out a trigger pulse and a precise time later starts the flapper moving. This trigger is then used by the timing program I wrote (which drives a National Instruments PCI 6602 card) to spit out a “burst” of triggers at 7Hz which ensure that the 3D camera is perfectly synchronized with the laser—in other words, a $600 flash sync chord which requires a computer to operate.

In my previous experiments, I would set the delay between receiving the trigger from the motor controller (“trigger out”) and the start of my burst manually, then run that 30 times, and when it finished, I would change the delay and start again. I did four different delays for “C1” and “C2”, so that in the end the assembled movie will look like the camera was 28 (7 * 4) frames per second instead of just 7.

So in this ultimate automatic concoction, the delay between trigger out and burst start is set by the Python script which does the recording. There are 10 different delays, so that the camera will seem to be 70 frames per second in the final movie. Each “phase” as we call it is again repeated 30 times, so now we have 30 * 10 = 300 repetitions of the flapper. Each repetition is 21 frames; I wanted to only record the first stroke and a few more frames to see where the ejaculation ends up and if it changes shape (and hopefully 21 frames is enough, since I haven’t processed it yet). So the total number of images for this experiment was 21 * 300 = 6,300, each is 24 megabytes, so we’ve got 6,300 * 24 = 147.6 gigabytes of images alone. I suspect by the end the processed data will be around 170 GB, and probably will take one or two months to process (one month if I coordinate several computers, two if I only use one). Hopefully.

For full automation I also wrote another script which would watch the output directory and whenever a run was finished it would move it to another computer. And in theory this script could have also started processing, but all the computers in here are still choking from the massive amount of data I produced this week so there was no way it would work out.

In the end, I only had to manually restart it twice, both times because of a weird recording glitch where the recording software sits there forever waiting for a frame that will never arrive.

Even if this last data set is no good, I’m happy that it was “fully automatic”.

Post a Comment

Your email is never published nor shared. Required fields are marked *