Monthly Archives: June 2014

Stochastic Exploration


There’s strength in numbers.  Many hands make light work. The whole is greater than the sum of its parts. It takes a village to explore the solar system. These aphorisms are so familiar—well, three of the four, anyway—that we rarely recognize their potential to change how we think.

So, let’s recognize it. What would it mean to explore space the way that cottonwood seeds and maple samaras drift across the landscape, blown randomly and yet ensuring that some small number of new saplings take root? What if we could use sheer numbers of spacecraft to design a mission that reaches its target—not focusing on high-precision trajectory control but seeking a statistical guarantee that some fraction of the many spacecraft arrives at the intended destination? Let’s take this idea further. What if the destination were a region of space? The entire solar system? What space-system architecture would guarantee good odds that one of our many spacecraft would encounter a celestial body?

What makes this idea even remotely credible is the possibility that someday soon we’ll see some very small spacecraft. Launch costs are what they are, and the U.S. Congress is willing to budget relatively little for new ideas in space. So, for the foreseeable future, the only way to put more spacecraft into orbit is to make them smaller. Sprites are a start. They’re one way to do more with less. The current Sprite technology demonstrator weighs about 5g. I’m confident we can knock that down to 500mg if we could find the resources to support that technology development. (The fact that there is so little funding—public or private—for this kind of research is one reason for the blog. So, I might as well put these ideas out there for free).

Let’s posit that the SpaceX Falcon Heavy will be able to launch 10,000 kg on our desired Earth-escape trajectory. SpaceX expects that it will carry 13,200 kg to Mars. So, a lighter, 10,000 kg payload would go even farther. And let’s say that 30% of this payload has to be dedicated to spacecraft infrastructure, such as something to tie the Sprites together and later deploy them, as well as communicate with the ground at the time of this event, which takes power, and thermal control, etc. The remaining 7000 kg worth of 500mg Sprites would comprise 14 million individual explorers.

Some of us have been thinking about this idea for a while: Cornell graduate students Lorraine Weis and Zac Manchester, for example. Zac wrote a paper about some of the mathematics.  Lorraine is working on ways for a large number of such spacecraft to exploit solar pressure and other subtle physics.

Here’s how it might work.

A mothership launches on a Falcon Heavy. It’s a 10,000 kg spacecraft that includes 100 kg worth of solar panels to power a 10 kg communications subsystem, a 50 kg traditional propulsion subsystem, another few hundred kg of other structural and electrical bits and hardware for guidance and navigation. Those spacecraft-design details are straightforward. Here’s what isn’t. About 2500 kg of material is an ultraviolet-degradable binder (if you’re an applied chemist), or mortar (if you’re a mason), or matrix (if you’re a geologist). This mortar is shot through with Sprites. They are frozen in temporary amber, which keeps them safe during launch and enables them to travel together after the launch vehicle upper stage separates from the mothership. Or maybe they’re like pineapple chunks in Jell-o. You get the picture.

Operators on the ground design a trajectory-correction maneuver of some kind, upload it to the mothership, and initiate it. Now the mothership’s job is done, and the Sprites are en route to somewhere. They should head for the nearest on ramp to the Interplanetary Transport Network. The ITN is a chaotic, multidimensional set of gravitational pathways through the solar system. Gravity from the Sun and planets is partly responsible for its existence. So is the rotational churn of the planets as they orbit the Sun. These pathways are hard to predict exactly, and no spacecraft has ever tried hitching a ride.

Until this Sprite mission. Arguably some of NASA’s interplanetary spacecraft, like Cassini, leverage parts of the ITN to cut down on propellant and enable them to travel to the outer planets affordably. However, it’s risky to depend on the ITN exclusively because of its mathematical subtlety and its chimerical behavior—risky for a single, exquisite, expensive spacecraft anyway.

For our 14 million Sprites, it’s another story. As the Sun’s ultraviolet radiation washes over the block of Sprites, the UV binder evanesces. The Sprites begin to flake off, and the individual Sprites fan out. The process resembles how the Sun’s heat and pressure burns off ice from comets, producing that characteristic tail. And like a comet’s tail, these Sprites roughly follow their siblings for a while. As time passes, their paths diverge. Differences among the individual Sprites’ flight dynamics separate them. The first Sprites to flake off end up at the statistical extremes. So do the last ones.

The “average” trajectory here is a slippery concept: the mean or median of this statistical distribution involves a cloud of Sprites, and we need to describe its motion with at least six coordinates (Kepler’s orbital elements, for example) or through even subtler mathematics like statistical moments. The goal is to put the average close enough to the trajectory we want that the number of Sprites on slightly different trajectories compensates for unexpected disturbances. Those disturbances would prevent a typical, single spacecraft from reaching its goal. In stochastic exploration, they’re part of a blurred reality in which we design the odds. And thanks to the number of chances, the number of spacecraft, the mission architecture confidently meets those odds.

