prev next

Applying Open Source to Rocket Landings

Blue Origin landed their booster back on the ground after lifting a capsule into space (or mostly into space, whatever). This is an awesome development. We need rocket landings and not just rocket launches to make them as reusable as airplanes to bring down the cost of spaceflight.

SpaceX and Blue Origin Rocket Landings

Of course, Jeff Bezos talked about what Blue Origin achieved and, of course, Elon Musk of SpaceX and other fame felt the need to throw a little shade and talk about how SpaceX is better. Billionaires will be billionaires.

I expect we can get this kind of development out of the way faster, and make everything about space cheaper, if we adopt an open source approach to the technology. Leaving aside concerns about export controls for the moment (which pretty much would put them in jail if they shared anything with people outside the U.S.), it’s just cheaper to solve problems if you already know what’s worked for someone else.

Open source was invented so that companies could safely use public code in their for-profit endeavors. People can use it too. Aliens could use it if they wanted. Anyone can use it, but the “people” who are happiest are the corporate lawyers because they don’t have to worry about their company getting sued. It’s an important distinction because sharing is an old idea, and open source is a lot like sharing, but open source ain’t sharing. Open source is a legal standard, not a moral or ethical standard. When individuals want to share they rarely bother applying a license to their work.

ohw_logo-golden_orb

There shouldn’t be any doubts about guys like Bezos and Musk knowing what open source is. Bezos clearly knows what open source is and intends to use it without commenting or contributing. Musk actually invoked open source when he allowed the world to use Tesla’s patents. However, in contrast Musk also said that SpaceX doesn’t patent anything because then China would know what they’re doing and copy them. Bezos tried to patent the idea of landing a rocket but Musk helped block the patent, arguing that tons of people already know how to do a rocket landing. So, if they know what open source is, why don’t they recognize its potential for creating cheaper solutions? I’ve got a theory on that, but first a bit of context.

There’s a bit of tension, then, between the perspectives of individuals and corporations. The corporations (SpaceX, Blue Origin, etc) only “share” when it’s safe and profitable. The masses share pretty freely, but only license what they share some of the time. So if we wanted to get lots of people throwing in on designs for reusable rockets we’d need to reconcile the difference between those perspectives.

Open source works best for infrastructure type technology; stuff that everyone needs. So we might be able to build up technology from the masses that’s used in many things and can also be used in spaceflight. A more fanciful possibility is using something like a Distributed Autonomous Corporation to organize the effort of the masses around actual spaceflight technology without a traditional corporation. We might even be able to eventually educate the people who run spaceflight corporations on the benefits of sharing development costs, but this is supposed to be a non-fiction piece.

There’s inherent issues with Open Source though when it comes to hardware. There’s a lot of activity in open source software because there aren’t really any barriers to building source code into object code, whereas things like an open source 3D printer (see RepRap for probably the first), you need to buy lots of materials that you might not otherwise have, and then, oh, you’ve got to build it. There’s not some machine that’s going to do it for you like software. There’s activity around many electronics projects, and a few mechanical projects, because turning the source into object isn’t too onerous. You can perhaps see how something like a rocket get’s hard to open source.

For something like rocket landings though, most of the systems are already in place. You already used the power of the rocket to go up, so slowing down can be done the same way (and is by Blue Origin and SpaceX). Just fire the rocket in the same direction, away from the ground, again. That’s super over simplified, but it’s to make a point. If Bezos and Musk (and NASA and ULA and maybe more) decided to start working together on the problem of landing, they already have 80% or more of the things they need. The last 20% is a bunch of hardware and software performing tricks for controlling the rocket on its way back down that they both sort-of have working, but it’s not 100%. Even if it has been proven to work after multiple orbital launches, there’d be more things to improve on. Like landing on a barge in the middle of the ocean where it’s moving around tons.

Falcon 9 Landing Stages

Landing the Falcon 9, via SpaceX

