Three years in, and I now have license to set up a lab.

At Allegheny, I have found there there is a great deal of opportunity for cross-disciplinary collaboration. I have colleagues I can have fun with in Art, Environmental Science, Biology, Physics, Psychology… perhaps even History, but I’m really only including them in the list in case one of them wanders by and feels left out. ;) Being able to make things move or collect data over time is a powerful thing, and I’m planning on making sure we can do more of that in my lab.

Of course, I would like to maximize the ability to fabricate while minimizing cost.

2D Lo-Fidelity Prototyping and Building

To start, I’d like to be able to do two things. I want to be able to cut new aircraft repeatably, and I’d like to have a low cost, workable material for exploring small scale robotics construction. My inclination, at this point, is to purchase a CNC foam cutter.

The Phlatprinter 3 would allow us to cut multiple copies of the Flying Gator easily, which would be excellent. Given my conversations with colleagues in Environmental Science, I think it would be useful to be able to build larger aircraft as well — for example, something that could be deployed for aerial photography in a coastal setting with gusting winds. This implies a much larger aircraft, and frankly, I don’t want to be cutting out wing spars for the rest of my life.

The Phlatprinter would also make it easy to cut robotics platforms out of foam (allowing students to design and build their own small robotics platforms), as well as provide (perhaps?) a robust enough skeleton for doing plushie robotics.

Twitchie Scorpion from MAKE magazine on Vimeo.

A Phlatprinter would run me roughly $1200 plus shipping.

2D Routing

A router would allow manufacture using beefier materials, but they’re big, and they’re more expensive. The blacktoe comes in either 2′ x 4′ or 4′ x 8′ sizes, for $2300 or $2900.

Given the prices, it is obvious that a 4′ x 8′ table is the way to go… but, I have precious little floor space. And, in truth, I need to think more about what role a router would play. It may be that a 12″ x 36″ table would be more than adequate for what I want to do (which mostly would be enclosures and small components for sensors and robotics platforms).

A router has many applications for small scale robotics as well as more artistic endeavors. The buildyourcnc website has some pretty pictures of the kinds of work people have done using these tools. I’d love to have access to these, as well as be able to make them available to students here at Allegheny.

PCB Milling

The MTM Snap was just announced, and obviously, that’s the machine I need.

While I could outsource PCB manufacture, the reality is that I typically need small, single-sided boards, and in quantities of 1-10. I could outsource (and perhaps I should), but I prefer not to outsource board production when I haven’t even had a chance to build and test. At roughly $700, I’m talking about 14 PCB runs at $50/each. If, for example, we were to decide that Environmental Sensing and Robotics might make an interesting course (or, perhaps, something more artistic, like Animatronics 101), then allowing students to cut and assemble a small board from scratch using tools like this would be an incredible experience unlike any they could find at any other small liberal arts college. (I may be wrong on that count, and if I am, someone tell me.)

Basically, I think I need a PCB mill. I could be wrong.

Misc Equipment

I’m hoping I can save in this space, and get high utility, low cost tools that allow my students to do basic electronics work without breaking the bank.

Power supplies, scopes, multimeters… these are all tools that you need to get on with building things and making sure you’re doing the right thing. I’m going to do some digging to see what we have on campus that I might use before I go shopping.

What Else?

What else do I need for a small scale electronics and robotics lab? Components, I suppose. Pieces-parts. Sensors. Motors. Stuff to build with. That may have to come with time. For the moment, I’m wondering what large pieces should be brought into play, and when. Is a dedicated machine for CNC foam work worthwhile? Can I use it in the ways that I think I want to use it? Would a single router be better? What tools would be valuable that I don’t have here already? (I have a Makerbot, but haven’t been able to set it up…) What, in short, would be the ideal set of tools for a small lab capable of supporting the exploration of environmental sensing and robotics?

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.

I work on a software project that helps make an interesting, parallel language with a long history run on lots of tiny computers. More details can be found online.

Specifically, we run code that used to run on a processor called the Transputer. It was developed by a company called INMOS. Today, there is a company called XMOS, and it has some of the same people involved who used to be involved in INMOS. However, the world is a different place today, and I think XMOS is the right idea at the right time for a lot of very interesting applications.

In this forum post, one of the XMOS peeps a member of the XMOS community was wondering aloud about the state of their language, XC the native language of the XCore line, XC. They have realized at XMOS that more people now use their tools externally than internally. (This is a very good thing… users kinda matter.) So, a few questions were asked. I quote:

1) Releasing the current roadmap for XC – showing bugs, features and plans for future development with some timescales. This will enable developers – customers – to feedback on what is important to them and also plan for future improvements to the language. In particular, any plans for typed channels or protocols, process mobility, relocatable, dynamically-loaded code and modules (a reserved word), are very important to members of this community, as recent discussions have shown.

2) Releasing the current implementation of XC – the compiler and tools – so that the community can develop, improve, and learn from the implementation and the language, as well as be equally invested in its future.

Regarding number one: a language will not survive without community. And, while a community will invest in what it cannot control (eg. Twitter), this is a different kind of community. For XC to grow and be useful as a language, the users must have input. This does not mean that language design decisions should be made by people who have no idea how to design languages—but, that said, the people who use the language know what would, and would not, be useful to them.

Regarding number two: there is no doubt that the compiler should be open source. It is one thing to invest in a hardware platform that is closed: we do that every day. But I do not want to build software with tools that might be taken away from me at any time, or modified in ways that destroy my business. If I buy an XS1-L1, I want to know that code written with compiler version 1.3.2 will be able to be built and compiled for the rest of time. I want the option of never updating the compiler, if I need to.

But, more importantly, an open compiler framework would make it much easier to port occam-pi to the XMOS platform. Again, though… I have no desire to do work on a platform that is locked away from me. If XMOS were to move their compiler into a git repository, I could check it out, explore, and contribute.

There is no universe in which opening the compiler can damage XMOS. If their language is ported to another hardware platform, it means more people using XC—meaning, more potential users of their hardware. If new languages are ported to the XC, it means more potential users of their hardware. If someone decides XC is ugly, and designs a new front-end that is friendlier and more expressive, it means more potential users of their hardware. Have I made my point?

Compilers should be open. Period.

Updated 20100623: See comments for reason.

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.)

For years, my colleagues and I have been working on lightweight runtimes for parallel languages. To put our work in context, we’ve often targeted small robotics platforms like the LEGO Mindstorms for demonstrating the power of a parallel-safe language for real-time systems. This summer, we realized that the Arduino was a marvelous, open-source platform with an energetic community of developers and users, so we ported our language and tools to the Atmega328.

We have a Mac environment done, are working on Windows, and will have a Linux release by January. This, however, is quite exciting:

concurrencycc-prototype0.JPG

Omer (Vimeo, Twitter), a PhD student at the University of Kent and our resident hardware guru, did a modified Arduino design that includes more LEDs (along with a few other nice changes, like a mini-USB connector and a lower-profile power jack that will easily work with LiPoly batteries). The extra LEDs are important, because we wanted a board that made it easy to demonstrate the power of a parallel runtime right from the start without any additional/external components.

I’m especially excited about being able to buy these in bulk and sell them to students at cost for use in classes. Next semester, students in Programming Languages as well as my second-semester first-year seminar titled “Technology and Activism” will build and program their own computers. It will be awesome.

We currently have placeholder material up at concurrency.cc, but soon we’ll have binaries of all of the tools and documentation up that let you start writing parallel programs for your Arduino!