A few weeks back, I wrote about my attempt to translate a low-fidelity circuit board design into something that could be run through a laser cutter. Today, Ponoko delivered the results:

You can click through to a large, high resolution image. In a word, it came out beautifully.

I do work surrounding the use of parallel languages in embedded applications. This summer, along with two students, we began work on a novel control system for an unmanned aircraft (a UAV), and managed to achieve autonomous level flight. Last term, Rich Bowden (Environmental Science) asked me if we could do a sensing project in Environmental Research Methods. During the break, I developed a board, built some prototypes, and wrote the control control code. I’m now developing the documentation (video coming soon!) for students, so they can assemble circuits and deploy their sensors to collect data. It’s exactly the kind of cross-disciplinary opportunity that we want to create. (Next time, we’ll get CS students involved early, and they can help develop the control code, and possibly even the board design.)

Sadly, we won’t be using these laser cut boards for this project; instead, the students will be poking holes in manila folders, and it should go well enough. Why not? First, the lead time was several weeks – it takes too long to send out for the boards to use in any “impromptu” manner in a classroom or research setting. Second, Ponoko charged me $21 for that board.

How is this a $21 piece of cardboard? The laser time cost $2/minute, and this design took just over 5 minutes to engrave and cut. The shipping was a flat rate of around $8. And, the cardboard… $0.41. It was worth it for a prototype, because I know that a laser cutter will meet real needs, and have high utility in multiple educational and outreach contexts.

I have students prototyping sensors as part of their senior projects, building robots as independent studies, core research that involves prototyping and construction, and I’d love to be doing more tangible, computational work across disciplines (eg. with colleagues in Art, Environmental Science, and so on). I’d go broke trying to do this via a service like Ponoko, and the turn-around (for prototyping and exploration) would kill me. Waiting three weeks for a design to come back means that, if you’re lucky, you can do two design iterations (maybe three) in a semester.

Hence, we’re going to try and get a laser cutter. $20,000 is my round-numbers target for a laser with a 2′ by 4′ bed. At the rates Ponoko is charging, it will pay for itself after 10,000 minutes of usage. We have excellent connections into the community (schools, etc.), and I think it will be easy to run this printer for all kinds of awesome projects that let teachers and students at the College and from area schools come together to explore the intersection of computer science and manufacturing.

I want computing to be tangible and accessible. By “tangible,” I mean I want students to be able to see, as much as possible, how a computational artifact comes together and/or interacts with the world. By “accessible,” I mean I want students who don’t consider themselves “computer people” to have opportunities for positive and meaningful interactions with programming and/or other computational technologies.

Just before break, a colleague asked me if we how hard it would be to develop a sensor that students studying Environmental Science could use to monitor light and temperature levels around a building, both on a fixed schedule and when motion was detected. (The answer: it takes 120+ hours of research, design, development, and testing.) Last year, first-year students build a cardboard computer — an Arduino glued to cardboard instead of soldered to a PCB. Building on that idea, I developed a sensor that would achieve the stated goals while also allowing for all of the major components (processor, sensors) without difficulty. The original board design looked like this:

The board design was done in OmniGraffle. The gray areas are velcro (for attaching the board to the enclosure), the gold areas are copper tape (making it easy to bring several ground wires together, for example), and the rest are wires that students would solder between various connectors. They would print the board, glue it to a manila folder, cut it out, punch holes, and start gluing headers to the board; I expect the total assembly time to be between 3 to 4 hours.

Now, the substrate leaves something to be desired: it is floppy and a bit annoying to work with. Further, it is tedious to punch holes through the board for every header connection. And while I like the fact that there is a certain amount of craft involved, I’d like to cut some of it down. So, I went looking to Ponoko, to see if I could laser cut the board.

I hadn’t used Inkscape before, but it wasn’t too difficult to get the hang of. The color blue indicates a cut through the material, gray indicates raster surface engraving, and green indicates vector engraving. (Letters are vector engraved.) Now, here’s the kicker. The material (cardboard) cost $0.41 for a 7″ x 7″ piece. This is fine. The laser work costs $2/minute, and my design will apparently take a little over five minutes to engrave and cut, meaning the laser work costs around $11. Handling is about $5, and shipping around $4, meaning the total cost for a Ponoko laser-cut board is $18 in cheap cardboard. Yes, that is more expensive than designing a PCB and having it produced and shipped in quantities of 10.

All of that said, I wanted to see it would come out, so I went ahead and ordered one. The reason? I want a laser cutter. A laser cutter is an incredible tool for crossing disciplinary boundaries. I can have students engraving parametric equations from their multivariate calc class onto balsa surfaces, capturing (cheaply, but robustly) the most beautiful 2D and 3D equations they can design. Or, we can explore paper cutting, or using more robust (cardstock), have students in Theatre doing scene design just like the pros. There are no end to the applications in Art. It would be a powerful tool for grounding outreach into the community (making laser cutting available to area middle- and high-school teachers and students), as well as a centerpiece for a new hacker/makespace. And, for me, I can be working with students on small-scale robotics using some of the tools that make bespoke and custom robotic work possible.

