Blog Archives
Introducing the Shepard Test Stand: Mach 30′s first Open Source Spaceflight Project
by Jeremy Wright, Innovations Technology Solutions, LLC
[Editors Note: I’ve been asking you to be patient on the hardware front for years now, so believe me when I say words cannot capture how excited I am to introduce you to Jeremy Wright--a new Mach 30 volunteer and major contributor to our very first open source spaceflight hardware project. Thank you Jeremy for taking us over the breach--and thank you, patient reader, for sticking with us through the “boring” parts.]
Shepard Test Stand Block Diagram
Mach 30’s Shepard Test Stand project has contributors spread over 4 U.S. states and 2 different time zones, so making sure that everyone gets a chance to leave their mark on the project can be a real challenge. Add to that the fact that we’ll not only be exchanging ideas, but also things like drawings and source code, and the challenge gets even more interesting. This kind of collaboration is possible because of what Mach 30 is doing through the Open Design Engine.
On Shepard, we’ve started this collaborative process in the project’s forums and wiki by working on the why, who, and how questions that will guide us through the rest of the design process. These are seemingly simple questions like:
- “Why are we building this?”
- “Who’s going to use this?”
- “What features does it need to have?”
However, without solid answers to these questions we run the risk, as contributors, of not all pulling in the same direction. As we head deeper into the project, these answers are being turned into a list of requirements that will keep us grounded and focused throughout the life of the project. That way we’re all on the same page, and when we get to the more exciting tasks of building and using the test stand, we’ll have our best shot at hitting the target. These requirements will start to pay off right away by informing the creation of the system block diagram, which is our next step.
If you haven’t yet, swing by opendesignengine.net and look over the Shepard Test Stand project. ODE will be moving into public beta soon, and we’d love to have the help of anyone who’s interested in moving humanity toward a space-faring future.
In short, “ad astra per civitatem” – to the stars through community
What about ITAR?
Image by Jeremy Brooks via Flickr
One of the first questions people ask when I talk about open source spaceflight is “What about ITAR?” It’s no wonder. Nearly everything to do with spaceflight technology is export controlled, making it illegal for US citizens and permanent residents to openly share spaceflight hardware and its supporting documentation. Needless to say, ITAR is a significant challenge for Mach 30 and other open source spaceflight groups.
I’ve spent a lot of time thinking about how Mach 30 might approach these challenges. The short answer is obvious. We work within the boundaries of ITAR. That doesn’t mean, however, we are abandoning are open source values.
The long answer is we need to develop a combination of approaches to openly publish as many of our projects as we can, while ensuring we are fully compliant with the requirements of ITAR. To that end, I’ve come up with four potential paths that might allow Mach 30 to develop spaceflight hardware in a (mostly) open way, while still staying in full compliance with the restrictions placed upon US based persons under ITAR.
Develop quasi-open source spaceflight projects
The first approach to dealing with ITAR, and in the early days the most noticeable approach, is running quasi-open source spaceflight projects. Mach 30 could host all of its spaceflight projects on a private copy of Open Design Engine, access to which will be limited to individuals who we have verified are US persons and who have received appropriate ITAR training in order to comply with ITAR. If you look at the formal definition of open source hardware, one of the requirements to be open source hardware is providing unrestricted access to the design documentation. Our space projects will fail to meet this requirement due to our insisting people agree to follow ITAR in order to gain access to our designs, hence calling them quasi-open source.
Create a catalog of published spaceflight technology
The second approach is crowd sourcing a catalog of the large body of published spaceflight technology. Why is this important? Simply put, any technology which is already published in public literature is exempt from ITAR. Let me repeat, if you can find a public article, book, or other source which fully documents a piece of spaceflight technology, then that technology cannot be withheld by ITAR. And, it turns out there is a large body of scholarly articles, textbooks, and government reports, especially from NASA, covering spaceflight technologies. Mach 30 could launch a new wiki to catalog, tag, and for openly licensed materials, archive publicly available materials concerning spaceflight technologies. This new wiki will be a public resource to help identify which projects need to be quasi-open source, and which can be fully open source.
Develop core technologies in non-space disciplines
The third approach is developing technologies as part of fully open source projects in non-space disciplines. Many core systems which are important for spaceflight are also applicable to non-space applications. Examples include power management, sensing, and command and control. By developing these systems in non-space applications, we could avoid the ITAR triggers and still develop the systems in full compliance with the definition of open source hardware. Projects could include solar powered robots to develop power management systems, autonomous Remotely Operated Vehicles (ROVs – remote controlled submarines for underwater exploration) to develop sensors and their related systems, and high altitude balloons to develop command and control systems. Once the technologies have been developed in these fully open projects, they can be ported into the quasi-open projects for use in space applications, but the core development will still be available in the non-space projects.
Partner with non-US groups for technology transfers
The fourth and final approach is to establish partnerships with non-US groups and to develop approved technology transfers. One such group Mach 30 is already discussing this approach with is CSTART. CSTART is an open source space organization which started during an online discussion at reddit.com. Its membership includes people from all over the world. At a recent joint meeting on ITAR, CSTART and Mach 30 discussed CSTART becoming a non-US group and its US members joining Mach 30. Both groups could then work within ITAR and other export control regimes, while they investigated the processes required to transfer technology into or out of the US. We imagine it will be easier to transfer technology into the US, but we will work diligently to find opportunities to legally transfer technology both ways.
So,where once there was the big scary ITAR, we now have a potential path forward for open source spaceflight. Please share your ideas for additional paths, as well as potential pitfalls of these suggested paths, in the comments!
ad astra per civitatem
End of the Space Age? Or a Time for Reinvention?
Image via Wikipedia
The Economist has dedicated an issue to the “end of the space age” suggesting over three articles that the promise of the space race has faded, political will eroded, and public interest evaporated. Who can blame them? Aging isn’t easy! Like life, it always seems more exciting when you’re young and free and visionary.
Kennedy mesmerized the world with sheer audacity of launching the space race. Without a doubt the excitement led to incredible achievements built on competition and daring goals. It helped, of course, that this competition had political objectives and seemingly unlimited resources to back it up.
When the shuttle program took off, it galvanized the world, again, around the possibilities of new technologies and intrepid journeys. The shuttles made it possible to create and support the International Space Station with which the shuttle has docked for that last time. I know I was captivated by the possibilities the ISS provided that unfortunately never materialized for most of the American (and global) public. Indeed, The Economist got it right that, over thirty years, the space program has become commonplace, mundane—just another trip to the International Space Station. But, where the The Economist sees the mundane Mach 30 appreciates the mature.
There’s less fanfare in building the foundations, but Mach 30 is focused on a new audacious goal—Open Source Spaceflight Hardware; cooperation that moves beyond government agendas or private industry to a community-led effort. Shuttle technology never focused sufficiently on building the mature technologies that could be leveraged for missions further afield. Imagine what small steps over 30 years might have meant to a spacefaring future.
Mature technologies (perhaps with small changes or new uses) are the foundation of successful systems. It’s critical that those systems be sustainable also in order to make long-term space travel a reality. Mach 30 goes one step further by placing open source as a central springboard for innovation to keep barriers low and advancement rapid among communities of practice—reaching for the stars through community.
Mach 30 accepts that moving a little slower but very deliberately may actually be the quickest route—even admitting we do miss some of the excitement of the race! That is maturity indeed.
And, yet there are dreams to be achieved. There are bold goals yet to be named. Find them with us—whether you’re a space enthusiast or simply recall shuttle memories—by joining Mach 30’s community. Donate. Friend us. Contribute to Open Design Engineering. With an open community leveraging mature technologies for sustainable travel spacefaring will be a reality.
