Uncategorized » Always Where

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.

boardbook hospital

Last night we had an episode of “Boardbook Hospital.” Honestly, I couldn’t come up with anything funny to say while working on a number of Matthew’s books. (I came up with a number of things that bombed, but really, book-repair is pretty spineless!)

Photo 56.jpg

We did have fun remembering the Muppet Show, though.

xmos / xc

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.

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.

hosts, backup

I’ve taken the plunge, and am giving a new hosting provider a try. Things will be moving over the summer.

This is a big jump; I’ve been hosting my own shiznit for years now. That said, I can do most of what I need with a shared hosting provider… so I’ll see if I can get by.

I went with DreamHost, and we’ll see what happens. The most important thing is that I am able to run duplicity to back things up to Amazon’s S3 service. So, even if things go bad, I can (at least) recover anything and everything I had on the shared host.

Now, to move all of my research pages from baseplate.org to rockalypse.org… I think it’s time to downsize a domain…

open your world

I’m a bit behind on a number of posts (as well as a few things in the Real World). I still need to post a few more pictures from the westward travel, for example. I came back and have been moving fast ever since getting students bootstrapped on summer research. I’ll have to point to their work in another post—I’m very excited about all of the projects they’re working on.

In the meantime, I can relate a bizarre experience I had while on my travels. While headed east, I was asked if I could give a talk as part of the opensource.com Open Your World forum. “That’s cool,” I thought, but I wasn’t about to cancel my travel. As it turns out, it was a webinar, and that meant I could “phone in” my talk.

Because I was traveling, I didn’t have time to give a presentation in my typical highly visual style. Instead, I had one content slide (an outline), which (given the travel) was about all I could put together. On the day of the talk series, I got up early (I was on mountain time), dialed in, and gave my talk. Personally, I thought it was a hoot, and was proud to have been included in the webinar series. Many thanks to John, Max, and the others at Red Hat who made it possible.

An overview post is up at opensource.com, and you can grab the audio from the series here. There were a number of great speakers, and I’m working on listening to the ones I missed.

glowing in the dark

This has been quite the drive. When we last left off, we were somewhere in Chicago, I think. Or somewhere West of Chicago. It doesn’t matter… we were somewhere on I90. It was a lot like I90 everywhere east of Chicago.

After Chicago, we drove across South Dakota. We saw sheep chutes.

After we saw sheep chutes, we saw Wall Drug. It’s a tourist trap, but by the time you get to western South Dakota, you don’t care. (Robin did — he was bitter about the whole exercise — but I insisted on a bumper sticker.)

While there, he made friends with a bison.

After that, it rained. And hailed. And in Rapid City, we saw every kind of weather warning you could get. Yes, tornados were flying around somewhere near us. We didn’t see one, but we were prepared to chase one if we saw it.

After we nearly died (we didn’t…), we went to Mount Rushmore. I tried to take a picture, but Robin got in the way.

Sadly, I ran out of film, and couldn’t take another. After reloading more digital film, I tried to take a nice picture of a statue at the monument. Robin was in the way again.

The guy’s name was Gutzon Borglum. That, clearly, was made up. I think his name was probably Jeff, and just changed his name to Gutzon because he wanted people to think he was cool. Clearly, it worked… he got a statue at a national monument.

Using the last of my digital film, I took this picture. I’m going to enter it into photo contests and win millions.

I have more pictures involving mountains, and my amazing climb to the awe-inspiring height of 12,750 feet. Those will have to be in another post, though, as I’m out of space on my blog. There are too few electronics left in the universe for me to write anything else at this time. That, and I’m going to have some breakfast.

PS. .dc., the discs are awesome. More on that in a later post.

roadtrips

Last week and this are all about road trips.

Last week, Carrie, Matthew, and I made our way out to Syracuse, Boston, NJ, DC, and home.

We started by attending Olin’s graduation, where we saw the Olin family from 2010 graduate:

Matthew made lots of friends, and is now well aquainted with the Olin “O.”

This week, Robin and I are driving to New Mexico. We swung through Minneapolis first. We saw northern Ohio.

We saw a cat.

And we saw all of I90 across southern Minnesota.

Don’t tell me I don’t have the most amazing vacations.

plumbing goes to hollywood…

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.

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.

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.