If I had my own laser cutter, this would have cost $0.41. And, in the end, getting a prototype in-hand is worth $18. But the real power from tools like this comes from having them readily available to make new collaborations and innovations possible.

What: Parallel Programming on the Arduino

When: Friday, December 10, 19:00 – 21:00 GMT-5

Where: Hack Pittsburgh

On December 10, I’ll be heading down to Pittsburgh for my first ever visit to Hack Pittsburgh! Now, you could claim that my lack of visits is because I’m a bad maker, or you could just accept that faculty are busy people, and having a toddler multiplies that effect.

But the making must happen! In this particular case, the making will be more along the lines of programming. I’ll introduce the basics of the programming language occam, a parallel programming language that has been around for roughly 30 years. Along with colleagues at the University of Copenhagen (Denmark), University of Dundee (Scotland), and University of Kent (England), we’ve made it possible to write occam programs for the Arduino, and have gone a step further in developing Plumbing, a library that simplifies many common tasks on the Arduino. We also have the start of a book on the subject which (hopefully) will get refreshed over Turkey Break.

If you’re looking to attend, you should do the following:

  1. Bring an Arduino.
    I have a few I can lend, but you should bring your own.

  2. Download and install our software.
    We have a free and open source environment for you to use when writing occam programs for the Arduino. It runs on Mac, Windows, and Linux.

  3. Grab the book.
    We have a CC-licensed book you should grab. You don’t have to print it (save the trees!), but you might want to have it on hand. So you know: I expect to update this over Turkey Break, so watch the Twitter feed (or the c.cc blog) for notice when that happens!

  4. Subscribe to our Twitter feed.
    We’re @concurrencycc on Twitter.

I’ll assume you don’t have any particular programming experience, unless the crowd who shows up happens to be a bunch of expert embedded systems developers, in which case we’ll adapt. If you have any questions, or anything you’d like to try and do in particular, drop an email to matt @ concurrency.cc, or (better yet!) join our users mailing list and drop your ideas there.

I’m also hoping to bring some students down as well, so it should be a good time.

I’ll have to write a longer post later, but I thought I’d just mention that OSCON is a great conference. Our presentation went well, and we’ve had a lot of great conversations with people about all kinds of things in the open source world.

More later… for now, it’s time to head out the door.

(Related, our parallel programming environment for the Arduino is now available on Ubuntu, Windows, and Mac. Hooray for packaging! And, I need someone to help me work through how to do proper source packages for some of the complexities I’m facing on the Fedora/Ubuntu side. Packaging compilers is not a lot of fun…)

This past week, Radu and Drew worked through the details of setting up PWM-based servo control on the Arduino. This gives us robust control over servos from our occam-pi based programming environment without having to interrupt our execution every 20ms to update a servo.

Here, the Science Dinosaur demonstrates how things work.


Radu and Drew’s work is “foundational,” in that it lays foundations for other projects. (We’re excited about moving on to some more interesting explorations shortly.) The servo control is absolutely necessary for another summer project we have going: the <a href=”http://rockalypse.org/blogs/flyinggator/”>Flying Gator UAV</a>. This flying robot (an “unmanned aerial vehicle”) is being custom built by Ian, and Ian and Anthony are developing the control system in occam-pi on the ArduPilot Mega. This combination gives us a lot of real-time safety, which we hope translates to “no surprises” when we are actually executing our code on a functioning UAV.

The nice thing about the ArduPilot is that is has a built-in hardware override, so that even if your code goes wrong, you can take control over your aircraft with a radio.

Here, you can see Ian taking the fuselage (that means “body” in airplane-speak) out for a test spin. Our aircraft is incredibly overpowered, it turns out.


You can follow an aggregation of all the students’ work at planet.rockalypse.org.

Last summer, I had the good fortune of taking part in Red Hat’s 2009 POSSE. It was an absolutely excellent experience, and many of the things we did and talked about have required much reflection and continued conversation for the ideas to take root. It also took some hutzpah: along with a colleague (and super-ninja support from Mel), we dove off a cliff this past term along with 40 of our students, introducing them to the Fedora project as seen through the eyes of the Marketing and Design teams.

I thought I would share a highlight from the day, though, that goes back to when Christian and I were at RH last summer. We shared with the group work we had been doing on making parallel programming more approachable. Specifically, we had recently completed a port of our virtual machine to the Arduino, thus bringing the venerable language occam to this popular embedded platform. (If you don’t know what an Arduino is, please… crawl out from underneath your IBM Model M keyboard, go to SparkFun or NKC Electronics, and buy one.)

ArduinoNG.jpg
An Arduino in its native habitat.

