Category Archives: OSHW

Shepard Test Stand is now OSHWA Certified Open Hardware

Nov 7 2016 by web.

Mach 30’s first hardware project was the Shepard Test Stand, a piece of hardware we designed to run tests on commonly available Estes rocket motors. From day one, it was a piece of Open Source Hardware. Now it’s an Open Source Hardware Association (OSHWA) Certified Open Source Hardware, receiving serial number US000006. shepard-oshwa-cert

OSHWA created the program primarily as a way to help people identify that a piece of hardware meets the commonly accepted definition of Open Source Hardware. This includes such points as the ease of access to the documentation, licensing, and others. All of these items are related to keeping the hardware as accessible as possible for others to recreate it themselves, modify, or even use parts to create their own unique piece of work.

Mach 30 was invited to participate in a closed trial of the process to certify that a piece of hardware should receive the OSHWA Certified Open Source Hardware badge, and as such we were privileged enough to receive one of the first serial numbers, US000006. If you’d like to learn more about the Shepard Test Stand, you can find out more on the project’s page on Open Design Engine.

Shepard Rocket Motor Test Stand

There were 60 separate projects registered, from 9 different countries from around the world. For more information about these first projects, check out the post on oshwa.org. If you’d like to learn more about the registration process, that link also contains a link to the registration form.

Hosting Open Source Hardware Projects on GitHub

Mar 21 2016 by Chris Sigman.

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.

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.

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.

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.

How could Open Source Hardware have helped Mark Watney?

Oct 6 2015 by Chris Sigman.

1 Comment

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.

But 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

Oct 2 2015 by Chris Sigman.

Comment

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

Jun 22 2015 by Chris Sigman.

Comment

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.