In Soda bottle rocket simulation take 2, I mentioned that the authors of one paper used “a thread wrapped around a Pasco super pulley ($24) which is similar to the Vernier ‘Ultra Pulley’ ($24). The thread-and-pulley approach seems good for getting finely spaced measurements for the first couple of meters (validating the simulation up to burnout), but not so good for measuring max height.”
Since I’m too cheap to buy a super pulley, especially since the vendors don’t even say how wide they are, so I can’t tell whether they’d work with the 1cm-wide photogates that I have, I decided to make my own. Actually, since I’m also lazy, I had my son design and make the superpulley out of Lego.
The pulley was made last night, and we tested it by wrapping a thread around it and yanking as hard as we could. We couldn’t get it to spin nearly as fast as the rocket was predicted to go, but it spun much more easily than I had expected. To get velocity, we took one-sixth of the circumference and divided by the time between ticks—this was smoother than I expected, so we did not try to do any computational smoothing. We also tried hooking up a Lego motor directly to the pulley to try to get a higher speed. The fastest speed we managed this way was still not as fast as we expected the rocket to go. (Trying a belt drive for more speed didn’t help—the Lego motor stalled.)
The first version of the Arduino software was very simple, and just reported each time interval (and equivalent velocity) back to the laptop over the USB line. I noticed, though that the maximum baud rate of the Arduino serial port (115,200 baud) would only let us communicate reliably if the ticks were at least a millisecond apart. At 23mm per tick, this would put an upper limit of 23 m/s on the measurements, but the predicted speed of the rocket was higher than that. So I rewrote the code to record the times in an array, and print (with fancier formatting) the whole array at the end of the measurement. To avoid having a complicated communication protocol, I have the program print the array and reset it to empty whenever there is a tick longer than a second.
One problem with the Arduino is that it has a really tiny RAM—only 2k bytes—and the time stamps in microseconds take 4 bytes each. Because of some overhead, it is not possible to store 500 time stamps, but 400 was no problem. This allows up to 9.2m of motion before the array fills up (at which point everything is printed). Even if a very long string were not a serious drag problem for a rocket, we would not be able to use more than 9.2m, unless we traded off some resolution (say recording only alternate ticks or recording time with msec resolution instead of µsec).
We were not sure whether this pulley design would work with the rockets, so we did preliminary tests this afternoon, launching air-only rockets. (That way we did not have to lug large bottles of water over to the field, and we did not have to figure out how to waterproof the photogate, Arduino, and laptop yet.)
For the first several launches, we ended up only saving the second burst of 400 data points, not the first one, so only saw the pulley spinning down, not the initial acceleration of the pulley.
We had another problem with the first few launches: the sewing thread that we were using snapped where it was tied onto the rocket. The first fix we tried was switching to buttonhole twist, the strongest thread we had brought with us. This was not sufficient. Two other fixes were tried. One was to reduce the launch pressure from 3bar (300,000 Pa) to 2bar and even 1bar, and the other was to use some Scotch tape as a strain relief. The combination of 2bar and the Scotch tape worked, but I’d like to try again without the tape, as I’m not sure it helped. We’ll also try getting some stronger thread (perhaps some surf line from a fishing store), so that we can try higher pressures.
After clearing up the confusion about which data we were to cut and paste from the Arduino serial monitor and getting the string to stop snapping, we were finally able to record a few good launches. For the next set of launches, we’ll use a Python interface on the laptop that my son wrote to capture the data directly from the Arduino and put it into files.
I’m very confused by the data in the 2-bar launches. Why does the blue curve have so much lower initial acceleration than the rest? Was that the Scotch tape strain relief working? Why does the red curve have a curving velocity plot (decreasing deceleration) during spindown?
[UPDATE: 2012 June 11. The predicted burnout height and velocity from the 2-bar simulation are 0.32m and 17.2 m/s. The 1-bar simulation suggests 0.14m and 10.0m/s. The low-pressure launches peaked at about 7–8m/s and the high-pressure ones around 18 m/s. the burnout height looks to be about 0.3m in most of the launch measurements, but this may be more a function of how long it takes the pulley to get up to speed than how fast the rocket is really going. Given the low precision of our pressure gauge on the pump and the noise in the velocity measurements, this is pretty good agreement.]
I’m actually rather amazed that we managed to record accelerations of 130g without snapping the thread. Because the thread can’t really convey any information to the pulley once the rocket starts decelerating, I think we can get away with a shorter thread, at least until we try bottles that filled with so much water that they reach burnout just at the apex of their flight, which may be as high as 10m, based on our simulation.
The burnout takes longer with water in the bottle, so the pulley can get us more data on the flight, but the powered phase is still only about 1/10th of a second, and we won’t be able to observe much more than acceleration to peak speed and peak speed.