They could start open sourcing the landing systems so that they can do hard things like landing on a barge in the middle of the ocean with the likely super complex software SpaceX designed to take in all sorts of information from sensors all over the Falcon 9. It could then be worked on collaboratively with other organizations (again, NASA, ULA, etc). They could even sweeten the deal with a list of the sensors that they’re using with it, where they go on the rocket, etc. If they aren’t commercial, off the shelf (COTS) items, things like that would be great to share their design and manufacturing with the likes of Blue Origin under an open source license too. With that done, as Blue Origin uses that software and those sensors and integrates them with their rocket and whatever they’re using to “balance a rubber broomstick on your hand in the middle of a wind storm” (via SpaceX) that is rocket landings from space, they can suggest ways to improve it, or even contribute their own improvements! All of the other bits of the rocket like the engines don’t have to be open sourced as well.

What’s better, is now the rockets are cheaper for more reasons than one. Yes, they’re reusable. But there’s not nearly enough people doing the same thing at 2 or more different companies. Now they’re working together, and that means developing better landing stuff faster, whether that’s software controlling the rocket, or the hardware helping it stay upright and not turn into a giant fireball (see videos of attempts at rocket landings on a barge).

Mach 30 At the Open Hardware Summit

Mach 30 at the Open Hardware Summit

This is a bit late, but I still wanted to share what went down at this year’s Open Hardware Summit. I was excited to be part of the event because it was a great opportunity to meet like-minded people and share what’s been going on with Mach 30.

The key to “open source hardware for all” is high-quality open source engineering tools.

This message has been one of the key themes of Mach 30’s work in 2015.  Our technical projects have been shaped by this value, Jeremy has been connecting with a group from MIT to explore open source CAD, and I have been talking about this value on our blog and at the summit (check out the Open Hardware Summit presentation in the video below or in the slides on Google Docs).

At Mach 30, we use open source tools for all our projects. This is because we want to give everyone the ability to take part if they have the time and inclination to do so, and not be restricted by the tools they don’t have.

One example of such a tool is CadQuery, a Python-based parametric CAD language, which is actually inspired by JQuery. Some of the reasons we chose to use it over other open source tools: it’s easy to use, it has a powerful API, and it has an active development community. We like it so much, and we think it’s so useful, that we are actively contributing to the project.

Without high-quality open source engineering tools, we limit participation in Mach 30 projects to individuals and groups with access to tens or hundreds of thousands of dollars in proprietary engineering tools. Our mission of hastening humanity’s advancement into a spacefaring civilization is too important and too big to put these kinds of limits on participation.

That said, please join us in developing and supporting high quality open source engineering projects like the ones below:

If you want to learn more about our cold gas thruster, check out the Yavin Thruster project on Open Design Engine.

ad astra per civitatem

Why We Need Professional-Level Open Source CAD

ad astra per civitatem – to the stars through community

At Mach 30, you’ll often hear us use this take on the famous Latin motto, ad astra, because we want to enable the broadest range of people possible to be part of the spaceflight community and  to contribute to our mission. A big, and sometimes insurmountable, barrier to entry for hardware project volunteers can be cost. If a user needs to pay tens or hundreds of thousands of dollars for engineering software licenses, you’ve just lost that volunteer. By utilizing open source tools, we ensure that everyone from the teenager with big dreams and a 3D printer to the retired aerospace engineer gets an equal chance to come alongside us.

Going hand-in-hand with open source software, is open standards and open data access. If Mach 30 can’t share things like CAD models, mathematical analyses, and research results with the broadest possible audience, we’re blunting the power of community. To see an illustration of this in action, see our recent blog post in which Mach 30 Reimagines The Martian with Open Source. By broadening access, we ensure that the weekend warrior working in her garage can reach us with her amazing ideas.

Up until recently, I had feared that Mach 30 was alone in thinking that the current set of open source CAD tools wouldn’t meet our needs. Then, I got an email announcing a new open source CAD discussion group organized by some members of MIT’s CSAIL lab.

