CUSat launched on September 29, 2013. It is Cornell University’s first formation-flight technology-demonstration mission. The name is pronounced “see you sat,” as in “I see you.” The spelling references Cornell University’s initials, of course, but it also refers to a key mission objective: demonstrating how one satellite can inspect another in orbit—for repair, servicing, and so on.
It went up on a SpaceX Falcon 9 rocket and shared the ride with several other customers, including another student-designed and -built satellite, Dande, from the University of Colorado (the CU of the Southwest). Dande is working great, as far as I know. CUSat’s mission-operations team flew the spacecraft for about a month before its flight computer overheated and invited in the grim reaper. Its early demise meant that CUSat never was able to demonstrate its capabilities fully.
With success only a hair’s breadth away, CUSat deserves another chance. As the Principal Investigator for this project, I’ll take the heat for what went wrong, but I also have the benefit of hindsight and have learned invaluable lessons. Here’s what I’ll do next time, if we ever find a sponsor willing to help us try again. In the spirit of Spacecraft a Week, I’ll offer a new design.
First of all, let me explain why this mission is important and boast a little about the great work that the Cornell students did in designing and building this experiment. CUSat’s architecture comprises two 25 kg satellites that fly in close proximity. They use GPS to detect the satellites’ position in orbit. That’s a fine thing, but it’s nothing new.
What’s new is that each of the two CUSat spacecraft has three GPS receivers, not just the one that your smartphone has. CUSat’s GPS antennas are spaced as widely as possible. Knowing the distance and direction (i.e. the vector) among these three antennas on a single satellite can tell us the orientation of that satellite relative to the Earth. Knowing the vectors among these antennas from spacecraft to spacecraft can tell us the orientation and position of one spacecraft relative to the other. That’s new.
And we know those vectors really well. Thanks to research by Dr. Shan Mohiuddin, formerly a graduate research assistant for my colleague Dr. Mark Psiaki, we know them to within about 3mm, likely about 1mm. That’s really new.
CUSat’s incredible precision and accuracy comes from tracking not just the GPS data you’re familiar with, which yields position accurate to about 1m, but also the so-called carrier phase. That is, we track the oscillations in the GPS radio transmissions themselves, measuring where the radio-frequency wave is at any time (i.e. the phase). As that radio wave passes one antenna, and then another, we mash together the phase difference, the speed of light, and the GPS transmissions’ frequency into an estimate of that relative position—again, good to a few millimeters or better.
The GPS receivers on CUSat are homemade, the result of research by the late Dr. Paul Kintner at Cornell. They cost about $1k. So, for about $6k and some software, we can navigate one spacecraft relative to another more precisely than you can write with a Sharpie. That’s why CUSat is worth doing, and that’s why I want to try again.
Cornell students designed, built, and tested CUSat. They did so under my leadership and with the guidance and support of the University Nanosatellite Program at the Air Force Research Lab. In addition to a well-conceived and implemented structural and electronic design, there are some unusual innovations that deserve special acknowledgment.
- One is that the entire two-spacecraft system is single-fault tolerant. No single failure can prevent mission success. The fact that there are two spacecraft in the formation is part of the reason. On top of that redundancy, each spacecraft has three GPS subsystems where two would do, two radios where one would do, eight pulsed-plasma thrusters where seven would be sufficient (and four would do nearly everything we want), two cameras, multiple solar panels, and a few other backups. Even if the spacecraft computer fails (the infamous Viper, to which I’ll return), the mission control center can send and receive commands to cycle the power through separate electronics. Furthermore, all the flight software, as well as some of the microcontroller code, can be reprogrammed from the ground.
- Another is that the flight electronics are protected by being nestled together, each board in its own aluminum box (to prevent electromagnetic interference among the boards). The most critical items are near the inside of this stack, with the flight computer at the center. It’s a little like organs in the human body, with the heart or brain protected by surrounding tissue that’s not quite as important. Radiation in the space environment has a hard time reaching these interior boards. High-energy particles need to pass through about 1 cm of aluminum to reach the flight processor. All this metal also helps wick away thermal energy, which of course we can’t remove in space with a fan, the way it’s done in a laptop.
In my opinion these are very successful design decisions, and the students who put it all together are to be commended. Somehow they managed to pack all this hardware, as well as the electrical harness to tie it all together, into a volume the size of a salad bowl. The Air Force tells us that CUSat is the densest spacecraft they’ve ever seen. In fact the students did it twice—two spacecraft, remember—and finished all this hardware in about two years.
So why didn’t it work when it finally launched five years later? The proximate cause is that the Viper overheated. Maybe that’s because it was packed in with other electronics, all of which generated heat, but I don’t think so. Despite the technical specifications reported by the manufacturer and our thermal analysis, the temperature rose to about 95°C over the course of a month’s orbiting in full sun (not expected when the students designed the mission). And that was the last telemetry we received. There were other problems, notably that the battery-charging software was incorrectly designed and implemented, merely counting up current in and out of the batteries and fundamentally misreporting the state of charge. However, that could have been fixed with a simple software patch if we had had the time.
But looking a little deeper, I now understand that we should not have let the spacecraft out of our sight until we had a firm commitment to launch. As it was, we delivered the spacecraft to the Air Force in 2008, five years before it actually launched. After 2008 our team gradually lost hardware expertise as generations of students came and went. CUSat went through four launch campaigns, each one a big hurry, during which I made bad decisions. For example, the most recent launch campaign but one led us not to repair some electronics that had failed during some previous pre-launch testing. And for one reason or another, we ended up launching one of the CUSat halves as a non-functioning mass that stayed with the launch vehicle while the other went on its way.
So, here’s what I’d do differently.
- Let’s launch CUSat via the International Space Station. Leave one of the two spacecraft on the ISS and send the other on its way, demonstrating formation flight with its highly accurate GPS navigation.
- I would not let the spacecraft leave the lab until it is ready to launch.
- And a few little technical tweaks:
- Use commercial electronics. Instead of the myriad “interface boards” that our students enjoy building from scratch, I would permit only off-the-shelf microcontrollers, such as an Arduino, to interface with hardware. No building boards.
- Get rid of the Viper flight computer, which was buggy, inexplicably crashing so that students wrote software patches and epoxied a USB drive to the board to accommodate them. The Viper board itself had integrated circuits mounted atop others, soldered to the traces on the board, with some other traces cut, making its overall quality very questionable. Unfortunately, we were committed to this flight computer. But with no response from the manufacturer, one of the Cornell students ultimately found a reseller online from which we continually bought more as generations of Vipers gradually died off.
- Use only commercially available wiring harness that comes with connectors; no making custom cables. Nearly every test failure on CUSat can be traced to an issue with harness workmanship or design.
- Build our own reaction wheels from commercial brushless DC pancake motors. No rotor (i.e. no flywheel), just the motors. Easiest thing in the world. We’ve done it twice since.
You heard right. For about $6k and some software, we can navigate one spacecraft relative to another more precisely than you can write with a Sharpie. Every spacecraft should have this capability. Imagine if any satellite could pinpoint its location relative to, say, the International Space Station within a few millimeters. The right combination of receivers and transmitters would make this possible. In this new world, a spacecraft could navigate to ISS and dock without radar, joysticking, or optical navigation. Spacecraft could sidle up to propellant depots and refill their water tanks, knowing their precise trajectory at any time. Spacecraft orbits would be known with astonishing precision, maybe avoiding collisions that lead to orbital debris. A CUSat reboot could show the way.