Tag Archives: Open Design Engine

Shepard Rocket Motor Test Stand | Apogee III | Mach 30

Hosting Open Source Hardware Projects on GitHub

by .
Comment

In response to us posting some information about our 2016 annual plan, we got a comment with some great feedback from Benjamin Brink that touched on a lot of different things. One of those that we wanted to respond to in more detail was hosting Open Source Hardware projects on GitHub.

hosting open source hardware projects

GitHub is great for hosting software projects, and is a good tool even for hosting and collaborating on other text-based goods like books (you can see some on GitHub’s Writing Showcase). These could be quick, small pieces of software from a ‘hello world’ application that only prints a predefined message, to large, incredibly complex feats of engineering like the Linux kernel.

The difference between software or books and hardware is very important, though, and is why we feel GitHub isn’t a great tool for hosting open source hardware projects, or documenting and collaborating on them. This difference is that there’s a lot more items that make up what is really needed for a piece of hardware to be Open Source than text.

These items of the project that I’m talking about, for any project that is more complicated than a simple breadboard or a few components that are easy to see how they go together, are things like build instructions. Regardless of your expertise, telling someone how to build a physical thing from parts requires pictures. A good example of what I’m talking about can be found in our own Shepard Test Stand project.

hosting open source hardware projects

Shepard Demo Sneak Peak

There’s no way to describe in text how to assemble Shepard and expect people to be able to easily reproduce it. All the Open Source Hardware projects we’ve seen on GitHub either fall into the simple category, and even those that don’t, like KickSat, don’t have build instructions. KickSat sort of gets around this by using SOLIDWORKS to show the assembly, but this requires you to pay for SOLIDWORKS.

Now, you could put together build instructions into a PDF or another file format that isn’t just text and images, but this doesn’t make it easy to collaborate. What people working on Open Source Hardware, as well as those just using the designs to build their own need, is tools like a full-fledged Wiki, so that beyond just text and images like I mentioned, other media such as videos can be included all in the same documentation.

The needs don’t stop there either. As these projects get more complicated, and involve people with backgrounds that don’t include software development, there becomes a need to accommodate people that aren’t comfortable with version control software. These contributors might be mechanical engineers, or photographers, or any other discipline. Unless all of these people can contribute with gentle learning curves, the Open Source Hardware community won’t be able to grow as large or as quickly.

hosting open source hardware projects

Open Design Engine, where we host Shepard Test Stand and other projects, is our way of providing some of these capabilities in one place, instead of across a handful of different websites, making it easier and more likely for projects to be truly Open Source. In all openness and honesty though, Open Design Engine has its shortcomings. We haven’t had the resources to invest in making it great. It’s a minimally viable product, and gives us just enough to be able to make our projects able to be collaborated on and truly Open Source.

Ultimately though, different projects have different needs. Many projects, for a variety of reasons, are relatively simple, and GitHub might be enough. If the project is simple, I’d consider recommending GitHub, if only because of its polish. But hosting open source hardware projects need a better, more advanced environment than that offered for the software world, and that’s the whole point of ODE.

Jones Boys’ Rocketry

by .
Comment

As Open Source Spaceflight Hardware (OSSHW) developers, we love to see other people building, modifying, remixing, and using our designs. In fact, we believe that the “Prime Directive” of Open Hardware is that it must be reproducible. That’s why we got so excited when we were contacted through Open Design Engine by John and Christopher from Jones Boys’ Rocketry. Christopher was working on a rocketry project for school, and was attempting to get a copy of our Shepard Test Stand thrust measurement hardware working.

John and Christopher

John and Christopher in February of ’08

Having someone build your Open Hardware has another advantage – you find more bugs and design flaws. The more people build and use your hardware, the better it gets. Our work with Jones Boys on Open Design Engine was no exception. They found a couple of bugs in our software, and their work brought about some operational improvements that we had glossed over because we’re so used to the hardware.

Christopher Testing the Shepard Hardware

After about two weeks of back-and-forth work, John and Christopher were able to get a successful data capture with a live engine.

Jones Boys’ Test Firing

Christopher was able to collect and analyze data from various motor fuel grain configurations and assembled everything into his science fair project display.