Beyond just being impressed with the credentials of the attendees at the first video conference, I was struck by how dissatisfied the majority of them were with the current state of open source CAD as well. We certainly have a selection of open source CAD tools at our disposal (like CadQuery, FreeCAD, OpenSCAD, and BRL-CAD), which is great, but all of these tools seem to lack one or more fundamental components in the areas of stability, functionality, or UX (user experience).

If you don’t believe me, seat a CAD professional (on Solidworks, SolidEdge, Autodesk Inventor, etc.) in front of your choice of open source CAD tool. Even with training, you’ll see that they quickly become frustrated by the lack of what they consider basic functionality. I’ve gotten chuckles out of other CAD professionals before when I’ve mentioned my own efforts to use open source CAD for complex projects. Sure, there are individuals and small companies who use open source CAD, but I have yet to meet anyone who prefers the experience over a proprietary CAD package.

open source CAD

Modeling in CadQuery

When Mach 30 finds an area where the open source alternatives are lacking, we first look for a suitable existing project that we can contribute to. If we we’re unable to find anything, we’ll roll up our sleeves and build the tools ourselves. Currently, Mach 30 community members are direct contributors to the CadQuery CAD scripting framwork.

CadQuery has allowed us to do some very exciting things, such as driving the geometry for 3D models directly from the rocket science documented in our Mathematics Tool Kit (MTK). However, CadQuery is only part of the solution. We also need CAD and CAE (Computer-Aided Engineering) applications that are capable of things like assembly, interference detection, and analysis. Beyond just being capable, these applications need to empower the community member working with them to be productive so that their precious resource of time is used effectively and efficiently.

If we, as the broader Maker and Open Source Hardware communities, can hit the mark in the areas of affordability, data sharing, power, and usability with our open source engineering tools, we’ll increase participation and accelerate the already amazing pace with which open source software and hardware is changing the world.

So, what do you think? Are you happy with the state of Open Source CAD, depressed by it, or somewhere in-between? Are you able to make FreeCAD outperform SolidWorks or Autodesk Inventor? We’d love to hear from you about how you do it.

J. Visits the Portland State Aerospace Society

“If you want to go fast, go alone. If you want to go far, go together.” – African Proverb

I like this proverb, especially as it applies to Mach 30. After all, our ultimate goal is to turn humanity into a spacefaring civilization, and you can’t really go farther than space.

Of course, such a lofty dream requires all the help it can get, and so one of Mach 30’s goals is to build relationships, and ultimately partnerships, with groups which share one or more aspects of our mission. One such group is the Portland State Aerospace Society (PSAS), a student organization at Portland State University dedicated to building and operating open source rockets (like we do).

I’ve wanted to visit PSAS ever since I first heard about them through our social network. So, when I met Nathan, one of the PSAS advisers, at the 2015 Open Hardware Summit, I arranged a visit for the next time I was on the West Coast for work. Happily, things worked out for a trip at the end of October. What follows is a little travel log of my visit.

Getting to PSAS

I took the train down from Seattle to visit PSAS at the end of a business trip.  The PSAS crew were great hosts. Nathan and Andrew came to pick me up at the train station and then took me out to dinner at a local pizza joint which makes its own fruit sodas.

J. Visits the Portland State Aerospace Society

Arriving in Portland

J. Visits the Portland State Aerospace Society

Dinner with Andrew and Nathan

Every Tuesday night, the PSAS crew meets to review current events in space, share project updates with each other, and work on their projects. I had the fortune of being able to make my visit work out on a Tuesday night, so I was able to meet the whole PSAS team. After the formal part of the meeting, I sat down and talked open source with Theo and Jamey, two PSAS team members. They were intrigued by our use of agile methods in open source hardware development. We also talked about replicating each others’ work to help ensure project documentation is complete at both PSAS and Mach 30.

The PSAS Rocket Shop

After chatting with Theo and Jamey, Nathan stopped by and asked if I was ready for a tour of the facility. That tour ended in the home of PSAS’ rockets. I am not sure what they call this lab, but at Mach 30, this is what we call a rocket shop. I was immediately drawn to their current rocket, inspecting details like the active roll control system. As I continued to look around, I saw many trappings of rocket culture, including the PSAS version of the Rockets of the World poster (in this case the rockets of PSAS). This is such a great space — I could live here.

