Back Story (tl:dr – skip to Design)

Early in my freshman year in college I got interested in attitude control systems (ACS) and genetic algorithms after reading this paper. I was disappointed, however, that the author had only tested his theories in simulations, and decided with a couple friends to rectify this. The end goal was to prove the ability of evolutionary computation to automatically generate a controller for a finless rocket through a live test. It would, of course, work the first time.

The only thing standing between us and scientific glory was the need to build a rather large rocket (no problem!), create some kind of inertial measurement unit (no doubt a simple matter!), and develop an attitude control system (How hard could it be?). In retrospect, it was only by vastly underestimating the complexity of the task that we were able to justify attempting it.

So, armed with our ignorance and a little spending money, we began work on what would turn out to be the longest, most expensive project I’ve ever worked on.

We considered several different methods of attitude control, but eventually settled on a cold-gas ACS that would push the rocket one way or another using jets of compressed air. We figured we could use paintball tanks and electric solenoid valves, but the ACS began to look rather complicated and we decided to work first on building an IMU (which somehow seemed much simpler).

None of us had any real electronics experience. The only thing I’d ever built that had actually worked was a simple electronic ignition box for fireworks in high school. Nevertheless, we began researching different methods of attitude determination and began experimenting with MEMs accelerometers and gyro rate sensors. We even managed to get an undergraduate research award from UTDallas to help with funds. Over the course of the next year we built and launched several small high-power rockets, and learned quite a bit about microcontrollers and basic electronics. Our efforts towards building a full 3-axis IMU, however, led us only to one simple conclusion: Attitude determination is hard.

While we completely failed at producing any kind of usable, accurate attitude determination system, we were able to accomplish quite a bit. We started a student organization, built a cheap cellular GPS tracker, made a large pneumatic cannon for testing impact-resistant flight recorders, and even managed to send GPS data down from a rocket during a launch and plot it in Google Earth in real-time. And, after a last-minute all-nighter putting together a poster, we even placed 2nd at the UTD Undergrad Research Awards poster competition.

The story could easily have ended there. Without a functioning IMU, and without further funding to build an ACS, the project would likely have been replaced by something less interesting and I would have gone on with my studies in cognitive science. However, I was bugging Dr. Greg Earle–my physics professor who had recently had an experiment fly on a sounding rocket out of Wallops Flight Facility–with questions about our project, and almost as an afterthought he said, “I think they might still do internships out at Wallops. I’ll check.”

As fate would have it, they did indeed still offer internships, and the following summer I found myself writing software for the Attitude Control Systems group there. I would intern there three times over the next few years for a total of 13 months. One of the other guys from UTD, Trev Sheerin, also made it out to help finish some simulation work I’d begun. The guys at Wallops were even kind enough to let us run an air bearing test, where one of their attitude control systems was controlled by neural net code we wrote.

Despite our most valiant last-minute efforts, the neural net code simply took too long to run and, even though the test looked good from the flight computer’s point of view, the gyro lost track of where it was pointed. This caused the ACS to point at all sorts of things, but not what we had intended it to. This was at the very end of Summer ’09, and we had to go back to school before we could make any improvements. Even when we returned the following year, it seemed unlikely that we would get another chance. Procuring an ACS for experimental tests and setting up the air bearing–all to satisfy the curiosity of a couple interns–was something we were extremely lucky (and grateful) to get to do once. The guys at NSROC are awesome, and they certainly would’ve let us try again, but we didn’t want to have to bother them every time we had a new idea. We wanted a way to test quickly, to test often.

And so it wasn’t until Trevor and I were out at Wallops this past summer that we started thinking about building an ACS again. We realized that, with the knowledge we’d gained there at Wallops, it really shouldn’t be that hard. Most of our original design decisions actually seemed valid, and having an ACS at home would allow us to continue experimenting with neural networks for attitude control. Indeed, having a cheap ACS platform that could be quickly modified and cheaply run would allow us to test all sorts of interesting things. Finding ourselves without much else to do in our spare time, work began in ernest. One of the other ACS interns, Adam Hunter, who had more (read: not zero) experience with pneumatics also agreed to help.

Design (tl;dr – skip to Testing)

Early designs were somewhat rudimentary.

