1

Engineering a Hybrid Rocket Avionics SystemHyrum K. Wright, Student Member, IEEE Bruce R. Christensen

Abstract—A functional avionics system is vital for the proper operationof a modern hybrid rocket, so proper design of the system is critical. Beforedesigning such a system, the designers should put significant effort into de-termining the functional requirements of the system. The design and con-struction of the system should be as simple as possible. All design decisionsand documentation, as well as implementation details should be stored sothat future designers can easily access them to avoid repeating mistakes.We show the experiences and efforts of a student-run team in designingand building a functional avionics system. We outline the design challengeswe have faced as a student-run project, and how we have overcome some ofthose challenges. We also show how we document our activities so that fu-ture designers can learn from our mistakes. Lastly, we describe our currentsystem and our plans to improve and extend it.

Index Terms—Avionics system

I. INTRODUCTION

IN December of 2003, several students from Utah State Uni-versity and Brigham Young University successfully launched

a hybrid sounding rocket at the U.S. Air Force’s Utah Test andTraining Range. Dubbed Unity IV (figure 1), the rocket flewto a height of 4,400 feet AGL, but not without complications.A malfunction in the recovery system prevented the parachutefrom fully deploying, and the rocket embedded itself verticallytwo feet into the desert sand. The impact caused substantialinternal damage to the rocket and has forced a redesign andreconstruction of a number of systems, including the avionicssystem.

The project has changed quite a bit since the December 2003launch (including receiving a new name: ARES [1]), but thebasic avionics problem remains the same: to design and build asufficiently advanced avionics system on a limited budget, withlimited student resources and time. We describe how we areachieving these goals and where we plan to go in the future. Inthe next section, we outline the requirements for a functionalavionics system and give a brief overview of the work done onthe 2003 rocket. In section III we describe some of the socialchallenges associated with the ARES project, while in sectionIV, we outline the current avionics system design and our futureplans for it. In conclusion, we describe how we will ensure thatothers do not repeat our mistakes.

II. AVIONICS SYSTEM REQUIREMENTS

By analyzing previous launches and talking with other teams,we have developed a set of functional requirements describingdesired system behavior. We divide them into two groups: thosethat are essential for proper rocket function, and those which,though not needed, would be beneficial.

A. H. K. Wright is with the Department of Electrical and ComputerEngineering, Brigham Young University, Provo UT, 84602, USA, Phone:(801) 422–7167, email: ieee@hyrumwright.org

B. B. R. Christensen is with the Department of Computer Science, BrighamYoung University, Provo UT, 84602, USA, Phone: (801) 422–4636, email:ieee@brucec.net

Fig. 1. The Unity IV rocket at the December 2003 launch.

A successful avionics system must meet these three primaryrequirements:

1. Command2. Control3. Data acquisition

The first requirement states that the avionics system must re-ceive commands from the ground station in real time and exe-cute them on the rocket. The second requirement indicates thesystem should control the rocket quasi-autonomously. The thirdrequirement is to acquire data from sensors in the rocket, andto both store that data internally and relay selected informationback to the ground station.

In addition to these primary requirements, it would be veryuseful, though not critical, for our system to meet the secondaryrequirement of mechanical robusness. If possible, the systemshould be sturdy enough to survive minor impacts [2].

In the following subsections, we elaborate on each of theserequirements, potential pitfalls associated with each one, andhow well the December 2003 launch satisfied them.

A. Command

For a sounding rocket to be of any practical value, it must is-sue commands to launch, fly, and deploy proper recovery hard-ware (such as a parachute) at the end of flight for a safe land-ing. Because physical access to the rocket is impractical duringflight, the rocket must receive and act on remote commands sentfrom a ground station.

Being able to receive and execute remote commands in realtime requires some way to physically transmit and receivethose commands. Some solutions require designers to designand build a significant amount of custom hardware and soft-ware. These custom solutions may add complexity to the ratherstraightforward goal of receiving and executing commands.

2

Sensor MeasurementsGPS receiver Speed

AltitudePosition

Tilt switches Apogee detectionPressure transducers Oxidizer tank pressure

Motor pressureThermocouples Motor temperature

Ambient temperatureVoltage meter Battery powerPitot tube Air speedGyroscope Inertial measurementMagnetometer Attitude in relation to the

Earth’s magnetic field

TABLE IPOSSIBLE SENSORY INPUTS

B. Control

Once a command has been received by the avionics system,it is essential that the system execute it correctly. In our specificapplication, the control functionality reduces to being able to:

1. Open and close the valve to the oxidizer tank.2. Initiate the solid fuel ignition system.3. Deploy the parachute at the appropriate stage in flight.Each of these control functions is essential to a successful

flight. System implementers can accomplish them with severalmethods, but they typically use a programmable microcontrollerto drive relays or MOSFETs that control peripheral devices.This can add another level of complexity to the system.

C. Data Acquisition

An otherwise successful flight would have little value withoutcapturing data from the rocket and logging it for future analysis.The avionics system should also send important data back to theground control in real time so that mission controllers are awareof the rocket’s status and can take appropriate action in the caseof a malfunction. Table I shows several sensory inputs that theavionics system could collect.

Obviously, some sensors are more important than others tothe correct operation of the rocket. For example, it is less im-portant to know the ambient temperature than to know the sta-tus of the apogee-detecting tilt switches that determine when theparachute should be deployed. Avionics system designers mustwork with other teams to determine which sensors are essential,and which can be left to a later design phase.

Some sensors produce data more rapidly than others. For ex-ample, the GPS receiver generates values at a frequency of only1 Hz, whereas other sensors, such as the oxidizer pressure trans-ducer, may be sampled much more rapidly. These requirementsmust also be taken into account while designing the system.

Collected but unretained data is not useful to the launch team.Data acquisition implies data retention. The avionics systemmust store the data it collects in an easy-to-retrieve format. Theavionics system should also transmit real-time data to groundcontrollers so that they can take appropriate action if a malfunc-tion is detected.

Each of these data acquisition requirements adds additionalcomplexity and possible points of failure. A failure that pro-duces anomalous values could originate in any component fromthe sensor to the recording or transmission medium. Also, somesensors should have protection against false positives. It wouldbe catastrophic if the apogee-detecting tilt switches gave a falsepositive during flight and deployed the parachute prematurely.A hardware or software debounce mechanism would help to re-duce this possibility.

D. Mechanical Robustness

In previous launches, the avionics system did not survive,even though the landing was relatively light [2]. A good systemwould be built to survive impacts that do not otherwise damagethe rocket. Although not essential for proper flight, mechanicalrobustness is an important secondary requirement that wouldhelp improve the quality of the system over time by eliminatingcostly and time consuming system rebuilding.

E. Analysis of December 2003 Launch

The avionics system for the December 2003 Unity IV launchmet some of these functional requirements, but it can be im-proved. In a detailed analysis of that launch, Jason Holt, theavionics team leader at the time, provides several reasons forsystem failure and discusses lessons that can be learned [2].Holt states that system designers should:

• Do the simplest thing that can possibly work.• Use simple, general-purpose tools.• Remember psychology.• Design prototype systems that are responsive to human in-

tervention.Even after several redesigns and substantial effort by the team

at that time, the 2003 system (figure 2), barely met the functionrequirements described above, and the system designers did notconsistently apply these four principles to the avionics systemdesign.1 In our efforts to build a better system, we show howwe are applying these rules to meet the functional requirementsdefined above.

1 For a more rigorous analysis of that launch as well as a compact history ofthe Unity project leading up to it, please see [2].

Fig. 2. The Unity IV avionics system launched in 2003.

WRIGHT: ENGINEERING A HYBRID ROCKET AVIONICS SYSTEM 3

Fig. 3. Screenshot of the new ARES web site.

III. SOCIAL CHALLENGES

Engineering tasks are rarely accomplished by just one indi-vidual. In his paper, Holt mentions a lack of communicationand camaraderie as a cause of some of the problems that theUnity IV rocket avionics team faced [2]. In designing the cur-rent generation of avionics hardware and software, our team hasencountered several of the same social challenges, and althoughwe are far from perfect, we have made progress in overcomingthem.

A. Team Composition

One of the greatest challenges that we face as an organizationis the composition of the avionics team. The ARES project pri-marily recruits students studying mechanical engineering, whowork on the rocket’s other systems. In contrast, the avionicsteam is composed mainly of students from electrical engineer-ing, computer engineering or computer science backgrounds.The skills required for work on the project are not taught inlower undergraduate courses, and as a result most students arenot able to work on the project until they near graduation, whichcontributes to high turnover.

In an effort to follow the rule of remembering psychology[2], and to establish an “organizational memory” for the ARESproject, we have created a central online repository for projectfiles [1]. This new server acts as a repository for all of the infor-mation generated by the members of the ARES team. It allowsteam members to create and edit web-based documentation, andto store source code and other documents (figure 3). The docu-mentation system can also track revisions of its contents to helpfuture participants see the decisions we are making right now.Currently, the server is used mainly by the avionics team, butthe resources exist to allow other teams to take advantage of it.