J. Visits the Portland State Aerospace Society

Welcome to the PSAS Rocket Shop

J. Visits the Portland State Aerospace Society

PSAS Roll Control

J. Visits the Portland State Aerospace Society

PSAS Rocket Poster

Latest Projects @ PSAS

After I had finished looking around, the PSAS team showed me two of their current projects:  a carbon fiber body for their next generation rocket and a mechanical system for separating the nose cone as part of the recovery system. Nathan and I agreed the PSAS carbon fiber process is a great example of a project that should be replicated to verify the documentation is complete.  We will have to see what we can do about that. The PSAS team also demonstrated the lab prototype of their new mechanical separation system (be sure to check out the video).

J. Visits the Portland State Aerospace Society

PSAS Carbon Fiber Body Sections

14 PSAS Prototype Nose Cone Separation System Demo

PSAS is also working on a 3D printed cold gas thruster system (the Mach 30 volunteers working on Yavin were very excited to hear this news when it hit Hackady). So, of course I couldn’t leave without checking that out. Their cold gas thruster is part of an RCS system for use in roll control. Look at how small the thruster module is in the photo of the thruster cross-section.

J. Visits the Portland State Aerospace Society

PSAS Cold Gas Thruster Pod

J. Visits the Portland State Aerospace Society

Cold Gas Thruster Cross-Section

PSAS Mission Control

Toward the end of the visit, Nathan fired up the rocket’s flight computer and the mobile mission control and demonstrated their web-based mission operations software. I was particularly interested in the web-based user interface. Mach 30 did some quick prototyping of user interfaces for our test stands (which require similar controls and feedback) at Apogee II, but we did not include web-based options. Between some things I have seen in maker robotics and the PSAS mission control, I think we should add web-based interfaces to our list of technologies to consider.

J. Visits the Portland State Aerospace Society

Nathan Demos PSAS Mobile Mission Control

J. Visits the Portland State Aerospace Society

PSAS Mission Control Uses Web UIs

J. Visits the Portland State Aerospace Society

PSAS Mobile Mission Control

One more quick comment on their mobile mission control: it is built around an Ikea desk screwed to a base with some casters. I think that is a very clever hack. The rest of the mission control system consists of a low-power PC running Linux and three mounted LCD monitors.


As you can see, I had a great time visiting PSAS. I took more photos than are shown here. If you want to see the rest of them, check out the Flickr album.  I want to thank everyone at PSAS for showing me around and making me feel welcome in their space. Special thanks go out to Nathan and Andrew for helping me coordinate my trip and getting me around town.

All of us at Mach 30 love visiting groups involved in open source spaceflight. Are you part of a group or know of a group we should visit next? Leave a comment below and tell us all about them.

ad astra per civitatem

Mach 30 Reimagines The Martian with Open Source

The Martian

What, no open source? (Image: Screen grab from The Martian’s official trailer)

Spoiler Alert: This post discusses several key details of The Martian.  If you haven’t seen the movie or read the book, you have been warned.

It might be argued that Rich Purnell, “steely-eyed missile man“, is the true hero of The Martian. But you know what else could have helped save Mark Watney (in a much smarter, more efficient way)? Open sourcing.

Let’s back the story up a bit before we get into the details. Mark Watney, played by Matt Damon, is an astronaut stranded on Mars after a dust storm forces his crew to leave him behind. As he does his best to signal to Earth for help and stay alive, NASA and a team of scientists work together to bring him home.

Purnell (played by Donald Glover), NASA astrodynamicist, then devises a daredevil rescue, involving an alternate trajectory for the spacecraft Hermes (the same vehicle that brought the crew to Mars).

NASA’s original plan was to have the Hermes enter Earth orbit, resupply, and then fly back to Mars. The problem here is that it takes too long — Watney’s supplies are severely limited, and time is a critical element. The Rich Purnell Maneuver would have the Hermes skip entering Earth orbit altogether, and instead go around the Earth and fly straight back to Mars.