We wanted to take a rapid-prototyping approach to building the ACS. That is, we wanted to build the simplest version that could possibly work and not get bogged down by chasing performance we didn’t need. We also didn’t want to be too concerned with performance in general. We knew we weren’t going to get amazing performance without spending tons of money, and that was ok. Most of the things we wanted to test could be tested with a pretty rough ACS. It didn’t need to work well, it just had to work.

Method of Suspension
The first major design task was to figure out how we would suspend the ACS in such a way that it could move freely. Normally, the ACS would be mounted to a spherical air bearing which would be floated up on a cushion of gas. We figured we could do something similar using pressurized water like what is done with spherical stone fountains. Making spheres, however, turns out to be hard. We also weren’t convinced that we would be able to drill a hole or set of holes perfectly through the center of an existing spherical object. All  in all, the spherical bearing method seemed rather complicated, and we decided in the spirit of the project to go with the simplest possible solution: hanging it by a cable.
This would end up preventing us from doing any kind of roll control because the ACS couldn’t spin, but it greatly simplified the setup and let us get to work on actually building the ACS. We could have spent months building a usable air bearing, and in retrospect going with the simplest choice here saved us a lot of time and money.

Thrust Requirements
Before we started designing the pneumatics system, we wanted to get a sense of what kind of force we would need out of the gas valves to push the ACS. We knew that an angular acceleration of 0.05 rad/s/s would give us decent coarse control (which is all we were after), and calculated that for a homogenous 3′x6″dia cylinder weighing 50lbs, we would need only need 0.075 pounds of force out of our thrusters to get that same acceleration. This really reassured us that we didn’t need very high gas pressure or flow rate to make this thing work.

Pneumatics

The biggest design decisions to be made were in choosing the gas tank, pressure regulator, and electric valves. The pneumatics system itself is dead simple, but figuring out the details of things like tank capacity and regulator pressure range took some time.

Tank
We decided to go with the early design decision to use paintball tanks to store the compressed gas. Used tanks are relatively cheap, and getting them refilled is pretty easy if there’s a paintball shop nearby. We weren’t sure how much gas we would need, but again we decided not to get too caught up with worrying about performance and bought a middle-of-the-road  48cu 3000psi tank from Pure Energy. It also turns out to be more economical to buy several small tanks than one large one, so we could always go that route if we needed more gas.

Pressure Regulator
The biggest design decision we had to make for the pneumatics system was what kind of pressure regulator to use. The paintball tanks stores gas at up to 3000psi. This gets reduced to 800psi by a regulator built into the output stem. Finding valves rated for 800psi was difficult (and expensive). We wanted to regulate this down somewhat, but were weren’t sure what output pressure range we would need to get the force we wanted. Being completely ignorant of fluid dynamics and pneumatics in general, we consulted one of the other interns who seemed to know more. He did some calculations and concluded that, assuming several simplifying conditions, the output force would be very roughly equal to the output pressure times the exit area. From this, we were able to decide that an output range of 0:100psi would probably be a safe bet for our regulator. We got really lucky and were able to find one on ebay for $5.

Valves
Having decided on what kind of output pressure we needed, we could figure out what kind of valves we could choose from. We found two different valves on McMastercarr that seemed to fit our needs.

The first was a stainless steel valve (McCastercarr #5077T13). This valve was more expensive ($64.76), but seemed more durable and we thought might have a faster response time.

The second valve that caught our eye was a delrin valve (McMastercarr #7876K11). This valve was less expensive ($42.48), lighter, and had a much larger flow coefficient than the stainless valve. Being generally unsure about which valve to get, we ordered one of each for testing. When they arrived, we found the delrin valve to be smaller, much lighter, and that indeed it did flow significantly more gas for a given pressure than the stainless valve. We figured flow rate and cost were more important factors than external durability, so we decided to go with the delrin valve.

Electronics

The electronics ended up being pretty simple, and consited of only four primary parts:

• Voltage regulator board – Accepts the 12V from the battery and regulates it down to 5V for the Arduino
• Arduino – Reads the gyro sensor and runs the flight code
• Relay board – Accepts the 12V from the battery and four 5V signals from the Arduino. When the Arduino sets one of the digital valve outputs to high (+5v), the relay opens and allows high-current 12V to switch the corresponding valve open.
• MEMS Gyro – Small angular rate sensor

Controller
We had worked with PIC microcontrollers in the past, but I ran into issues getting everything to work again and decided to look for a simpler, easier option. I’d heard numerous mentions of Arduino in other project write-ups, so I decided to order one and give it a shot. We wrote some simple test code while waiting for it to arrive, and when it finally came in we were amazed to find that A) it took less than ten minutes to get the build environment working, and B) our test code actually compiled the first time. It was clear that Arduino was a much better choice for rapid prototyping, and I’ve nothing but praise for it.