Christopher’s Display

Christopher took his display to multiple science fairs, and did extremely well. He was in 9th grade when he competed, and in the regional ISEF Science Fair, took first place in physics for his group. After that he went on to win second place in the American Institute of Aeronautics and Astronautics fair, which included a $100 cash award and a 3 day workshop at Goddard (I’m very envious). He also got an honorable mention from the USAF Office of Scientific Research.

Christopher Explaining His Project at the Science Fair

Congratulations to Christopher for doing a great job, and thanks to him for using Mach 30 hardware. We’re always excited to work with people who want to build spaceflight related hardware without starting from scratch. If you’re interested in building a rocket motor test stand or satellite receiving ground station, please feel free to contact us. We’d love to talk with you.

ad astra per civitatem – to the stars through community

Related Links

ODE Project Spotlight: Photosynq

by .
Comment

Back in March, we had our first Open Design Engine (ODE) Project Spotlight, a Google+ Hangout where we talked with the guys behind Photosynq. The project is aimed at bringing data collection about the health and growth conditions of plants out of a few greenhouses and into the hands of crowd-sourced researchers everywhere.  In our hangout, we not only talked about what Photosynq is, but also how the project developers are using ODE and other tools to manage the project. You can watch the video of the hangout through YouTube:

We got a lot out of speaking with Greg and Robert.  It was great to learn how others are using the tools available in ODE, but we were especially excited to learn about some of the technologies they were leveraging.  Jeremy and I found the data analysis tools they’ve developed, with some 3rd party libraries, something great that we might be able to leverage for the Shepard Test Stand.

We hope to have other Project Spotlights with other projects hosted on ODE in the future.  If there’s one in particular you’d like to vote for, please leave a comment! Thanks again to the guys at Photosynq for spending the time to hang out with us and talk about their project.  You can learn more about Photosynq on opendesignengine.net

Working Virtually

by .
Comment

Over the last couple of months the Mach 30 community has been talking more about the concept of virtual Makerspaces. I’m guessing that most of our readers know what a Makerspace (a.k.a. Hackerspace) is, but just in case, I’ll give you a definition I might use.

Makerspace (n.) – A space, normally a physical room or building, where people come together to share resources such as expertise, manpower and tools. This is done to help complete projects that the makers might not otherwise have the resources for.

Some people come just to hang out and see what’s going on, but most come to work on projects. Whether you’re working on arts and crafts or spaceflight hardware, I have yet to find a Makerspace that didn’t welcome all kinds of projects.

