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.
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.
Pretty nice project! But I wonder why you use relais to drive the valve instead of high power (MOSFET) transistors. The additional “lag” introduced by the relais makes the control loop more unstable (at least in theory
.
Another idea for a nice test setup: put the whole thing upright mounted on a stick (like an inverted pendulum) and let ist self-balance using only the thrusters. This would somehow resemble the actual usage in a rocket.
I decided to go with relays largely because I’d used them before. I’m no EE, and I hadn’t used MOSFETs before so I was a little weary. You’re absolutely right though, I think MOSFETs would be a much better solution. I’ll add it to the (long) todo the list of improvements!
As for the vertical pole-balancing setup, I’m not sure that would accurately simulate what we’re looking for. The balanced pole would tend to fall over rather than let the system rotate freely as it would in space. It’s an interesting idea though, and we came up with lots of odd ideas about how we could suspend this thing before caving to simple cable suspension. It was simple & cheap, but it definitely isn’t perfect and I would really like to look into a better solution sometime.
The easiest setup would be using a logical level MOSFET. They are a bit more expensive than the “normal” ones but directly connect to uC output pins – no EE degree required
. You can use the same schematic as you use now for driving the relais. Just replace the relais in the schematic by the valve coil and connect the high side to 12V instead of 5v (open collector design) – that’s all. The clamping diode D1 should be a fast and high voltage type. Schottky diodes are best vor this purpose.
For the pole-balancing setup – yes, this doesn’t simulate an object floating in zero gravity. But I think it will loosly approximate the boost/ascend phase of a rocket. Of course the pole would tend to fall over – that’s what the control system should try to work against. This would be a test for the stability and performance of the control system but yes – probably not the most accurate simulating of a “real” mission
So I’m curious about the equations. For example.. I assume it has less influence on attitude control the higher up (and less atmosphere) you have.. right? For example.. how much control would you end up having in a rarified atmosphere.. at say 100k feet?
Tweeks
Actually, these kinds of cold-gas systems are used quite frequently in rarified space environments, largely with success. The majority of thrust comes from the momentum of the gas particles being pushed away from the vehicle. Whether or not you’re at 100 feet or 100k feet, you’re still pushing mass away from you. For subsonic gas flow, I believe the amount of thrust is roughly equal to the pressure of the gas (about 30psi for our tests) multiplied by the cross-sectional area of the nozzle. A rarified environment is actually nicer because you don’t have other aerodynamic forces acting on the vehicle.
Hey There,
This is a great project, we had a student team working on doing this in 2007. They got as far as building a working inertial measurement unit (IMU), but didnt get any progress on the thrusters. We where only looking at roll control though, and where going to be using CO2 and high pressure NOX solenoids.
As others have mentioned you might want move away from the relays, they will introduce a failure mode during rocket flight (acceleration or vibration triggering).