Category Archives: Community/Partners

Building high altitude balloons and hacking video cameras

by .
4 Comments

Image by blackrazorus vis Flickr

In my last post, I proposed a partnership between Adler Planetarium, Dayton Diode, and Mach 30 to build and launch open source high altitude balloons in Dayton, OH.  I am happy to report the project has a “go”.  We have two volunteers from Dayton Diode who want to work on the project, and Ken at Adler Planetarium received “enthusiastic approval” for the Dayton Diode/Mach 30 crew to participate in Adler’s December launch.  Ken is also beginning to recruit volunteers in Adler’s Far Horizons project to gather and assemble documentation for posting on Open Design Engine.  I will continue to post updates on the project as they become available.

Our friends at Adler Planetarium also asked us for some technical assistance on another project, and I wanted to pass on their request.  Ken is working through the development of a project dealing with asteroid occultations and is trying to figure out if there’s a way to hack an off-the-shelf video camera to be able to capture 60fps video and record that video with lossless compression.  Ken is familiar with using CHDK to hack digital still cameras, but neither of us have any experience modifying video cameras.

This is where you come in…

Do you or someone you know have experience modifying digital video cameras?  We want to hear from you.  Leave a comment or send us a message.

ad astra per civitatem

Attending the hackerSPACE Workshop

by .
1 Comment

This weekend Josh (a member of Dayton Diode) and I had the great pleasure to attend Kentucky Space‘s hackerSPACE Workshop.  The hackerSPACE workshop, led by Bob Twiggs co-creator of the CubeSat standard, was an introduction to CubeSats for hackerspaces, entrepreneurs, and educators.  In addition to the formal presentations, there were a number of group suggested breakout sessions including ones on educational outreach, open source CubeSats (of course, I suggested this topic), working with Amateur Radio operators, and operating high altitude balloons.  I am very happy to report the open source CubeSat topic generated quite a bit of additional conversation and opened the door to several partnership opportunities.

One such opportunity involves designing, building, and operating high altitude balloons.  During Mach 30’s strategic planning for 2011, the Mach 30 board decided to start its CubeSat development efforts by first building high altitude balloons.  High altitude balloons offer many of the same design, fabrication, and operation challenges as CubeSats, at a fraction of the cost, making them ideal “kites“.  And, it turns out, there are several high altitude balloon programs near Ohio to partner with, as we learned from the high altitude balloon breakout session at the workshop.  These programs include:

It turns out Josh and I sat next to Adler Planetarium’s Ken Walczak.  Ken and I talked at length about the Far Horizons program and launching high altitude balloons.  It turns out Adler Planetarium has been looking for a way to share the designs and procedures for their high altitude balloons in support of their educational mission.  It just so happens, Mach 30 has a website for sharing open source hardware projects, and as mentioned earlier, a desire to build its own high altitude balloons.  There has also been talk at Dayton Diode about building a high altitude balloon as a group project just because it would be cool.

Sounds like a great partnership opportunity to me.  Here’s how I see it working.  Mach 30 would provide project coordination, funding, and hosting (on Open Design Engine).  Dayton Diode members who are interested in a high altitude balloon project would volunteer their time to build and operate the balloon.  And Adler Planetarium would provide the experience (in the form of plans, procedures, and training).  Ken from Adler has already expressed an interest in this proposal, and believes he can arrange for a live training opportunity for Dayton Diode members at one of the upcoming Far Horizons launches (the next one is in December).  And Mach 30 has funds allocated for a high altitude balloon project.  And, I am cross-posting this blog post on Dayton Diode’s blog to gauge their interest.  More details to follow as things move forward.

What about ITAR?

by .
3 Comments
Restricted Area

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

Ask a silly question…

by .
4 Comments

Well, I’m back at ISPCS again, one of my favorite conferences about spaceflight.  And this year I am joined by Greg Moran, Mach 30’s vice president.  One of the first day’s panels concerned intellectual property as business assets.  Just as the panel was about to start, Greg asked me if I was going to ask the panel a question about open source hardware.  My response was “of course not, I learned a long ago bringing up open source in large sessions like this doesn’t work.”  Well, this panel showed me I hadn’t learned that lesson as well as I thought.  😉

The first panelist was from the Patent and Trademark Office and she presented a number of changes which are in the works concerning how patents and patent applications work.  Given that our mission involves open sourcing our designs instead of patenting them, her material did not really concern Mach 30.  The second speaker was the CEO of a computer peripheral company which derives a great deal of its income from its patent portfolio, so much so that he described his business as an intellectual property business instead of a hardware business.  At some point he went as far as to suggest the new space companies should consider a similar model.  Well, that was the proverbial straw for me, so I posted the following (somewhat snarky tweet) to vent my frustration over his message.

http://twitter.com/#!/Mach_30/status/126779828094513152

Now, I knew in the back of my mind that the ISPCS staff were going to draw some audience questions from tweets tagged with “#ISPCS“, but that hadn’t happened yet, so I figured nothing else would come of it.  Imagine my surprise when one of the first questions was preceded with the caveat that it came from twitter, and then heard my tweet read out loud, followed by the sound of crickets.  No one on the stage understood what the question was even asking, so I raised my hand, claimed ownership of the question, and elaborated on it.  So, how did the panelists respond?  I think the twitterverse said it best.

http://twitter.com/#!/Marimikel/status/126783090721964032

Ouch! Well, the second panelist did say something about liking his monopolies. But wait, there’s more.

http://twitter.com/#!/ad_astra2/status/126783332691349504

Maybe we need to do some outreach on the benefits software companies large and small have gotten from open source software?

And do you want to know the best part? Greg and I got several “oh that was you” comments when we introduced ourselves at dinner and the reception afterwards. Let’s hear it for stirring the pot.