Assuming we’ve licked the problem of how to plan the trajectory of a cloud of particles, we now have a cloud headed somewhere interesting. How about Jupiter? It’s well known that the combined gravity of Jupiter and the Sun trap asteroids—the so-called Trojans. Their orbits reside in a permanently stable tidepool in the planetary ocean. We call it a “Lagrange point.” Maybe some Sprites end up there. Others may slip past and begin to orbit Jupiter, where they slow down thanks to electrodynamic drag and collisions with gases found among Jupiter’s many orbiting moons. Over time they encounter those moons and the spaces between. Some likely end up entering Jupiter’s atmosphere.

Another aphorism: if a tree falls in a forest and no one is there to hear it, does it make a sound? We could ask, “if a Sprite encounters a planetary body but transmits nothing back to Earth, have humans explored?” A few of us think the answer is “yes.” But, you know, some scientists are all “me, me, me.” For these solipsistic types, let’s consider a couple of ways for these interplanetary Sprites to tell us what they’ve found.

Taking a page from the Kicksat mission, we could use a matched filter to detect special gold code pseudorandom sequences, each a unique signature emitted by one of the 14 million Sprites. The Sprite ground station’s special brand of signal processing helps it pick out a Sprite’s faint transmissions from all the other noise. The longer the code, the better—that is, the greater—the signal-processing gain. And there’s another reason for a long code: each Sprite should have a unique signature, and creating 14 million unique codes demands that they be long. In fact, if it’s to be like the Kicksat Sprites, we’ll need 28 million codes—a 1 and a 0 for each spacecraft. Each would be about 10 gigabits long.

Solar power might be sufficient for spacecraft on ITN pathways among the inner planets. Near Jupiter a more likely choice would be a nuclear power source, a betavoltaic battery. Widetronix, a start-up in Ithaca, NY, is developing this technology, and they’re already able to power integrated circuits with a microchip-scale nuclear source. Some of their batteries have half-lives of a century. So, a nuclear Sprite is well within the realm of possibility. What’s more, it could last far longer than most of the engineers who designed and launched it.

But let’s say that nuclear power is off the table. How about scavenging the energy of impact? When a Sprite strikes an asteroid, for example, a piezoelectric layer in its structure deflects and produces high power for a brief instant. In that instant, current flows through an analog circuit designed to emit a short, high-power pulse at a specific frequency. The Sprite’s swan song is a transmission that confirms an impact (in this case something very short, nothing like the 10 gigabit sequence of that nuclear design). That information could be useful in figuring out the statistics of the Trojan asteroid population—how many, how big, and where they are. How about we design this analog circuit to include a device whose inductance varies with matter that happens to adhere to the Sprite during its voyage? Maybe electrostatic charge makes it stick. That variation would alter the frequency of this swan song. When we detect it, such a transmission might reveal something scientifically novel about interplanetary gases or particulates.

How we ask the question can determine the answer. Rather than asking “how can we build a spacecraft to take high-resolution images of Trojan asteroids,” we might ask “what science can you do with tiny sensors that offer a statistical guarantee of asteroid collisions?” The latter is a question that demands more from our imaginations. It’s the kind of question we need to ask more often.


Spaceflight with a Sharpie


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.

  1. 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.
  2. I would not let the spacecraft leave the lab until it is ready to launch.
  3. 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.


shoers_microroverSpace exploration and space science are serious undertakings. Steely-eyed missile men with furrowed brows insisting that failure is not an option. Suits and skinny black ties. Short haircuts. Special safety regulations. Lots of jargon and three-letter acronyms (TLAs). We rarely hear the word “adventure” in the context of professional spacecraft engineering, let alone “fun.” And I never heard it on Capitol Hill during my two years working in Washington, D.C. But here’s the thing. Isn’t all this at least a little exciting? Even enjoyable? Honestly, if you’re an aerospace engineer and you don’t get some kind of kick out of what you’re doing, just go back to school, get an MBA, and make a lot more money doing something soulless that involves straightforward arithmetic and nothing more death-defying than Earnings Before Interest, Taxes, Depreciation, and Amortization (EBITDA).

That’s why it’s great to see Astronaut Chris Hadfield playing Space Oddity. He’s confirming for us that space and popular culture can be one and the same. Maybe even better, NASA flew some Legos recently. What would you build in orbit if you had something like Legos?

Connecting people to space in this way has some immediate benefits, sure—motivating the public to advocate for space-program budgets, moving Congress to appropriate money for NASA, and all that. But I think there’s a much more long-term benefit to embracing our natural curiosity, sense of adventure, and desire for play. What if we could create a killer app—a game, say, that people want to play desperately enough that they’ll invest in space hardware the way they invest in video games? What if a killer app for space showed us what’s possible if we all pull together and do what humans do best: build, create, and seek adventure?  What if you could play Minecraft on the Moon? For real? Would you and thousands of your friends pay enough to kick start a gamer’s space age?

Let’s call the game Mooncraft. Here’s how it might work.

A tactical objective is to survive the lunar night—about 14 Earth days long. There are no zombies or other lunar miscreants that skulk about (as far as I know), but nighttime is bad enough without creepers. Your avatar is a very small rover. Let’s say 100g in mass, for reasons I’ll explain. It captures a 176×144 grayscale imagery at a few frames per second.  These small frames and data compression would enable communications at less than 12Kbps, less than an old dial-up modem. The rover transmits its data to a larger, shared communications node to downlink to Earth. Servers on Earth distribute the video to gamers. So, you’re looking at the gray, black, and white lunar surface in grayscale. Makes sense to me.

There’s the question of light-travel time, which delays the signals to the rovers, and the video back to Earth.  It’s a few seconds. That’s too slow for joysticking a fast vehicle, but these little things travel slowly—a few millimeters a second. Commands to the rovers consist of “move forward x distance,” or “turn y amount,” delivered by a special type of game-controller interface that interprets typical Xbox controller or Wii controller motions as macroscopic commands that are executed on the scale of seconds. It will take some training, but I am confident that we’ll get used to it.

To survive, and in fact to thrive, on the Moon, players mine the regolith and build structures. Rather than whacking at the material with a pickaxe, as in Minecraft, some rovers dig up and nudge the powdery, sandy regolith forward with a snowplow-like attachment. Others pick up and place small rocks with a simple robotic arm. Still others can sinter igneous rocks together, tack-welding them in place. Yet another type of rover can provide bursty power to rovers that request it. Dr. Joe Shoer designed the microrover shown at the head of this post. Future posts will go into the technical designs of some of these microrovers.

Game designer and author Erin Hoffman clued me into the gaming value of creating different characters for these rovers, establishing an essential story line. We would start with a few of these characters but (and here’s the part I really like) we would let people design their own. The Mooncraft company, if it were ever to exist, would launch its own rovers for the use of the gaming community and would also launch rovers designed by its players (for an appropriate fee, of course).

The business case depends on utilization. Say that a gamer is willing to spend $5 per hour operating a rover. That’s over $44,000 per year, if a user wants a rover all to himself or herself. Those economics don’t make sense for most of us. My daughter assures me that the people who play Minecraft for hundreds of hours straight are also not the people with that kind of money to spend.

Instead, a time-share arrangement probably makes more sense, in which the rover is available to a gamer for a session and then autonomously leaves the site that a gamer has been working and goes to another gamer’s site to serve as his/her avatar for a while. And that shuttling back and forth continues. There’s likely an optimal algorithm for sending the rovers where they’re desired, a sort of traveling salesman problem to be solved for this kind of lunar gaming.

Let’s consider a business case. If a rover survives for three years, at 50% utilization, it provides about $22,000 in income. The cost of launching a 3U CubeSat to the Moon is alleged to be $1M. Say half the mass of this 4 kg 3U combines landing systems (airbags, in my opinion, and/or crushable foam) and requisite software, radios, solar panels, and structure. That leaves room for 20 tiny rovers.  I would suggest a sign-up fee for users, like buying a gaming system.  Say it’s $500 and that 1,000 people per rover sign up.  The total income over that three-year lifetime would be over $1.8M. Assuming the launch cost stays at $1M, and accounting for the cost of money, taxes, operations, building the rovers, and other things, we would conclude that this enterprise is on the ragged edge of profitability. Now, where’s that guy with the MBA that I insulted earlier?

A little more profitability might come from special users—people who level up or even choose to create a private population of these rovers to fabricate their own lunar outpost. Maybe NASA or other organizations would like to operate a fleet of these rovers for the sake of science and human exploration.

Remember, we’re playing with the actual surface of the Moon here. An accidental (?) outcome of playing the game Mooncraft may be the creation of a supply of lunar bricks (and Mooncraft could share the profits of selling these bricks to other users, with the gamers who created them). Another outcome may be a very large radar or optical reflector on the surface of the Moon, and who knows what else? An intentional outcome of these leveled-up players’ work may be the creation of a lunar base, or a space hotel. Or a lunar runway.

In any case, a game like this would provide an economic incentive for private launches to the lunar surface and, maybe, eventually, human habitation of the Moon. As awesome as Minecraft is, I might prefer the real version, the one in which I could go live in the structures that my avatar builds.

Let me summarize. There are three reasons for Mooncraft. First, maybe someone can make a buck from the entertainment aspects of this idea. The second and third objectives here go beyond mere entertainment. We’ll get some lunar structures built. And the gamers can share in the rights to license them for use. But most of all, Mooncraft is one of several ways in which to increase consumer demand for space. Increasing the demand for hardware in space will lower launch costs by making rockets a commodity. Launches could become such a common occurrence that they begin to resemble the mail. Think about how much it would cost to send a package across the country if we had no postal service, in fact no roads. You would need an expedition, outfitted for survival during a weeks- to months-long trek. Starts to sound like space travel, doesn’t it? So, let’s create the demand for sending hardware across the cosmos and motivate a business case for the 21st century version of the Pony Express: frequent, commercial access to space. Games maybe the way to start.

I’ve spent some time with a few startups in the Bay Area recently. Some will probably be successful. But I’ve seen what that success requires. Money, yes. Also a realistic business plan. But most of all you’ll need passionate employees willing to work for a fraction of their value in the hope of building something that will change the world. Well, I think a real-world version of an already compelling game might generate such passion.