We are also making an active effort to attract and recruit tal-ented individuals early in their collegiate careers, making it pos-sible for people to establish longevity in the project so that theycan make more meaningful contributions. By using commodityhardware and familiar software, we also are lowering the bar-riers to entry so that participation does not require knowledgetaught in senior-level courses.

B. Communication

Good communication is essential to the success of an avion-ics team. It is important that current team members communi-cate clearly to each other and to future team members to main-tain project continuity.

Our team meets weekly to discuss our progress. In addi-tion, the ARES web site [1] and an Internet mailing list provideimportant means of communication. The web site provides apermanent, easily-accessible central location to document ourdesigns and activities, while the mailing list facilitates easierdiscussion among busy team members. Online archives of itsmessages will be a valuable resource for future designers.

C. Budget Constraints

Hardware is not free, and even with the plethora of Free soft-ware available, we eventually require hardware to run that soft-ware. Fortunately, the ARES project is supported by a generousfaculty sponsor who provides some resources from his researchfunds. Even with those funds, our resources are limited, and wehave had to be creative in designing and building our avionicssystem without sacrificing our functional requirements.

Fortunately, we have secured donations from generous cor-porations which have helped us to design a high-quality sys-tem. Several companies have offered us discounted rates onparts, and we have also ordered free samples of various elec-trical components in small quantities. We have learned to useparts left over from past systems, as well those available in theelectrical engineering shop.

Even with a limited budget, we are well on our way to de-veloping a usable avionics system for under $1000. Almost allof our components can be used for several system iterations,making the cost of successive generations much lower.

D. Time Limitations

The ARES project does not operate with funded research po-sitions, but rather students participate in it as an extracurricularactivity. Most engineering students are strapped for time due totheir studies, and are hesitant to commit more than a couple ofhours per week to an external project. Some students registerfor a one credit course for participation, but generally studentsparticipate in the project on a pro bono basis.

Additionally, our launch sponsor, the U.S. Air Force, cansometimes impose rather interesting launch timeframes. Wemay get range time on relatively short notice, and must be ableto quickly conjure up a functioning avionics system. The nextscheduled launch is in March 2006, and although it may strainthe current avionics team, we will have a functioning, albeitsimple, system ready for that launch.

A possible solution for our time limitations is simply to havemore people capable of doing more work. As we follow some ofthe guidelines described above regarding team composition, wewill increase the size of the team, and also decrease the stresseson the time of the current team members.

IV. CURRENT SYSTEM DESIGN

The focus of our current work is to design a robust, extensiblesystem that can be used for not only the impending March 2006

4

Fig. 4. Block diagram for the phase 1 ARES avionics system.

launch (figure 4), but for several future launches. In developingthis system, we have attempted to creatively overcome the chal-lenges listed above while creating the simplest possible systemthat meets the functional requirements outlined in section II. Inthis section we briefly describe the design of each major com-ponent of the system, while the next section defines the futuredirection of the ARES avionics system.

A. Flight Computer

The center of the avionics system is the flight computer. Itreceives all the communication from the ground control stationand records flight data. Thus, the flight computer is the mainsolution to the functional requirements of command, control,and data acquisition.

Instead of simply using a data logger or a piece of custom-designed hardware as previous teams had done, we decided touse off-the-shelf hardware based on the PC/104 form factor [3].PC/104 is a compact bus specification meant for embedded ap-plications. We are using a simple, but powerful, PC/104 single-board computer (SBC): the VersaLogic Bobcat [4]. The Bobcatis a SBC based on AMD’s Elan 520 processor, a 586-class pro-cessor that runs at 100MHz (figure 5). Even though we do not

need that much processing power right now, we invested in theboard in order to be extensible for future flights.

This board also allows us to achieve our goals of keepingthings simple and lowering the learning curve for future partici-pants. Because it is simply an x86-based computer, we can pro-gram and interact with it using conventional programming lan-guages and techniques. For instance, the computer runs DebianLinux, which is well-known and well-supported in the techni-cal community [5]. It is Free in that we can modify it to suitour own needs, and it is also free in that we do not have to payany money to use it. Both qualities help us stay in our budgetconstraints while meeting our functional requirements.

We also chose to use a commodity CompactFlash card fordata storage on the flight computer. In the event of a systemfailure, the CompactFlash card can be easily read with com-mercial memory card readers. This makes data retrieval mucheasier and helps to preserve organizational memory and preventus from making the same mistakes again.