Valve Driver Board
The valves we wanted to use required 12v at 1.2amps to open. This is more power than a microcontroller can source, so we knew we had to build some kind of relay board to switch power directly from a battery.

MEMS Gyro Sensor
We initially tried using a +-180 deg/s sensor, but it really wasn’t sensitive enough to catch the mostly slow rates the ACS saw. We switched to a  LPR503AL +-30 deg/s sensor and had much better results. So good, in fact, that we were able to estimate change in pitch/yaw by simply integrating the value from the gyro. I’d always assumed that the integration drift for MEMS sensors would be too high, but it actually works surprisingly well.

Construction

The components of the ACS were mounted to wooden decks cut from 1/4″ plywood. The stack of decks was held in place by four allthread rods.

Testing

Here’s the most recent set of tests using just the rate sensor for attitude estimation. This was before we got the bluetooth modem, so you can see the USB cable still attached for monitoring purposes.

Additional Info & Future Directions

There are lots of directions we could go with this. I’d like to look into vision-based control and also a couple cool things involving remote control via Wii-mote. Below is a link to a report Trevor and I did for a school project, including more info on the control law we came up with, how we calibrated the MEMS sensors, and how we determined the spring constant of the suspension cable.

RPACSFinalReport.pdf

I think we could also miniaturize the system to fit inside a 6″ dia x 18″ tube–something launchable. I don’t think I’ve ever seen an amateur rocket with a full pneumatic ACS, but I think it’s definitely doable.

Sadly, I’m entering my last semester of undergrad at UTD and expect to be busy with less productive, more important things. Work on this project will probably continue this upcoming summer. However, if you’re local to the area and you’d like to use the ACS for something, by all means let me know and I’ll be happy to lend it out for science.

Special Thanks

We had an enormous amount of help from many people in working on this project, and it would be nothing less than petty theft if their contributions weren’t recognized here. Firstly, thanks to Dr. Greg Earle and Dr. Phil Anderson at UTD for supporting us in our initial work back in 2008–this project would certainly have fizzled out if we hadn’t had your help at the get-go. Big thanks also go out to Nate and Nick Wroblewski, who allowed this tomfoolery to be built in their garage and offered key design insights (the use of brake line & a sliding mounting point assembly were their ideas). Also thanks to Ashley Wroblewski, who provided strategic nutritional support throughout the summer. Also a huge thanks to the guys down in NSROC pneumatics, Mike Scott and Time Wilson. We certainly would not have been able to get the pneumatics system together without your help, so thanks for letting us pester you all summer. Also thanks to Josh Laub for doing the nozzle flow calculations for us. Finally, thanks to Jan Jackson and all the other guys at NSROC who supported us and helped us along–you know who you are.

I found a pack of neodymium magnets at Wal-Mart that looked like they’d fit inside the spokes of the rotor, and I bought some 26-gauge wire at a local electronics store. The magnets fit inside the rotor spokes, and I temporarily wedged them in using folded paper. This worked well enough that I would never bother to glue them in. Four magnets could be placed inside the spokes on each side of the rotor, giving eight magnets total. I arranged the magnets so that their polarities alternated every quarter turn.

Next, I used a power drill and a screwdriver handle to wind a pair of test coils. The coils were connected in series, taped to the top and bottom of the generator, and the rotor was spun up. Sure enough, a sine wave appeared on the scope.

After experimenting with different numbers of winds, I determined that a coil with 320 winds would yield between 3 and 5 volts, depending on how fast the rotor was spun. I wanted a pair of coils that could easily drive a simple linear 5v regulator for USB charging, so I figured two of these in series should work. I made a simple rectifier/5v regulator circuit and scalped a female USB connector from something less interesting.

