SPARTAN was an R&D project from Sierra-Nevada Corporation for a tactical military UAV system.  I assisted with several aspects of this project, including design of the onboard power system, flight termination, and problem solving.

• Power system

A versatile power system was developed all the way from requirements to I&T, which could run the aircraft off either the ultra-fast rotational output of the ducted-fan engine, or in the event of engine failure, on backup batteries.  The system provided regulation and on-off control for payload and critical flight systems.  A bank of status LEDs indicated which power source was in use, and whether all voltages were within acceptable limits.   This system was even adaptable to a customer request to use the generator as a motor to start the ducted-fan engine.

• Flight termination

Per requirement, flight termination features were built into the power system.  Several channels of servo control signals generated by the power system microcontroller were used to cut off fuel flow to the engine, and release a recovery parachute.  Termination could be initiated by the main avionics system (via either autonomous or direct command), or by a completely separate radio system using a coded signal (the iconic “big red button”).  Logic was built into the system to reduce the possibility of inadvertent activation, while ensuring that the intended signals were promptly applied.

• Problem solving
  

In addition to designing an effective RF and DC power-grounding architecture for the aircraft, several black boxes were built to solve issues that were preventing effective flight testing.  These boxes allowed standard radio-control systems to interface with various parts of the aircraft and test fixtures.  At the core of these boxes were microcontrollers programmed to input, process, and regenerate servo actuator signals in real-time.  These signal translators solved several difficult problems in an inexpensive and elegant way.

As these were flight-critical systems, considerable care was given to circuit and code correctness, reliability and speed.  Particularly gratifying was the fact that the onboard power system, based on a four-layer PCB and fine-pitch surface-mounted parts, worked perfectly the first time it was assembled.

• Sierra-Nevada Corporation website

Individual final project, Interplanetary Mission Design (ASEN 5519)

As a final project for the Interplanetary Mission Design course taught at the University of Colorado, I designed a mission to Jupiter.  This entailed choosing an appropriate gravity-assist course by evaluating planetary alignments over the mission time window for lowest (energy) cost and highest (velocity) return.  Once the transfer course was selected, a useful science orbit around Jupiter was chosen and targeted.  Finally, for extra credit, the transfer course was evaluated for possible asteroid encounters along the way.  Using a JPL database, the spacecraft was found to pass near four asteroids during its transfer to Jupiter, though additional maneuvering would be necessary to create close flyby encounters.

This project was particularly rewarding.  Before entering the course I had been fascinated by astrodynamics but nervous about the mathematics involved.  However, I was extremely gratified by the talent of the instructor (George Born) and his veritable army of TAs.  This project also got me deeper into Matlab and Satellite Tool Kit (STK) than I had ever been before.  STK turned out to be very useful in not only verifying Matlab results, but also in producing visualization which made this work much more understandable.

• Final report (800KB, PDF)
• STK animation (3 minutes, 9.7MB, MPEG4)

Another X-Prize won!  Armadillo Aerospace is the first team to win the Lunar Lander Challenge (but the demonstration window is still open, and other teams could still share the prize money).

One thing I really like about Armadillo is that from the beginning they’ve done their engineering in small increments, fixing what doesn’t work as they go along.  They’ve been at this a long time and their logs are fascinating to read; full of endless problems with metallurgy, thermodynamics, supersonic flow, control… all encountered through thousands of tests, and all eventually solved.  Founder John Carmack, who made his fortune from DOOM and other video games puts it best:

When asked what lessons the traditional aerospace community should learn from their success, Carmack answered, “You learn so much more by getting out there and doing things than you do sitting at a desk running a CAD program. You can’t even imagine some of the things that wind up going wrong. It’s the unknown unknowns that get you. You wind up getting things done by going out there and trying it, accepting levels of failure and you beat the problem into submission by working on it over and over and over again. And when you can build your operations tempo up to doing things every day, that’s what we want to see in the aerospace world.”

Exactly.  They’ve definitely earned this one, and the million dollar prize ain’t bad either.

• Armadillo Aerospace Qualifies for Northrop Grumman Lunar Lander Challenge

via OnOrbit

It’s taken a while, but Haiku, an open-source project to replace an orphaned operating system called BeOS, has finally reached alpha stage.  To understand why this is exciting, you need to know a little history:

BeOS was an extraordinary operating system available in the mid-90s.  Lean, modern, media-savvy, and blazingly fast, it was a joy to use.  BeOS went through a number of evolutionary stages, running on proprietary, then Apple, then PC hardware; but each effort ran into brutal anticompetition tactics from both Apple and Microsoft.  (And to be fair, BeOS suffered from poor marketing of an admittedly difficult-to-market product.  Why should you buy something that comes “free” with your computer, even if it is mediocre, if it means giving up the benefits of ubiquity?)  In desperation, the company (Be) changed their focus to “internet appliances” instead of general-purpose desktop software, but this failed when the dot-com bubble burst.  Despite heroic efforts within and outside the company, Be went bankrupt and was sold to Palm (which did very little with the BeOS technology), and a small handful of BeOS revival efforts eventually faded away.

Except for one, the Haiku project.  Unlike some revival efforts, which used illegally stolen code, or proposed creating Linux windowing systems that just looked like BeOS, the Haiku project rewrote BeOS from the ground up.  Because they didn’t have access to all the minute details of the real BeOS internals, Haiku is not binary-compatible with BeOS.  But it IS source-compatible (existing code can be recompiled to run on Haiku), and has the same great look and feel that made BeOS such a pleasure to use.

It’s a valid question as to whether it’s worthwhile to try to revive orphaned operating systems, especially for desktop use.  There’s definitely a critical mass where the number of users vs. the amount of development feed each other; below that limit an OS is not likely to survive.  But there’s something to be said for a healthy ecosystem requiring diversity, in both the natural and computer worlds.  Without competition, the few remaining choices become stagnant and bloated.  Sometimes something revolutionary is needed to keep everyone on their toes.

• In the Round: Haiku Alpha Released (a good summary of the history of Be, BeOS, and the Haiku project).
• Haiku project announces availability of Haiku R1 Alpha 1 (announcement and download link from Haiku-os.org)

Via OSNews.com

Things I will miss when I move away from Boulder Colorado:

• Driving on Cherryvale road, past the old house with the man on the porch who waves back at you, Peter’s Pumpkin Patch, and fields with the Flatirons in the background and deer and hawks and late summer wildflowers.
• Being lucky enough to live in a light, airy treehouse on a creek and a bike path.
• Being able to ride your bike most places in town without entering traffic.  And at certain times of the day, being able to get across town faster on a bike than in a car.
• The pair of juvenile owls who learned to fly and hoot in the big cottonwoods just off our porch.
• The Parkway Cafe, with the aquariums and great waitresses and the best Eggs Benedict in town.
• My mom.
• Birthday dinners at my aunt’s house.  My uncle’s perfectly-grilled steaks.  My cousin’s X-box.
• Dropping by the Tropical Bird Farm and handing out nuts to everyone.
• The human-scale housing developments (I can’t afford to live in them, but it’s encouraging to see them).
• Skiing in whiteout powder that has blocked the arriving crowds and makes you laugh out loud.
• J.B. Saunders, the best electronic parts store in the state within walking distance of my home.
• Camping.
• The International Scout.
• The Boulder Outdoor Cinema.
• All the science going on in the area, and the people who understand it.
• People who see something they can do to make things better, then actually do it. (Community Cycles!)
• People who think up completely oddball ways to have fun, then actually do it. (Ignite! Thursday night cruisers! Nerf wars!)
• Having the resources of a major university just down the street.
• Colorado Space Grant, birthplace of the next generation of explorers.
• Growth limits, which have made this city beautiful (but expensive).
• Summers when the bulk of the students are gone.

Things I won’t miss when I move away from Boulder Colorado:

• The weekend the students return.
• Growth limits, which have made this city expensive (but beautiful).
• The abject wealth.  Friends saying “we’re selling our house, you should buy it!” when it’s listed at 1.2 million.
• 28th street turning into Anymall America.
• Pearl street turning into Upscale Anymall America.
• RIP the beloved local places that have come and gone: Tom’s Tavern, The Last American Diner, The Hoffbrau, Daylight Donuts, Double Nickel, Philly Junction, Aria, etc.  (Most forced out by outrageous rent inflation and replaced by national chains that can operate at a loss.)
• The completely insane building department, which lets everyone get away with murder except you.
• Whole Foods, where people’s brains shut off as they enter the building.
• RIP Annual Trash Day, where people used to put anything and everything out by the curb for city pickup and great scrounging.  (Permanently canceled due to liability and funding.)
• RIP the old recycling center, which had better parking, tolerated scrounging, and had a more community feel. (Replaced by a “modern” recycling center which is poorly designed and doesn’t allow scrounging).
• Complete respect for your constitutional rights, as long as you agree with us.
• The moral high ground.  We’re all sinners.

