Category Archives: Open Source

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

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!

How could Open Source Hardware have helped Mark Watney?

As many of you probably are aware, the plot of the new movie The Martian is centered around Matt Damon’s character, Mark Watney trying to survive on Mars long enough to be rescued after the other members of his expeditionary crew were forced to leave or be stranded. Mark, and later NASA, struggled to use the things that were left behind to keep him alive. All of the hardware, things like the rovers and life support systems, were portrayed as things that NASA designed and built themselves, and no one else had all the nitty gritty details about their design and function.

The Martian OverlookBut what if even some of these things were Open Source, so that anyone in the world could look at the plans to build them? Or even better, build their own? In the movie, NASA and Mark did a heroic job of finding solutions to the problems, but if the hardware was all Open Source, engineers outside of NASA would have been able to aid them. Perhaps the nearly fatal explosion of the resupply mission wouldn’t have happened? Other engineers might have identified the flaws and brought them to NASA’s attention. Or perhaps the men and women at JPL would have been able to get more things done quicker, without so much stress and overtime, because of the larger community lending them their support.

Open Source Hardware isn’t a panacea to all problems, but it opens up a lot of opportunities that don’t exist when the designs live behind closed doors. Most things have been developed in this closed source way in the past. With incredibly complexly engineered things like rockets and habitats for Mars, the level of effort to make those things a reality creates a tremendous barrier for others to build on what’s already been done. If even some of these things that organizations like NASA build had their designs and build procedures open to the wider community, or even the public, to view, use, and build upon, the community can not only help each other out when there’s a problem, but build better solutions and accelerate the pace of progress.

BeagleSat

Several years ago when our president J was getting his PhD in rocket propulsion, he suggested the university look into using cheap, relatively easy to use programmable micro controllers like the Arduino for controlling small satellites like CubeSats. At the time, other micro controllers like the Beagle Bone Black (BBB) weren’t available.

Yesterday, J came across a Google Summer of Code project called BeagleSat, which is the same sort of idea that J had, to have an open source framework for building CubeSats.

Furthermore, if we were to do something like this today, we’d lean towards the BBB because of its power and versatility.

We’re very curious to see how far they can take this project. They published weekly status updates on their project web page, and it looks like there’s some cool work done, but also a lot more to do. We’re always happy to see documentation being reported on a regular basis, and it looks to us like this will be a great open source hardware project.

Yavin Thruster Sprint 1

Mach 30 has started to use agile methodologies to manage its engineering projects, and the first of those to use an agile approach is the Yavin cold gas thruster. This last week, we completed our first sprint, and we’re all very pleased with the results.

For anyone that might not yet know about the project, it’s to develop a test stand connected to a source of pressurized gas, such as an air compressor, where different designs for the thruster can be tested. One of the aims for the project though is to develop and test new tools for future Mach 30 projects, such as CadQuery and our new Mathematics Tool Kit (MTK), a piece of software to make it easier to compile documentation around science and math proofs and analyses. We’re not only working to further develop these tools, but putting together a tool-chain for future design efforts. How this tool-chain works for Yavin is that we’re using MTK and a Python library to document and calculate aspects of the thruster such as wall thickness and nozzle shape. We can then create models with the same library in CadQuery, and export the model to be 3D printed.

In the first sprint, we took on 3 main items. The first of these was an export control review of the project, which can be found under the project’s Wiki on Open Design Engine. Second was a structural analysis of the gas chamber before the nozzle. The team generated a number of artifacts for this, including a document created with MTK detailing the analysis, a python library to support it, and an initial model created using CadQuery. You can see pictures of the model below, but the coolest part is that we printed it!

This slideshow requires JavaScript.

This is just a proof of concept model though (it’s huge, and not an ideal size at all!). There’s a lot more work to be done! We have to produce another (or add to the existing) library to do the actual thruster design, and a number of other tasks.   Some work to do to make it so that CadQuery supports all the functionality we’ll need for making a good performing nozzle, but we also have a number of tasks ahead focused around testing.

For transparency, there’s one more item we had planned on doing, and that was performing a test calibration on a volunteer’s 3D printer.  Doing so helps us to build up information about how to calibrate other printers for printing future Yavin thruster nozzles. We don’t just intend for Mach 30 to print these, we intend for all sorts of people to do so, so we’re trying to make it as easy as possible on our end to print one of these.

We feel we accomplished a great deal for our first sprint, and we’re all very proud. If you care to hear more about our first sprint, you can check out our sprint review and retrospective here.