Hosting Open Source Hardware Projects on GitHub

Mar 21 2016 by Chris Sigman.

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.

Mach 30’s 2016 Annual Plan

Mar 16 2016 by Ingrid Velasquez.

7 Comments

Most of your New Year’s resolutions have probably faded into fond memory by now, so why not pick up a new one? We’re excited to share Mach 30’s 2016 Annual Plan because we’re constantly on the lookout for volunteers to help us make our dream of open source spaceflight come true. We may not have cookies (we’re not the Dark Side, and we don’t have the budget for it — yet), but we do have very cool plans ahead.

This year’s project list is divided into three categories: rocks, pebbles, and sand. Dr. Stephen R. Covey, entrepreneur and author of The Seven Habits of Highly Effective People, tells a parable to explain this principle. Rocks are top priority, pebbles next, and sand last, the moral being that, “If you don’t put the big rocks in first, you’ll never get them in at all.”

The biggest priority on our list is developing Ground Sphere. This is a small, portable satellite receiver that you can use to eavesd— erm, listen to voice communications from the International Space Station. We also want to look into the viability of developing Ground Sphere as a product that we could possibly sell, which is why after building the prototype, we want to demo it so we can gauge interest.

Other rocks include the board’s annual strategic planning retreat during Apogee 3 (Mach 30’s annual outreach event), and recruiting both board-level and non-technical volunteers. We’ve realized that the organization would be served well by having a diversity of talent.

Onto pebbles: we’re continuing marketing activities because we want to at least double our reach this year. You may have noticed that we’re publishing more content than before and that we’ve restarted our newsletter.

Also in the pebbles category are the actual Apogee 3 Public Outreach Event, plus acquiring D&O insurance by January 2017.

Lastly, we move on to our sand activities. We’re supporting the Open Source Hardware Association by either becoming a corp member or being a sponsor at the Open Hardware Summit this year. Also, we’re publishing the Mach 30 Annual Report for 2015.

We’ve also categorized the projects into large, medium, and small, depending on how much time, money, and manpower we need to complete them. Looking at it in this way helps us determine if we’re doing too much or not enough. More importantly, it helps us assess if we can do the things that we really need to do, what with our (current) lack of resources.

Ground Sphere development and planning for Apogee 3 are considered large, while recruiting, the Apogee 3 event itself, and publishing the annual report are medium. Lastly, marketing activities and the OSHWA sponsorship are small.

Another way that we’re grouping the projects is according to whether they’re administrative or mission. Administrative tasks involve taking care of and growing the organization (recruiting non-technical volunteers), while mission tasks are those that fall in line directly with our mission statement (developing Ground Sphere).

You’ll notice that two-thirds of our tasks this year are admin. That’s because we want to focus on growth right now so we can do more mission work in the future.

We’ve figured out some time ago that Mach 30 is relevant to three communities: makers, space enthusiasts, and open source hardware enthusiasts. The numbers on the chart are the product of a quick calculation of how activities would impact these communities. As you can see, we’re trying to make sure that our activities are equally interesting to all three groups.

Projects also fall into three major areas based on Mach 30’s IRS-approved non-profit mission. As explained by Mach 30 president J. Simmons, “OSHW means supporting the OSHW community (because a rising tide helps all ships, think things like open source cad software and Open Design Engine). Ed is for education and outreach (because more people need to understand about space), and OSSHW is open source spaceflight hardware (that being our main thing of course).”

Last but not the least, in keeping with our efforts to recruit more non-technical volunteers, we’re putting more effort into visiting incubators and idea places. We want artists, writers, photographers, marketers, and business-minded individuals to join and help our cause.

Part of why we’re doing this is so we have a document to guide us through the year. It also helps keep us accountable as a team. The other part of why we’re sharing this with you is because we hope some of you will get excited enough to want to join us!

Check out Mach 30’s 2016 Annual Plan in infographic form below. Click here if you’re interested in volunteering, or email us at outreach@mach30.org.

Making a Paper Sundial in 15 Minutes

Feb 22 2016 by Chris Sigman.

2 Comments

A few months ago, I came across an Instructables project for a paper sundial. Papercraft projects are some of my favorites, because all I usually need is basic elementary school supplies that are lying around the house. Some of them are probably even from when I was in elementary school! Even better: because we’re working with paper, it doesn’t hurt much when you mess something up. With how easy this is, it’s a great project for all ages, especially for kids or your inner Maker!

Completed paper sundial

You can find all the instructions and resources you need for this 15-minute project at Instructables. As a brief overview though, the writer created an online tool you can use to generate a PDF that customizes the sundial for your location, and whether you want it set up for summer or winter. From there, you print, cut, glue a little, and you’ve got your very own paper sundial.

There’s one thing that I found a little tricky though, that I thought I’d share so you can benefit from my experience. In step 4 where the paper sundial instructions talk about how to fold the gnomon (the piece that casts a shadow to show you what time it is), I found it a little unclear how the folds should look, and even glued the wrong things together.

No worries though, because like I said before: it’s paper, and you can just print out a second gnomon! Below is a picture of the northern-facing side of it, to give some extra perspective. Hopefully that makes things clearer for you if you ran into the same problem I did.

North side of paper sundial gnomon

Once I was all done, I noticed that my gnomon of my paper sundial wasn’t quite straight. The instructions point out some ways to avoid or fix this, but I went with a different route. When I cut out the dial, I glued it on some card stock (aka thick paper if you’re not familiar with it). So, to straighten out the gnomon, I just cut some of the excess from what I used for the dial, folded it in half, and glued it on. Perfectly straight now! In the picture below, the darker area of the gnomon you see is where I glued on the cardstock.

Sundial gnomon reinforcement

With daylight savings time mixed with winter weather consisting of a lot of clouds and snow, I haven’t been able to take it for a test drive. It’s a bit hard to catch days that are sunny and will therefore let the sundial cast more of a shadow, but I’m confident from some of my pictures that it’ll work perfectly.

I think I might even upgrade it to something out of stainless steel next time! This obviously would require more than some scissors and some glue (think Dremel angle grinder with a cutting wheel). If you’re a Maker, you might even try reproducing an antique sundial, such as those in the Liverpool Museum’s Collection

Finally, for some extra education: why are the hours in the dial not evenly spaced? After all, the Earth doesn’t rotate at different speeds throughout the day (although when you’re at work or in school, it can feel like it’s slowing down). The reason why is because this is a horizontal sundial, one that sits flat on the ground. Equatorial sundials, like picture below of a sundial in Beijing, have their dial aligned with the angle of the sun on the sprint and fall equinoxes. This makes it so that the shadow cast by the gnomon directly follows the motion of the sun, and thus the motion is constant. One more thing to know: on days residing on the winter side of the equinoxes, the top side of the dial is used to show the time, and the rest on the bottom side.

Equatorial sundial in the Forbidden City, Beijing. Picture from Wikipedia.

I hope you enjoyed making a paper sundial, and maybe even learned some things. If you’ve gone the extra mile and customized your sundial, we’d love to hear about it (or even see it!). Post a comment here, or even better, show us on Facebook, Twitter, Google+, or another social media site of your choice.

Applying Open Source to Rocket Landings

Dec 21 2015 by Matt Maier.

Comment

Blue Origin landed their booster back on the ground after lifting a capsule into space (or mostly into space, whatever). This is an awesome development. We need rocket landings and not just rocket launches to make them as reusable as airplanes to bring down the cost of spaceflight.

SpaceX and Blue Origin Rocket Landings

Of course, Jeff Bezos talked about what Blue Origin achieved and, of course, Elon Musk of SpaceX and other fame felt the need to throw a little shade and talk about how SpaceX is better. Billionaires will be billionaires.

I expect we can get this kind of development out of the way faster, and make everything about space cheaper, if we adopt an open source approach to the technology. Leaving aside concerns about export controls for the moment (which pretty much would put them in jail if they shared anything with people outside the U.S.), it’s just cheaper to solve problems if you already know what’s worked for someone else.

Open source was invented so that companies could safely use public code in their for-profit endeavors. People can use it too. Aliens could use it if they wanted. Anyone can use it, but the “people” who are happiest are the corporate lawyers because they don’t have to worry about their company getting sued. It’s an important distinction because sharing is an old idea, and open source is a lot like sharing, but open source ain’t sharing. Open source is a legal standard, not a moral or ethical standard. When individuals want to share they rarely bother applying a license to their work.

ohw_logo-golden_orb

There shouldn’t be any doubts about guys like Bezos and Musk knowing what open source is. Bezos clearly knows what open source is and intends to use it without commenting or contributing. Musk actually invoked open source when he allowed the world to use Tesla’s patents. However, in contrast Musk also said that SpaceX doesn’t patent anything because then China would know what they’re doing and copy them. Bezos tried to patent the idea of landing a rocket but Musk helped block the patent, arguing that tons of people already know how to do a rocket landing. So, if they know what open source is, why don’t they recognize its potential for creating cheaper solutions? I’ve got a theory on that, but first a bit of context.

There’s a bit of tension, then, between the perspectives of individuals and corporations. The corporations (SpaceX, Blue Origin, etc) only “share” when it’s safe and profitable. The masses share pretty freely, but only license what they share some of the time. So if we wanted to get lots of people throwing in on designs for reusable rockets we’d need to reconcile the difference between those perspectives.

Open source works best for infrastructure type technology; stuff that everyone needs. So we might be able to build up technology from the masses that’s used in many things and can also be used in spaceflight. A more fanciful possibility is using something like a Distributed Autonomous Corporation to organize the effort of the masses around actual spaceflight technology without a traditional corporation. We might even be able to eventually educate the people who run spaceflight corporations on the benefits of sharing development costs, but this is supposed to be a non-fiction piece.

There’s inherent issues with Open Source though when it comes to hardware. There’s a lot of activity in open source software because there aren’t really any barriers to building source code into object code, whereas things like an open source 3D printer (see RepRap for probably the first), you need to buy lots of materials that you might not otherwise have, and then, oh, you’ve got to build it. There’s not some machine that’s going to do it for you like software. There’s activity around many electronics projects, and a few mechanical projects, because turning the source into object isn’t too onerous. You can perhaps see how something like a rocket get’s hard to open source.

For something like rocket landings though, most of the systems are already in place. You already used the power of the rocket to go up, so slowing down can be done the same way (and is by Blue Origin and SpaceX). Just fire the rocket in the same direction, away from the ground, again. That’s super over simplified, but it’s to make a point. If Bezos and Musk (and NASA and ULA and maybe more) decided to start working together on the problem of landing, they already have 80% or more of the things they need. The last 20% is a bunch of hardware and software performing tricks for controlling the rocket on its way back down that they both sort-of have working, but it’s not 100%. Even if it has been proven to work after multiple orbital launches, there’d be more things to improve on. Like landing on a barge in the middle of the ocean where it’s moving around tons.

Landing the Falcon 9, via SpaceX

They could start open sourcing the landing systems so that they can do hard things like landing on a barge in the middle of the ocean with the likely super complex software SpaceX designed to take in all sorts of information from sensors all over the Falcon 9. It could then be worked on collaboratively with other organizations (again, NASA, ULA, etc). They could even sweeten the deal with a list of the sensors that they’re using with it, where they go on the rocket, etc. If they aren’t commercial, off the shelf (COTS) items, things like that would be great to share their design and manufacturing with the likes of Blue Origin under an open source license too. With that done, as Blue Origin uses that software and those sensors and integrates them with their rocket and whatever they’re using to “balance a rubber broomstick on your hand in the middle of a wind storm” (via SpaceX) that is rocket landings from space, they can suggest ways to improve it, or even contribute their own improvements! All of the other bits of the rocket like the engines don’t have to be open sourced as well.

What’s better, is now the rockets are cheaper for more reasons than one. Yes, they’re reusable. But there’s not nearly enough people doing the same thing at 2 or more different companies. Now they’re working together, and that means developing better landing stuff faster, whether that’s software controlling the rocket, or the hardware helping it stay upright and not turn into a giant fireball (see videos of attempts at rocket landings on a barge).

Mach 30 At the Open Hardware Summit

Dec 7 2015 by J Simmons.

Comment

This is a bit late, but I still wanted to share what went down at this year’s Open Hardware Summit. I was excited to be part of the event because it was a great opportunity to meet like-minded people and share what’s been going on with Mach 30.

The key to “open source hardware for all” is high-quality open source engineering tools.

This message has been one of the key themes of Mach 30’s work in 2015. Our technical projects have been shaped by this value, Jeremy has been connecting with a group from MIT to explore open source CAD, and I have been talking about this value on our blog and at the summit (check out the Open Hardware Summit presentation in the video below or in the slides on Google Docs).

At Mach 30, we use open source tools for all our projects. This is because we want to give everyone the ability to take part if they have the time and inclination to do so, and not be restricted by the tools they don’t have.

One example of such a tool is CadQuery, a Python-based parametric CAD language, which is actually inspired by JQuery. Some of the reasons we chose to use it over other open source tools: it’s easy to use, it has a powerful API, and it has an active development community. We like it so much, and we think it’s so useful, that we are actively contributing to the project.

Without high-quality open source engineering tools, we limit participation in Mach 30 projects to individuals and groups with access to tens or hundreds of thousands of dollars in proprietary engineering tools. Our mission of hastening humanity’s advancement into a spacefaring civilization is too important and too big to put these kinds of limits on participation.

That said, please join us in developing and supporting high quality open source engineering projects like the ones below:

If you want to learn more about our cold gas thruster, check out the Yavin Thruster project on Open Design Engine.

ad astra per civitatem