B. Communication

To receive commands and send data back to the ground, therocket must be able to communicate via radio. For our applica-tion, MaxStream, Inc. donated two data radios that simulatethe physical layer of an RS-232 link [6]. These radios em-ploy spread spectrum transmission technology and provide au-tomatic error correction and retransmission, which helps keepour system simple. We just plug the radios into the flight com-puter and the ground station and pretend that the two are phys-ically connected. The data radios create an effective rocket-ground control communication link.

C. Ground Control

The ground control station sends commands to the rocket. Italso receives relevant flight data directly from the rocket duringflight to assist flight controllers in making real-time decisionsabout the rocket. Combined with the I/O subsystem describedbelow, the ground control subsystem allows flight controllers to

Fig. 5. VersaLogic Bobcat, the flight computer and heart of the avionics system.

WRIGHT: ENGINEERING A HYBRID ROCKET AVIONICS SYSTEM 5

manually execute any action on the rocket remotely in case of anerror. By building this functionality into the avionics system, weensure that the system is highly responsive to human interaction.

The ground control station consists of a laptop computer con-nected to the data radio to establish a serial connection to therocket. It sends commands to the rocket over this simple serialinterface, and any software on the ground station only exists topresent a user interface to help in sending those commands. Assuch, the system can be run with something as simple as Hyper-Term under Microsoft Windows, R© or something more complexlike a National Instruments LabView interface. This softwarehas not been written yet, and its complexity will be determinedby the time available before launch.

D. Input/Output

The flight computer interfaces with several internal digitaland analog input and output devices to collect data and con-trol the rocket. Various input devices may need to be sampledat different frequences. As the block diagram shows (figure 4),we have identified four major outputs and two inputs that areessential for launch. Some of the other sensors listed in table Imay be included in a later phase, but in an effort to keep thingsas simple as possible for this launch, we will only fly what weabsolutely need.

To tackle this problem, we initially set set out to design acustom board to handle all the inputs and outputs, powered bya small Atmel AVR microcontroller. It would be a mediatorbetween the flight computer and the other devices on the rocket.We even wrote a multi-tasking, preemptive real-time operatingsystem (RTOS) called AROS that would manage the varioustasks that the AVR would run.

Although elegant, AROS may prove a bit more complex thanwhat we absolutely need for our launch in March. Holt, whois also a graduate student at Brigham Young University, hasdesigned a simple board he calls the Gadgetboard that meetsour requirements [7]. We are currently investigating using hisboard, because it provides the functionality that we need, easilyinterfaces with the flight computer, and most importantly, might

Fig. 6. The avionics system enclosure.

Fig. 7. The switching power supply connected to our flight computer.

be the simplest possible solution. We may still use AROS, butprobably not on this flight.

E. Power System

To function correctly, the avionics system must have adequatepower. Various components of the system may require differentvoltage levels. Although we have attempted to design the en-tire system to run at +5V, some commercial components mayrequire +3.3V or +12V. In addition, batteries are heavy and ex-pensive, so we want to be able to use as few as possible.

The center of our power supply solution is a switching powersupply, the Tri-M Engineering HE-104+ DX [8]. This productfits nicely into our existing PC/104 stack (figure 7). It acceptsan unregulated 6-40VDC input and can output up to 12 amps ofcontinuous power at +5V. It also outputs +12V, +3.3V, and -12Vsupplies that can be used if needed. By purchasing an off-the-shelf power supply, we have helped solve our power problemsand eliminate complexity in the system for future teams.

The power supply also allows us to better use our batter-ies. Instead of running the flight computer on internal batteriesalone, we also include external batteries to be used while therocket is being prepared for flight at the launch site. The ex-ternal batteries are two standard automotive batteries connectedin series which output +24V and can source substantial current.They connect to the internal system through a simple power cir-cuit, and can be reconnected at any time should a hold be placedon the launch sequence during countdown.

F. Enclosure

In the early design phases of the current avionics system, wewanted to ensure that the system would survive any minor im-pacts. The previous system was destroyed when the bottom

6

of the parachute can to which it was welded sheared off uponimpact [2]. Fortunately, the overall design of the rocket haschanged significantly since that launch, and the avionics systemnow has it’s own vertical space in the rocket, independent ofother mechanical components.

Our PC/104 stack and other components now live in an alu-minum box which is attached to the airframe by a vertical damp-ening system (figure 6). This system will cushion the avionicsshould a vertical impact similar to the last one occur. Addition-ally, we are using screw terminals wherever possible so that theconnections between components are stable, both mechanicallyand electrically.