Here’s a rough diagram of the electronics showing the coils and rectifier/capacitor arrangement. This was actually done in a circuit simulator applet I found at http://www.falstad.com/circuit/. I would highly recommend this program to anyone new to electronics, as it really does a good job of showing how current flows through various circuits.

The coils themselves only output 1.9 Watts at maximum rotor speed (0.25A at 7.5V), but I think this could be greatly improved by someone who actually knew what they were doing. A more efficient switching regulator and stronger, better-placed magnets would be great improvements.

The first case was pretty heavy, so the second improvement I wanted to make was to route out both insets a little deeper, allowing thicker foam. This ended up reducing the weight from 1.4kg to 1.1kg with the Kindle inside.

Another major improvement was cutting the Kindle inset big enough for foam around all four edges.

I also wanted something that would keep the Kindle from falling out of the case when it was open. I settled on brass turn buttons and routed out insets for them in all four corners using a dremel. This ended up looking really nice, but it’s a little inconvenient to have to move the top turn buttons to turn the thing on and off. Also, if I leave them engaged when I close the case, they keep the foam on the front side from doing any good. I’m sure there’s a simple solution for this, but I haven’t come up with anything decent yet.

After the paper was removed the little holes were visible enough that I could score the design using a small, flat tool. Unfortunately, the design didn’t end up being quite as visible as I would have liked.

I found a guy that does laser engraving, so I’m going to give that a shot. All in all I think this case is a major improvement over the first one. It’s still a little heavy, and the hinges aren’t aligned quite right, so there’s still some improvements to be made yet, but I think I’m almost done here. A friend of mine has commissioned me to make one for her dad, so maybe this project will even pay for itself!

I was never very good at drawing things without actually being able to see them, so the sketch wasn’t really quite what I’d imagined and the idea continued to fester. Later, while working on an idea for a reverse-geocaching device, I was trying to find the point of land that was the furthest possible distance from me. Turns out one of the island that was closest to being on the opposite side of the Earth from me (and one of only three antipodes for the U.S.) was Ile Saint Paul, and it just happened to look similar to my sketch.

A couple years later the guys over at Unity3D made part of their game development application freely available to the public (thanks guys!). Included in this development environment were lots of really cool tools for designing level maps and modeling terrain. I spent the next few days compulsively modelling the island that had been rolling around in my head for so long.

But the best part was that once the map was created, Unity, being a game engine, happily let me run around on a beautifully rendered version of my brand new island.

You can “listen” to a picture pretty easily. By simply copying and pasting the contents of a bitmap into a .wav file, you can trick a program like Audacity into “playing” an image file. Here’s what the Mona Lisa sounds like using this method:

MonaLisa.bmp as .wav

MonaLisa.mp3

While interesting, I wanted something that was a little more musical. I wanted something that sounded nice. For a while I played with the idea of trying to make an image that, when converted into a .wav in this way, would sound interesting. I quickly discovered that the color content of the image was much less important than the its spatial frequency content. That is, while a single vertical red bar and a green bar might sound identical (a single tone), two bars stacked next to each other would sound very different (a doubling in frequency). This is probably better illustrated by the image below:

One of my first attempts to draw something that sounded interesting. The image has been rotated 90 degrees, and so gets played from left to right.

totem.mp3

Source: Wikimedia Commons

Our eyes produce these ‘emergent’ colors by both being sensitive to intensity and by treating combinations of colors differently. To try to imitate this, I wrote a java program using JFugue to translate the pixels in an image into a midi sequence of three-note piano chords. For each pixel, the three values for red, green, and blue get mapped onto corresponding sections of the piano.

It’s not perfect, but the results were actually pretty interesting. I had to downsample the images heavily so they could be played in a timely manner (640×480 pixels at 2 pixels per second would take about 42 hours to play).  Here are some sample images and their corresponding ‘songs’:

MonaLisa.midi

blueflower.midi

The rhythm you hear in the Mona Lisa midi is actually due to the padding bytes used in the bitmap format the image was saved in. These padding bytes occur at regular intervals ever few pixels, and always have the same value. This causes the rhythm effect your hear. It had never occurred to me that a file format might have a rhythm, but by all accounts it makes sense. The padding bytes were removed in the blue flower midi.

At any rate, it was a really interesting project and I hope to get more time someday to keep playing with it.