HOMER (the High-Altitude Ozone-Measuring Educational Rocket) was the third sounding rocket flown by COSGC.  It successfully launched out of NASA Wallops Flight Facility in Virginia in August 1996.  It carried three photometers and one spectrometer to perform remote measurements of ozone and related gases.  It was designed and built on a 2-year schedule by a dozen undergraduate and graduate engineering students.  The skin, nosecone, and specialized mating sections were donated by NASA and other organizations. Almost everything else was designed and built from scratch by students, with a budget of $20,000.

I started out as a Command and Data Handling (CDH) team member, but soon became CDH lead when the former lead (the talented Wes Brandley) graduated.  HOMER’s onboard computer consisted of an off-the-shelf 68HC16 industrial control board coupled with house-designed PCBs for I/O.  The system was tasked with real-time data collection and transmission (interfacing to a high-speed radio link; there was no onboard data storage), and general spacecraft housekeeping including turning subsystems on and off at specific times during the flight.  A lot of thought went into the build quality and failsafe operations, such as how to recover from an unexpected reset during the flight with maximum safety to the payload and minimum science data loss.  The system performed flawlessly during the flight with no resets even during the 20G launch accelerations.

I also modified a commercial off-the-shelf video camcorder for this flight after the responsible student graduated.  The camcorder operated successfully, and even with the limited field of view through the tiny porthole, the resulting footage became a (locally) famous example of what students could create.

HOMER was my first major space mission, and it completely changed the direction of my life.  I had never before had the experience of working on a small team to build something extraordinary (the rocket reached an altitude of 100km, which is “officially” in space).  The team was also extraordinary, and has gone on to accomplish many great things.

Additional information

• Homer fact sheet (50KB, PDF)
• Construction montage video (2 minutes, 10MB, MPEG4)
• Physical layout animation (1 minute, 5MB, MPEG4)
• “HOMER: A Rocket Odyssey”
  documentary made for HOMER’s 10 year reunion
  (35 minutes, 150MB, MPEG4)

DATA-CHASER was a student-designed, student-built, and student-operated space experiment which flew on space shuttle Discovery mission STS-85 in August of 1997.  It was the third space shuttle payload built and operated by the Colorado Space Grant Consortium, a group of colleges and universities in Colorado that support student-run space experimentation.

DATA-CHASER consisted of two separate but linked experiments. The first, DATA (Distributed Automation Technology Advancement), tested remote control and autonomy technologies.  During the mission, the hardware onboard the space shuttle was monitored and controlled in real-time from the University of Colorado via the Internet.  At that time, this was a significant advancement over previous shuttle experiments which had to be controlled from NASA centers.  Onboard autonomy software, developed in partnership with JPL, was also tested.  This allowed the payload to make its own decisions when it wasn’t in contact with the ground (although it was monitored in the background for testing purposes).  DATA helped pave the way to simpler, less expensive, and more effective spacecraft operations.

DATA controlled the second experiment, CHASER (Colorado Hitchhiker And Student Experiment of solar Radiation).  Chaser consisted of three instruments: LASIT, SXEE (pronounced “sexy”), and FARUS, which measured the full-disk solar ultraviolet and soft x-ray radiance of the sun.  These wavelengths drive ozone creation and depletion in the upper atmosphere, which in turn affects the amount of ultraviolet radiation reaching the Earth’s surface.  The data from this experiment helped benefit atmospheric, climate and environmental research, as well as giving DATA a set of science instruments to exercise.

My role on this mission consisted of coming in late in the project to troubleshoot outstanding onboard firmware issues. This involved ferreting out two power-up reset bugs (whose symptoms were masking each other) and coming up with workarounds. I followed the payload from Colorado to Goddard Space Flight Center in MD, which involved extensive work on the payload bay bridge in a cleanroom environment, and was also lucky enough to tag along on the integration trip to Kennedy Space Center FL, where we got to see space shuttle Discovery closer than I could have imagined.

Additional information:

• DATA-CHASER web pages on archive.org’s wayback machine
• Promotional video (coming soon)

Citizen Explorer was Colorado Space Grant Consortium’s do-it-yourself educational science satellite.  It carried two ozone-measuring instruments for low-resolution global measurements, and was designed to transmit that information directly to participating K-12 schools worldwide. The satellite was first conceived in 1996, received a launch vehicle slot in 1997, and came very close to launching in November 2000.

I served as both systems engineer and Command and Data Handling (CDH) lead on this mission. The systems engineering position was particularly challenging;  the extremely tight mass, volume, power, and especially budget restrictions, along with issues unique to a project run by undergraduate engineering students, required innovative technological and programmatic solutions.