Although still in development, we feel that that this versionof the avionics system will be ready for our March 2006 flight,and we expect that it will be reusable for several future launches.Throughout the design of the system, we have made a consciouseffort to use commodity parts to meet our functional require-ments, as well as remember the lessons learned from past de-signs. In addition, we have designed the system so that ad-ditional components can be added in the future without muchwork, as will be shown in the next section.

V. FUTURE PLANS

The future of the ARES avionics system looks bright. InMarch 2006, the phase 1 system will launch, which will giveus valuable practical data that will help us designing our futuresystems. Because we have established a central location fordocument and knowledge storage, we hope that those lessonswill not be lost on future system designers. We have also madea point to use commodity hardware and software that can beeasily extended for future generations of the system.

The Bobcat flight computer is quite similar to a standard PC,and the software that it runs can be easily upgraded. Addition-ally, our bus design allows for multiple I/O devices to talk tothe flight computer over the multi-drop RS-485 protocol, ratherthan the more limiting duplex communication of RS-232. Whennew sensory and operational needs arise, we can add them to thebus with minimal effort.

In the near future, we plan to integrate GPS receiver func-tionality and additional internal sensors, such as temperatureand ambient pressure. We did not include these sensors in thephase 1 requirements because they are not absolutely essentialto launching and recovering the rocket. These sensors wouldprovide useful datapoints for the design team, and so are be-ing considered a phase 2 priority. Even though we may need todevelop custom hardware for these devices, we can now storethe schematics and board layout for that hardware in a centrallocation—something that was not available to previous teams.

Future designers will be able to build the solid foundation ofthis avionics system to meet needs that we have not yet eventhought of. Additionally, by using simple, off-the-shelf hard-ware and software and by trying to avoid designing customcomponents, we have lowered the barriers to entry for futureparticipants.

VI. CONCLUSION

Even though we may not have a complete avionics packagein place for the March 2006 launch, we will have a system that

meets all of our functional requirements, while staying withinour budget and time constraints. We have designed this systemby taking into account lessons learned in past generations ofthe ARES project and with the hope that future generations willlearn from us.

In four months, we have gone from bits of esoteric hardwareand a vague understanding of what the avionics system shoulddo, to a concrete requirements definition, pieces of function-ing hardware, and a document storage system to ensure that ourwork is not lost to future members of the team. We achievedthis by encouraging open dialog with other teams, and by mak-ing sure that our decision-making process is well documentedfor others to follow.

We hope that by carefully documenting our successes andfailures, and by making that documentation easily accessibleto future teams, they will avoid our problems and continue tobuild a quality avionics system on the foundation that we havecreated.

REFERENCES

[1] Brigham Young University, BYU ARES Rocket Project,http://rocket.et.byu.edu/, Accessed on Dec. 10, 2005.

[2] Jason Holt, “How Not to Design an Avionics System,” in Respon-sive Space Conference, 2005, number 3, Also available online athttp://www.lunkwill.org/cv/responsive.pdf.

[3] http://www.pc104.org/technology/pc104 tech.html, PC/104 Technology,PC/104 Embedded Consortium, Accessed on Dec. 12, 2005.

[4] VersaLogic, Corp., Bobcat - 586 Processor Module,http://www.versalogic.com/Products/DS.asp?ProductID=135, Accessedon Dec. 13, 2005.

[5] Software in the Public Interest, Inc., Debian - The Universal OperatingSystem, http://www.debian.org/, Accessed on Dec. 13, 2005.

[6] MaxStream, Inc., 9XStream-PKG-R 900 MHz RS-232/RS-485 RF Modem,http://www.maxstream.net/products/xstream/pkg/9xstream.php, Accessedon Dec. 13, 2005.

[7] Gadgetboard, http://www.lunkwill.org/gadgetboard/, Accessed on Dec.14, 2005.

[8] Tri-M Engineering, Inc., HE104+ DX - High Efficiency PC/104+ PowerSupply, http://www.tri-m.com/products/engineering/he104 plus dx.html,Accessed on Dec. 12, 2005.

Hyrum K. Wright Hyrum Wright is an undergradu-ate student studying computer engineering in the De-partment of Electrical and Computer Engineering atBrigham Young University. He will graduate with aBachelor of Science in April 2006 and plans to pursuedoctoral studies beginning in September 2006.

Bruce R. Christensen Bruce Christensen is an under-graduate student studying computer science and lin-guistics at Brigham Young University. He will grad-uate in April 2008, when he plans to begin graduatestudies.