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.

This past year, I’ve been serving on a task force at my institution. Our charge is to investigate the intersection of technology and learning on campus, make recommendations regarding where we might focus our energy in the next five years, and (perhaps most importantly) recommend political structures that might then provide guidance and insight on an ongoing basis.

This post at CunchGear struck a chord. The author’s recommendations for new college students are (simplifying):

  1. Don’t buy a new laptop. Buy a used one.
  2. Install free software on it.
  3. If you want to play fancy games, use someone else’s fancy game machine.

Scott Merrill, the author, even addresses two major constituencies: engineering/computing-type students and liberal arts (literature, history, etc.) students:

  • [ COMPUTING ]
    No matter what you buy, you’ll probably have better facilities on campus. And networks are everywhere: remote into powerful machines.
  • [ LIBERAL ARTS ]
    You’re just typing papers and checking Facebook. You don’t need an expensive computer.

And do you know what? I think he’s right.

Sadly, institutions are slow to change. I would love to push for the following:

  • Install a free operating system on all public machines.
  • Offer a netbook/laptop programme that provides low-cost, robust laptops running open software. System76, for example, provides netbooks and laptops ready-to-go with Ubuntu. I’d love to have an EduBook to trial – my suspicion is that this little laptop would cut it for many students.
  • Establish a grassroots initiative to provide training and support for students. On my campus, we’re starting a learning/living community initiative, and I could see that new community structure playing a role in this way.

I might be able to go further in my recommendations, but that’s what comes to mind at the moment.

This re-statement/reflection on Scott’s piece was inspired by a post over at TeleRead. Chris at TeleRead closes with the following statement:

Perhaps the emphasis on college students having the latest and greatest technology should be reconsidered, at least from the perspective of giving them them the best ability to focus on the important thing—their education.

Now, making a bit of a 180º turn from what I was just saying, I’ll claim that this is a naive, sweeping statement that fails to take into account any of the realities or pressures I think many faculty feel in higher ed: students expect new media. Their world is made up of interaction and video, and we’re still giving them chalkboards. So when the sweeping claim is made that they should focus “on their education” (at the same time as you’re calling for new modes of interaction, collaboration, and problem solving), please consider what tools we’re currently working with, where the technology is headed, and how we might be leveraging that technology to improve our students’ learning experience. No one I know is considering technology for technology’s sake… but we’re pretty sure that there’s some really amazing learning we could be supporting… if we could just get the tools in the students’ hands.

The fact is, some of these devices do enable real-time, community-driven collaboration (many-to-many interactions) that simply were not possible a few years ago. Yes, I could photocopy a student’s paper and hand it out to everyone… but doing that with 20, 3-page papers means 60 x 60 pages (roughly 3600 pages). Using tools like iAnnotate allow students to comment on and mark up each-other’s papers instantly and digitally. And, perhaps more importantly, tools like that allow me to handle my digital workflow more easily. (I do not, at this time, own an iPad, but I’m reasonably confident that a lightweight tool designed for media creation, annotation, and consumption would be a boon on a day-to-day basis. Netbooks simply don’t cut it (for many reasons), and my 13″ MacBook is too big and has too short a battery to be practical.)

In my mind, we’re in a Catch-22 situation in higher ed: we can require our students buy tools that let them engage in distributed, real-time media creation and collaboration surrounding digital artifacts… but that implies that our pedagogic approach is going to change to support their purchase of those tools. Down that road lies a commitment to change when many think that we’re doing fine as it is. Or, we could adapt our pedagogy (which is fine as it is), but our students won’t have the tools to engage the way we want them to. How do you drive change in a system that is (at best) mildly elastic, but ultimately static and resistant to change?

I’m teaching a first-year seminar this year titled Creativity and Leadership. I’ll put the question to them. Perhaps they’ll come up with something.

During the summer of 2009, I had the good fortune of taking part in the Red Hat POSSE programme, meeting a bunch of excellent open source peeps, and getting a sense for how I might introduce more of my students to the world of open source contribution. This last spring, my colleague and I introduced 40 first-year students to the Fedora project. This semester, I’d like to introduce y’all to a few more.

This semester I will be leading eight intrepid students in an exploration of interface design and development at Allegheny College. Your open source project (or a small part of a larger project) could benefit greatly from these students, if you’re interested.

HOW YOU CAN HELP

I want developers/managers from “projects” that have a GUI. I say “projects” because you might be the lead on, say, a network settings dialog box that is part of Fedora. You need to be of the mindset that your GUI could always be better, but you never seem to have the time to sit down and do heuristic evaluations, sit users and do interaction testing, and so on. If we work with you, you also have to commit to being timely in responding to the students—most likely on your developer mailing lists—because we can’t wait for two weeks to go by in a 14-week semester while we’re waiting to hear back from you. (I’m not talking about 5-minute response times, but if you can’t reply to email from people trying to make your project better within 24-48 hours, please don’t respond.)

Basically, we ask that your community be reasonably responsive, and we’ll be doing all the work.

WHAT WE WILL DO FOR YOU

Macintosh Plus

Small teams of students will, throughout the semester, engage one or more of these projects as budding interface designers. They have no prior experience in this regard, but will be engaging material on lo-fi prototyping, usability, the psychology of interface design, and so on. We will be discussing this material (which we will try and do in as open a manner as possible) and directly applying what we learn to the interfaces that are part of your project.

The students will work within your community, using your tools (mailing lists, wikis, etc.). I do not expect them to implement their designs, although some of them may be capable of doing so, and they might even do it. This, however, will not be a requirement of the course. (Not everyone in the course is capable.) If their work is good, and you like what you see, we only ask that you give their efforts serious consideration for implementation… we’re working with you because we don’t want to be doing interface design and testing in the abstract, but instead we want to add value to real projects through our efforts.

SOUND GOOD TO YOU?

If it does, please drop me an email (mjadud at allegheny dot edu). If you’d like to talk to me on the phone, I’m happy to chat—92JADUDM92 is my Google Voice number, which… well, it’s new to me, so we’ll see what happens.

I don’t (yet) have the course website up, but it will probably live here when it goes live

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.

This semester, we’ve introduced 40 students to the Fedora project . By “introduced,” I mean they have been introduced as contributors.

I want to point out that for me as a member of the faculty this is 1. hard, 2. a massive leap of faith, and 3. very, very exciting.

And, it is all of those things for our students as well. They’re blogging over at act.ivism.org, and I’ve written an introductory piece about their project on opensource.com. If you want to check out what they’re writing (and leave them some encouraging notes on their blogs), that would be awesome.

Remember: these are first-year students in a Freshman Seminar who have not declared their course of study. Despite that, they’re diving into IRC, wikis, blogs, mailing lists, and sprints as they rapidly come up to speed on contributing to the Fedora project. I don’t think they have any idea just how big a jump this is for some people. And because they don’t know it’s a big jump, they’re just jumping.

Give em’ some props. (Or, leave the props here, and I’ll pass them on.)

One of our third-year students is giving a talk about two of his passions today: Tea and Twitter.

Pat Canella ’11 will present a talk titled “Twitter and Tea” at 4:30 p.m. on Wednesday, March 17 in Alden 101. The talk will focus on Canella’s own experience with the tea community, on Twitter and other “Web 2.0″ tools. Refreshments will be served. The talk is sponsored by the Association for Computing Machinery at Allegheny. All are welcome to attend.

What started as an exploration of an idea in our Junior Seminar became a talk that he’ll be delivering to a much wider audience. And rightfully so—Pat has been exploring tea through a number of media (Twitter, blogs, etc.), so this should be good.