We thought our tools needed more work before we released. Our POSSE mentors were floored that we hadn’t released already! We realized that “release early, release often” really does mean getting your software out before it is fully baked. In our case, we were worried that the 70+ pages of book (incomplete) and only having installer support for one platform (Mac) wasn’t far enough along… this, apparently, is around version 3.8-RC2 for most projects.

Or, not. But their point was made. So, we released. I put the tools into use in my classroom (things worked just fine), and we decided we’d just keep pushing and promoting. As a result, we will be presenting at OSCON later this summer (very exciting), and we have two contributors from the world at large who are exploring the use of our tools in their own projects. We’ve created a “community” space in our repository and given them commit access, as well as a branch (in one case) so they can add new low-level features without worrying about leaving trunk in a broken state.

More than anything else, having the new contributors is what makes it fun. People poking at what we’ve done, asking questions, and trying new things… that’s a blast. Today, we got picked up by Slashdot, and my sincere hope is that we’ll pick up a few more explorers before the week is out.

If anyone is interested, I now have a (very gross) binary Debian package that you can explore — join the users mailing list and inquire if you want to try it out. We’ll get our IDE for Windows done soon, and put the polish on the site as we head off to share the fruits of our efforts at OSCON.

So, remember: radical transparency and release early, release often.

Or, at least, OSCON. I think I’m supposed to put one of these somewhere… for now, I’ll put it on my blag. We’re talking about parallel programming on the Arduino. Tray shwet.

OSCON 2010

The semester is over, grades are in, and now I hit the road for points east: Syracuse, Boston, DC, and then home again. After that, road-trip to Albuquerque, NM. No, don’t ask.

Then, it’s a flight home, and we dig into research. Very, very exciting.

The concurrency.cc board (cccboard) was photographed in the wild being its own bad self. Some of the Kent crew made their way to a meetup in London of the OSHUG, the Open Source Hardware Group, hosted by Osmosoft. psd shot this picture:

20100501-cccboard.png.png

Yes, Omer’s step-up circuit lets our Atmega328-based board run off a single AA battery. Very, very nice. I have six boards, but no bits and bobs. That must be remedied!

This summer, we have students working on ARM ports (the Fluke) and an autonomous aircraft based on the Arduino. This is, as we like to say in the group, Very, Very Exciting.


The concurrency.cc logo

I am excited to announce the release of Plumbing, software and documentation to support artists and makers in the programming of low-cost, open-hardware
platforms like the Arduino. The Plumbing libraries are a collection of parallel components written in occam-pi , a small language with a long history.

Last summer, we decided that it was time to bring six years of work regarding runtimes for parallel languages to the Arduino, a popular open platform for exploring the of art, electronics, and computing. In doing so, we decided that documentation would be critical in this effort. Documentation became a focus because we decided as a team that users matter. In designing and documenting Plumbing, we kept our focus on the students, artists, and makers who might do something amazing with our tools.

I think we’ve taken some substantial risks. Many people have contributed many thousands of hours of development time in our software (to say nothing of the years invested in occam-pi), and we will soon be releasing hardware as part of this effort as well. For me, the most substantial is the commitment to publishing our book, Plumbing for the Arduino, under a Creative Commons BY-SA license. That means that anyone can modify, distribute, and sell our work, as long as you give us credit.

Giving our book away is substantial because publishing is part of how academics are evaluated and keep their jobs. By giving away our book, we must now convince our respective institutions that publishing under the Creative Commons will force us to produce a better product (on an ongoing basis) than editorial review would, as well as reach more readers than if we found a publisher (who would then claim copyright over our creation). Or, we must find a publisher who is interested in helping develop and market our text while allowing it to continue to be available under a free and open license. (If you know one, please have them drop me a note to me at matt at concurrency dot cc.)

concurrency.cc and the materials made available from that site have been in development for years. I’m glad to finally see everything settling in place so people can easily download and explore the tools we have spent so many years working on. If you do, let me know how things go. (We’ll have mailing lists up soon, I promise… but for now my job as a professor calls, and it’s going to be a busy few days…)

Thanks to Dave Humphrey, GDK, and the rest of the POSSE crew. For months the encouragement to just release! has been kicking around my head. That message helped keep us on track as we reworked build systems, wrote text, built websites, and generally did all that stuff that no one thinks about when bringing a project together.

And we’ll get a Fedora RPM done as soon as we can. (In the meantime, you can build from source like the rest of us.)

In the preface to The Art of Computer Programming (1969), Knuth wrote the following:

100103-knuth-preface.png

I would posit that the vast majority of students who complete an introduction to Computer Science (often heavily focused on introducing the practice of programming) would not say that they felt they had been exposed to an aesthetic experience much like composing poetry or music.

This next term, I hope to work on developing a new course at Allegheny titled (tentatively) Digital Creativity. This course could serve as a pre-intro to the major, or introduce non-majors to the beauty of programming and computing, providing a collaborative, cross-disciplinary, and creative grounding in computational thinking using tangible, physical artifacts that students can relate to directly.