Citizen Explorer’s Flight Computing system was designed for extremely low cost, ruggedness, and rapid development in an educational environment.  It consisted of an off-the-shelf 80386SX PC-compatible industrial control computer with minor but important modifications for spaceflight, networked via RS-485 to four 8051-based microcontrollers for low-level subsystem I/O.   The subsystem controllers were programmed in C and Assembly.  The main computer ran VxWorks, Spacecraft Command Language (SCL), and autonomy software developed in partnership with JPL.  The architecture required careful attention to reliability and recovery concerns, and required the identification and execution of many design tradeoffs.

With an original schedule of 14 months from paper to launch, CX-1 would have been an ambitious project for any team. Due to a series of launch vehicle slips, this schedule eventually stretched out to 3 years, but this was still not enough time to get everything working, and ultimately the Delta-II launched without CX-1 aboard. Several subsequent generations of students worked on CX-1 and eventually created a functioning spacecraft, but a second launch was not forthcoming.  CX-1 is now stored in COSGC’s cleanroom in the hope that it could still be manifested on a future flight.

Additional information:

• Mechanical drawings (PDF, 240KB)
• Wiring harness (PDF, 1MB)
• Architecture lecture series: Critical Decoder (PDF, 181KB)
• Qualification flowchart (PDF, 61KB)
• Flight computer fact sheet (PDF, 36KB)
• Microcontroller network (“Micronet”) fact sheet (PDF, 66KB)
• “Make your own CX-1″ (PDF, 38KB)

Experience is one of the main factors in creating a successful space (or any other) project. However, this is one thing that students, by definition, lack.  An effective way around this issue is to invite corporate and academic experts into a project to advise and assist the student engineers.

Mentorship has grown to become a core value at the Colorado Space Grant Consortium.  But it took some time to get that way.  One issue is that a mentorship relationship has to be carefully managed to get the most out of it.  Another is that some of the best mentors at COSGC are former students; the longer a student organization like COSGC exists, the more alumni resources it will produce.

Bruce Davis (DANDE structural lead / I&T manager) and I noticed that other organizations weren’t taking advantage of this resource as well as COSGC was, so we wrote a paper for the 22nd AIAA/USU Conference on Small Satellites.  The paper illustrates the need in the industry for student-mentor relationships, describes some of CSGC’s best practices for creating and maintaining mentorship ties, and provides some success stories.

“The Creation and Impact of Corporate Mentorship on Student-Led Satellite Projects”

• Paper (PDF, 1.2MB)
• Presentation (PDF, 630KB)
• AIAA/USU Small Satellite Conference web site

NEMO science orbit animation 2 minutes, STK 6 Click image to play NEMO Functional Block Diagram (FBD) Visio Click image to enlarge Multilobe high-gain rigid antenna concept

NEMO, the Neptune Exploration Mission of Opportunity, was a team project for ASEN 5148 Spacecraft Design.  This project was carried out in an industry-standard fashion, including answering an Announcement of Opportunity, formulating requirements, performing trade studies, and generating a final phase-A report and presentation.  Ten students were on this team; I served as C&DH lead, with responsibilities including investigating hardware and software options, and performing radiation analysis over the mission lifetime.  I also produced Functional Block Diagrams (FBDs) of the spacecraft systems, and performed STK modeling to visualize and refine the mission’s science imaging plans and concept of operations.  This project was very interesting due to the extreme distance and time scales involved.  It’s nontrivial to design a spacecraft that has to last 20 years before it even reaches its destination.

The Satellite Tool Kit (STK) visualization here was challenging because STK does not include Neptune’s moons by default.  I retrieved the orbital elements from JPL’s database, and entered them manually.  The blue box in the main window (and the blue cone in the small window) is the main science instrument’s field of view.  The red oval in the small window is NEMO’s science orbit; every dot is one day apart.  The primary science goal of the AO was to perform long-term observations of Neptune’s auroral ring, so the hundred-day orbit was not a hindrance.  Neptune’s largest moon Triton is a fascinating object because it is in a retrograde orbit – it orbits in the opposite direction to nearly every other body in the solar system.

Three teams each produced a different design to meet the same AO.  Our team was commended on sticking closely to the requirements and producing a straightforward design, which was both (relatively) inexpensive, and (relatively) low-risk.

Selected project documents:

• Final report (PDF, 2.2MB)
• Spacecraft Functional Block Diagram (PDF, 350KB)
• CDH Functional Block Diagram (PNG, 350KB)
• Spacecraft Electrical Interconnect Diagram (PNG, 650KB)
• STK animation (h264, 8MB)