opensource » Always Where

lofi hardware, delivered

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.

from llvm to lnot: compilation back-to-front

As a member of the faculty, it is often hard to justify spending time learning new technologies. This, to me, is a rather ugly Catch-22: to learn a new technology, I must justify it either with a publication or a clear, immediate application to my classrooms. If you’re driving towards a clear, concrete deliverable, it really isn’t exploratory learning… it’s work, under pressure, with a deadline. That’s why I’m excited about a project I’m undertaking this semester with one of our seniors.

The student was looking for a 2-credit independent study (this is roughly a 1/2 course load). We brainstormed a great deal, and in the end, the student thought they’d like to dig into some more Scheme programming, so we decided a compiler might be a good way to focus our efforts. However, I didn’t expect that it would end up being a project with so much potential.

At Indiana, I saw how we can write compilers front-to-back in the nanopass style. However, several grad students in the languages group insisted the right way to write a compiler was back-to-front. What does this mean?

First, you take your assembly language, and generate an executable.

In our case, we will be working with LLVM Compiler Infrastructure project. Specifically, we’ll begin by writing programs in LLVM assembly, and using the LLVM toolchain to turn that into a native executable.

Although our input language is not C, we might imagine starting with a simple program in our language LNOT (L₀) that is nothing more than the number 8. A single expression. When compiled and executed, it should return the number 8. Expressed in C, this would look something like:

int main(int argc, char **argv) {
  int retval;
  /* Assign the result of our entire program to retval */
  /* In this case, the entire program is the constant 8. */
  retval = 8;
  printf("%d\n", retval);
}

The disassembled LLVM looks something like:

define i32 @main(i32 %argc, i8** nocapture %argv) nounwind {
entry:
  %0 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([4 x i8]* @.str, i64 0, i64 0), i32 8) nounwind ;  [#uses=0]
  ret i32 undef
}
 
declare i32 @printf(i8* nocapture, ...) nounwind

As we are writing the compiler “back-to-front,” we now need to take one step backwards towards our input language. Because we are working in Scheme, we’ll represent our language in S-expressions (to minimize parsing effort). The first pass (or, the last pass, in front-to-back thinking) will be one that transforms an S-expression based syntax for LLVM assembly into actual LLVM assembly. Therefore, the input language to the penultimate pass might look something like:

(define (main i32)
  (args [i32 argc]
        [(i8** nocapture) argv])
  (entry
   (tail-call (printf (i32 (i8* ...)) ...))
   (ret (i32 undef))))
 
(declare (printf (i32 (i8* ...) ...)))

This elides many things, but my point is that we might take the ASM of LLVM and “lift” it into a syntax that can be easily pattern-matched in Scheme and manipulated. As we work from the back-end of the compiler to the front, our next step might be something trivial: for example, we might get rid of the entry form, because (with a very simple input language), we know we will only ever have one function, and therefore we can generate this automatically. Or, we might be more aggressive, and acknowledge that we don’t need to generate any of the wrapper code… so, we should only need to develop a language for statements that will proceed and/or live on the right-hand side of the retval assignment statement.

For me, it is exciting on a number of levels. I get to learn with a student, which happens less often than one would like. I don’t know LLVM, and am glad to be spending time getting to know it. Also, I haven’t ever written a compiler back-to-front, and evaluating this (both technically and pedagogically) has value — I’ll probably be teaching our compilers course next spring. And, I get to do some hacking, which I simply don’t get much time to do.

When we have a repository up, I’ll post a link to it, although it won’t be an “open” project, per se. We’re not doing this to engage in a new compiler authoring project so much as learn, but if you want to, you can watch us as we work.

adventures in lo-fi open hardware

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.

Welcome POSSE SA!

Welcome graduates of POSSE SA!

Actually, South Africa is a big place; perhaps there will be more POSSEs there, in which case, we’ll have to call you Classic POSSE SA, or something like that. Mind you, you’ll always be special. But really, I digress. Already.

Take 2.

As you look to involve your students in the world of open source (and, indeed, as you explore it further yourself), use the tools you’ve been introduced to so we can stay in touch. Not so much because those who came before think we have all the answers, but because we’re hoping you can contribute to and improve the explorations we’re making already. And, for that matter, TOS can, we hope, serve as a space where we can support each-other as we try and engage in explorations that encourage our students to reach beyond their comfort zones as they begin exploring the world of decentralized collaboration under the aegis of free and open communities of practice.

So again, welcome!

computers and college

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

Don’t buy a new laptop. Buy a used one.
Install free software on it.
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.

free interaction design for your open source project

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

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…

OSCON is good

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

dinosaurs and uavs

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.

release early, release often

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

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.

cccboard in the wild

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:

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.

lofi hardware, delivered

from llvm to lnot: compilation back-to-front

adventures in lo-fi open hardware

Welcome POSSE SA!

computers and college

free interaction design for your open source project

HOW YOU CAN HELP

WHAT WE WILL DO FOR YOU

SOUND GOOD TO YOU?

OSCON is good

dinosaurs and uavs

release early, release often

cccboard in the wild

Pages

Archives

Admin

HOW YOU CAN HELP

WHAT WE WILL DO FOR YOU

SOUND GOOD TO YOU?

Pages

Tags

Archives

Admin