Purnell then proceeds to spend every waking moment calculating the details of the this trajectory and verifying it will work. He then flies out to present his work at a secret management team meeting, where it is summarily discarded as too risky.

Just when it appears that all hope is lost, Mitch Henderson (the Hermes Flight Director) disguises the Rich Purnell Maneuver as a family photo and sends it to the Ares 3’s resident orbital dynamicist aboard the Hermes, who then shares it with the rest of the crew. After reviewing Rich’s plan, the crew quickly decides to mutiny so they can save their crewmate (wouldn’t you?). To ensure mission control doesn’t interfere with their plan, the crew disables the Hermes remote overrides (all three of them) and changes course for Mars. The rest, as they say, is history.

All of this cloak and dagger activity makes for great drama, but it is no way to run a space program. What if the NASA in The Martian valued transparency over secrecy? What if the management team didn’t have to rely on just one veteran engineer’s evaluation of Rich’s work when deciding whether it would work? And, what if Rich’s proposed trajectory could have been developed by a team of volunteers from across the planet instead of being fueled by one man’s dedication and gallons of coffee?

NASA could have used its resources more efficiently, its management team could have had greater confidence in the Rich Purnell Maneuver, and Rich could have arrived at his proposal faster. All of this, and the crew wouldn’t have had to mutiny in order to save Mark. Applying open source principles to spaceflight, like we do at Mach 30, gives organizations all of these advantages. As the Mach 30 president and the team leader for our open source projects, I get to see first hand the impact these principles have every day.

Transparency is the core value that underlies the open source software and hardware movements. To put it simply, in open source, there should be no secrets, especially where failures are concerned. It’s clear that transparency is not a core value of The Martian’s version of NASA, which has huge impacts on people’s decisions.

Think about how much time is wasted at all layers of the organization in trying to keep the Rich Purnell Maneuver a secret (first when designing it, then hiding it, and ultimately implementing it). How much more efficient would it have been if Rich worked for a NASA where he could have simply said, “Hey. I have an idea to save Mark, but it is a little risky, so I am going to work on it as a side project for now”? Or, how about if the management team and the crew could have discussed the idea openly?

Linus’s Law, named after the developer behind the Linux kernel, says that with sufficient eyeballs, all bugs become shallow. The idea behind this law is that in open source software (and by extension hardware) the availability of more people to review and test a project leads to greater discovery of problems in that project. Greater discovery of problems means more problems get resolved before a project goes into production, making for a better project when it is released. Consider how much stronger the case for the Rich Purnell Manuever would have been (and in turn management’s confidence in the plan) if it had been developed as an open source project with many eyeballs discovering issues along the way instead of having to rely on just Vincent Kapoor’s (Chiwetel Ejiofor) word that it would work.

Rich was only one man, spending many sleepless nights in his office, racing to calculate, verify, and document his proposal before the Hermes got too close to home to implement it. With the right tool, like Mach 30’s Mathematics Tool Kit (MTK), he could have shared this work with collaborators across the world. MTK’s unique combination of calculation and documentation environments in one tool would have allowed Rich to focus on defining the trajectory while other contributors wrote the code to calculate and test the trajectory. Still more engineers could spend their energy documenting and reviewing the results. By using MTK to break the work into smaller, more specialized parts, Rich (and his team) could have completed the proposal in far less time than Rich ever could alone (and with far fewer all-nighters in Rich’s office).

In summary, compared to the cloak and dagger we see in The Martian, applying open source principles to spaceflight would have gotten Rich to a finalized proposal faster, given management greater confidence in the proposal, and allowed NASA to spend its resources more efficiently (no mutiny required).

So, what do you think? How could you have contributed to the open source Rich Purnell Maneuver? Could you have helped spread the word to your social network to help raise awareness for this approach to save Mark? Could you have coded up some of the math? How about peer reviewing the code or the math? Or by doing something else? Let me know in the comments. And as always, ad astra per civitatem!