prev next

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

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!

The Mach 30 Guide to ISS Tracking (And Sharing It)

290409main_iss_tracker_226

Example ground track of the ISS, from http://www.nasa.gov/

Did you know that the International Space Station (aka the ISS) typically flies over your head about a half dozen times every day? More importantly, did you know that you can actually see it happen with your naked eye?

Admittedly, you can’t always just look up and see it whizzing by. There are two reasons for this. The first is because the sky is too bright during the day. Second, during the night, all the Earth’s satellites are in its shadow. There are, however, two small windows each day in which it is possible to see the orbiting satellites flying overhead. These windows occur during the “terminator conditions”. Sadly, they have nothing to do with Arnold Schwarzenegger. They do, however, have everything to do with the transition from day to night.

The "terminator line" is the region on Earth between daylight and night time.

The “terminator line” is the region on Earth between daylight and night time. PHOTO CREDIT: Image by Norman Kuring, NASA GSFC, using data from the VIIRS instrument aboard Suomi NPP.

A terminator, also called “twilight zone” or “gray line,” is a line that separates the day and night sides of a planet. In other words, “terminator conditions” simply mean sunrise and sunset. During these periods, the Earth’s satellites come out of the shadow and are able to reflect the sun’s light. Besides that, the sky is lit up just enough to make bright objects visible, but not so much that they’re drowned out.

The weather and sky conditions also play an important role in how well you are able to see the ISS as it flies over.  Obviously, you won’t see anything if it’s cloudy, and you won’t want to go outside if it’s too cold. Therefore, you want to be smart and plan ahead. You can get a weather forecast anywhere, but “sky conditions” are a little harder to find. Sky conditions determine two things: cloud cover and the probability of rain. You also want to know the moon’s current phase because that affects how well you can see at night. You can check out the Sky Charts from Clear Dark Sky to make sure.

BlackfootCSK from http://www.cleardarksky.com/

Clear Sky Chart — Sample forecast of “seeing conditions” put out by http://www.cleardarksky.com/

Basically, there are three things you need for your ISS tracking project to be successful:

1.) Know when and where to look

2.) Use a recording device

3.) Post it online and tag Mach 30

Let’s dig a little deeper into the details, shall we?

1.) Know when and were to look. In general, just before dawn and just after dusk are the best times to look. Several websites will calculate the exact times for you, and most will also give you specific directions in which to look. Here are my personal favorites:

Heavens-Above. This site is the most technically accurate and computationally full featured. This is best if you are comfortable with tech and have a basic understanding of astronomy. Besides the ISS, it has a ton of other satellites that you can track.

NASA’s Spot the Station. Probably the most user-friendly option — it is NASA’s ISS after all, which means they have the best resources.

Satellite Flybys. Just enter your zip code and voila! It’s not the most accurate, but more than good enough to get you looking in the right direction.

ISS AstroViewer. Of all the sites on my list, this has the least features. It’s not very complicated, but it still tells you when and where to look. All you need is to input your city name.

2.) Use a recording device. Like we said, the ISS is usually bright enough to be seen with the naked eye, and therefore a decent quality camera or even some camera phones will be able to see it. Of course, the better the camera, the better the quality of pictures and video that you can get. If you can get your hands on an SLR camera and some good telephoto lens, even better. If your device allows it, use “low-light” or “nighttime” mode. If you’re using a DSLR or manual lenses, adjust your apertures, ISO settings, and exposures accordingly. Long exposure photographs will produce a “streak” as the ISS flies through the frame. 

Flickr user Paul Williams via Creative Commons

PHOTO CREDIT: Flickr user Paul Williams via Creative Commons

You’ll also want to use some kind of stationary object to steady your camera, like a tripod or luggage rack of a parked car. This is especially important when you’re using telephoto lens or low light settings, because your device will be much more sensitive to movement, and therefore more likely to blur. The more versatile the mount, the better.  The ISS doesn’t hang around in any area for vary long, so get ready to readjust the field of view as the station moves across the sky.

Trust me, you’re going to get excited and want to gasp, and point, and do a little dance when you spot the iSS (or is that just me? No, it can’t be). So again, plan ahead and set the camera up early, leaving you to enjoy the event without worrying about messing up the shot.

3.) Post online. All that hard work and success deserves a little recognition, and we at Mach 30 would definitely love to see what you get. Just post it on your favorite social media site (or all of them, because why not), and tag us. Use @Mach_30 on Twitter, @Mach30 on Facebook, +Mach30 on Google+, Mach30-blog on Tumblr, and Mach 30 on YouTube. Then you can brag about your ISS tracking skills!

Have fun!

Mach 30 ISS Tracking - ISS flyover

PHOTO CREDIT: Greg Moran, cerca 2010 in Dayton, OH via Creative Commons.

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.