The Mach 30 spaceflight hardware developers are spread across the U.S. and we’re always looking for better ways to collaborate on protects. Traveling would be one way to work together, but that gets expensive. We recently changed our Thursday night Google+ Hangout schedule so that we could have a dedicated hardware (a.k.a. “#EngineerSpeak”) Hangout. This will allow us to partially address our collaboration needs.

Mach 30 Hangout

A Typical Mach 30 Google+ Hangout

The intent was to make it free form so that the things the attendees wanted to work on was what would be worked on. Just like a Makerspace. The first week ended up being more of a normal meeting where I asked for feedback on the Shepard Test Stand software. That was a great Hangout that really helped but the second week’s hardware Hangout ended up feeling much more like a Makerspace, partly because of an engineering challenge that J. Simmons gave us.

The engineering challenge was to see if we could convert the Shepard Test Stand application from Processing to Python in 10 days. That way we could test Python’s viability for use in our Shepard 2.0 kits. As we started that second week’s #EngineerSpeak Hangout, we discovered the need to make some significant changes to the sample code that I wrote to meet part of that challenge.

Shepard Test Fire 2 - E12-8 engine

There were 5 of us in attendance, but Chris Sigman and I were the only two who had accepted J’s challenge. This diversity of interests and focuses had the makings of a great Makerspace environment. Here are a couple of reasons why:

  1. Even though Chris and I weren’t in the same room, we were able to work on the code collaboratively in real time. We worked through the code, sharing solutions to some problems and talking through possible fixes for others. The only thing that would have made it better is if we had both been logged into a shared code editor so we could have been editing “over each other’s shoulders.”
  2. Even though they weren’t working on the engineering challenge, the 3 other Hangout members hung around to work on their own projects. This allowed them to comment on what Chris and I were working on and share things about their activities as well.

It was 5 people sharing a space and resources, working together and independently in true Makerspace style. The Hangout ran long, but before it was over Chris and I had fixed the code and I was left with the feeling that this Hardware Hangout stuff might have some major potential. Couple that with the ability to work on our projects collaboratively on Open Design Engine, and we have a couple of powerful tools to allow us to do distributed development.

As time goes on we’ll be developing and refining our methods of distributed collaboration. It’s a critical part of our mission and we hope you’ll join us on the ride. Stay on the lookout for a future post on how we’re starting to use Open Design Engine as a virtual Makerspace as well. If you’re interested in learning more about Mach 30 and our hardware projects, please add Mach 30 to your Google+ circles and request an invite when you see Thursday night Hangout announcements.

Related Articles

Gravitas at Mach 30

by .
Comment

Gravitas (n.) – An ancient Roman virtue that denotes seriousness and dignity. It encompasses the depth of knowledge and/or personality that comes with experience. A very old word, but a modern circumstance.

So, how do you decide who’s got it all together in a field of endeavour as broad as ‘Space’? In any situation, you look for the survivors. Those who’ve been in the ‘game’ the longest with the most success. In something as new as the Open Source Space Movement, it can be a little more difficult. This is because a good web presence or a flashy marketing video can imply credence, sometimes more than actual content can. You have to dig past the ‘vaporware’ to find the real foundations. Another telltale sign is the language. Not the difference between German or Swedish or English, but the language of the non-tech, the space enthusiast, and the astronautical engineer.

Open Source is a confusing maze for newcomers. It is a difficult paradigm to wrap the brain around when all of your existence has been cocooned in a proprietary existence. Add “Space” to that and life gets interesting. Out of the 754,000,000 hits on a search engine, where do you start? What values, what gravitas do you look for? How does this relate to Mach 30?

cropped-mach30webheaderwordpress1.jpg

Here are some of the things that we have done to promote gravitas.

Organizational maturity:

  • Mach 30 is a 501(c)(3) public charity. We’ve built a solid foundational base on which we established the organization, with the IRS paperwork to prove it
  • Strong business processes including openly shared documentation, meeting minutes, strategic plans, etc.  These provide transparency.
  • We seek out like minded organization and work with other non-profits, makers spaces, government entities, and the broader aerospace industry.

Technological stepping stone approach

  • Being biased towards mature technology means we can build and test now.
  • Having learned from the misatkes of others, we avoid the “death spiral” of giant development projects that will cost large fortunes.
  • Pursuing a technology “Road Map” development plan instead of jumping-in to shiny and fun projects
  • Tackling the true barrier to safe, sustainable, routine, and reliable spaceflight:  Namely affordable and reusable spacelift.

Open hardware development and Open Design Engine

  • True open source hardware projects (space-related or otherwise) need to share their WHOLE project, from inception to disposal.  Mach 30 does this on ODE.
  • In fact, Mach 30 is responsible for the development and operations of the opendesignengine.net because we identified this as an unfulfilled need, then filled it.  
  • Mach 30 conducts its work using open systems engineering processes.  Open source hardware development with distributed collaboration is different, as we’ve learned from past projects.

Identified need to deal with Export Controls, ITAR and more

  • Working to understand Export Controls
  • Having an Export Control Task Force
  • Meeting regularly to expand our knowledge and compliance of Export Controls

Each of these works combine to build gravitas. We’ve been at this for four years. We ask ourselves these questions frequently, “Are we doing this right?” “Are we true to our vision?” “Is this right/correct/needed?”. We strive to complete our goals. We work to make our little corner of the Open Source Space Movement a little better each day. We don’t have all the answers, but we are willing to share what we know.

Mach 30 is gaining gravitas, little by little. Each conference we attend, every event we hold, and every failure we review and improve upon adds to that weight. We are by no means perfect, but well will continue to work towards bringing humanity into a spacefairing civilization.

~ ad astra per civitatem ~
to the stars through community

Related Articles: