c.cc

NEVER GIVE UP

The life of faculty is a busy one; keeping up with hacking code is hard when you’re busy teaching others how to hack code, and constantly working on projects that provide them with authentic learning opportunities. C’est la vie.

That said, a few people have contacted me recently about the occam-pi tools for the Arduino. Well, to be honest, “a few” means “a couple,” which really means two. One is someone I do not know personally (from Spain), and the second is someone I know because they discovered the tools some time ago, and wanted those tools to work again.

Unfortunately, the KRoC build is tricky… there’s no one command that “just builds” everything for the Arduino. (That’s a Joel Test failure: can you build and deploy in one step? Nope…) So, two years ago, I had experimented with hosting the compiler. I wrote a really complex server, and it worked poorly. There was a port leak, I think.

This past weekend, I rewrote the server, giving it just one endpoint (instead of 6), and simplified the whole process. I wrote a new command-line driver that used this protocol. At this point, I had a 6-hour hack that “worked.” I then scriped a few thousand runs, and watched RAM and resource useage: everything stayed stable. Win.

The next day, I decided we still needed a GUI. I had written one two years ago, but I was afraid of the bitrot. As it happens, I had written in (during my overzealous over-complication of the code) enough abstraction layers that my configuration and ‘net access was all abstracted away. So, a few changes to accommodate the differences in the new backend, and the IDE worked. As we say at Berea: HUZZAH.

At that point, I assumed the build process would “just work,” because it just invoked some compilers and bundling tools. And… it did. I even had the VM laying around that was used for the Windows build. (Hooray for large hard drives.) I did a “git pull,” and ran the build scripts. A few small tweaks were called for, but within the hour, I had both a Mac and Windows distributable build. (Perhaps it was three hours… there were path issues on Windows.)

That’s the long way to say that we have new, working versions of the Plumb IDE for occam. It only targets FTDI-based m328p devices (old-school Arduinos) and the Uno-family of devices (Uno, Motino, etc.). I will be testing 3.3V devices later today. I will work on 32u4-based devices later.

For now, though, we have an occam environment for the Arduino again. If you pick it up and have questions, drop a note to the users@concurrency.cc mailing list, or to me personally if you get bounced from there… we have some aggressive filtering because of SPAM.

For your pleasure, you can visit the Downloads section and grab the most recent version of the Windows or Mac build. Linux (in the form of a Dockerized goodness) will be coming soon.

The image below hung for years in my father’s machine shop, clearly a photocopy even then. It remains true: never give up.

What's To Be Done

At this point, we have one active committer on the occam/Arduino project. Everyone else is, I suspect, busy.

I made a big push at the start of the summer, and summer research with students (and now, the school year) eat my time. Two children also keep me busy.

The question has come in via Twitter: how long until we have support for the Mega?

We had good support for the Mega1280, and used it in an aerial robotics project. As far as I can tell, it should run on the 2560 as well. That said, the bootloader bugs on the 2560 have plagued me for years; patches and requests for fixes have made no difference, and I’ve given up.

So, there are some steps we can take:

1. We need to combine the TVM and the bytecode in one file, so that every time you write an occam program, the entire VM is re-uploaded along with the new bytecode. This will work around the problems with the bootloader. So, step one is to modify the process by which we build code for the 2560.

2. After that, we need to make sure the occam libraries are working on the 2560. They should, but that will require testing.

That’s about it, really.

Currently, things work this way:

1. A web service runs on an Amazon VM. The IDE squirts native code at it, the web service compiles the code, and compiled code for the Arduino comes back.

2. After the round-trip over the ‘net, the compiled code for the Arduino is squirted onto the board.

All of this code is open and in a repository.

I’ve spent some time trying to get the Mega working (this past summer). I don’t know what the problem was, but I ran into problems; I was able to execute occam programs, but had a hard time successfully accessing registers and, you know, blinking an LED. (With full debugging enabled, I found that I was able to execute bytecode… but something is wrong with the hardware access.)

So, we’re at a point where, frankly, I either need to free up time, or more people need to be willing to hack on things.

1. The VM is currently… unprotected. I really need someone to help set up a VM that is jailed so that the server can run a compiler on arbitrary code without compromising the machine (in the case of malicious intent).

2. The web service is currently written in PLT Racket. It could be written in Python, to make it more accessible to more hackers. I’m fine with this; I didn’t do it in the first place because 1) I know Scheme well, and 2) I knew it would Just Work. However, if we want to turn this into a Cherry Py app (or similar), I’m fine with that. But, that’s work.

3. The compiler driver is fine, but we need another script that mashes a compiled VM together with the bytecode, padded so the bytecode always starts at the same place in the IHEX file that AVRDUDE uploads to the Arduino. This is easy, and I suspect I’ve already written it. I don’t think it is currently plugged into the server, however.

4. The IDE is fine, mostly, but it needs some cleanup and improvement. It is written in PLT Racket, because it is one of the few languages that I know of that will let me write a GUI application that will Just Work on all major operating systems without compromise. I’d consider moving to an extension for Editra (a pure-Python environment) or Gedit (also scriptable in Python) if people were willing and able to help drive the effort.

In short, there is work to be done, and it is detailed work. I’ll get there (maybe)… because I, too, have 2560 boards that I would love to be able to use. That said, I also have ARM boards I’d love to be able to use, and would like to spend time on a Raspberry Pi environment, and perhaps the Parallella, and … you get the picture. There’s more work than I can do on my own, and for the moment, I have a lot of responsibilities just being a professor at a small college with small children. This work, sadly, is not able to occupy my time front-and-center.

That’s the story. The answer to “when will the 2560 be supported?” is probably “sometime next summer.” That’s realistic. Anytime sooner will surprise me as well as you.

Release Early, Release Often

Many people have spent many years keeping occam alive on many platforms. I want it to be easy to use on the Arduino.

I’ve been working hard for a few months now to get all the pieces in place.

• A compiler in the cloud. To simplify things, I stuck the compiler on a server.
• A website refresh. I really want to focus on documentation and libraries to support users doing cool stuff.
• A new IDE. I wanted something to get users moving quickly.

And, I’ve ordered a mess of Arduinos. An Uno, a Leonardo, a Due, and a Mega 2560 are all on their way. (In truth, the Uno, Leo, and Mega are the only boards that will be supported in the immediate future.)

Documentation will improve quickly as well. I’d especially appreciate it if people join the mailing list and provide me with some direction—what do you want? I’ll probably be doing some work that supports our summer research on home health sensing first, but we’ll see where we go from there.

Website Refresh, Plumb

First, the website picked up a big refresh today. That’s a win. It will take time to make sure everything is ticking over nicely, but I’m looking forward to the process; we were still learning Jekyll with the last rev, and it’s a bit more straight-forward now.

More importantly, we have some new tools, and those, too, will be easier to improve and manage over the coming weeks and months.

Plumb

Plumb makes it easy to get occam-pi code running on your Arduino on your Mac or Windows.

Basics

You must plug your Arduino in before starting Plumb. Choose the code you want to send to your Arduino, and then hit “Run.”

Loading Examples

If you want to see some instructional/educational example code, use the “Examples” menu.

Edit and Run the Examples

The example code can be edited and run directly from within Plumb. Keep in mind, this is not a programming environment; if you want to save your work, you’ll need to copy-paste and do your programming somewhere else.

Semester Coming to an End

This semester has been full of headaches and annoyances, but after much head banging and hard work we were able to accomplish minor goals. Although we didn’t accomplish everything we had wanted to, we feel that the progress we made was significant for the time we had. We took pre exsisting python code, rewrote it into ruby follwing OOD, organized it, heavily commented it, as well as fixed the fishtailing issue that taking place with the old code.

With the progress we made obtaining level flight without the dolphin kicks that were previously present, the next step of GPS waypoints is obtainable and the code can be transfered safely to occam-pi and placed on a physical device. We feel that these are the next logical steps for the project.

Goals

We have a week left of class, and we would like to try and tie in our heading into our pitch so it can turn as well as change altitude at the same time. If we can accomplish this, the plane will behave as a “real” plane flies. We are unsure if we can accomplish these goals with such a short period of time, but its worth a try.

Did You know?

There is now a robot, called the HyTAQ hybrid that can travel by air and land! Its pretty cool.

Please look here to see the video and article.

http://www.engadget.com/2012/11/28/hytaq-hybrid-quadrotor-robot-travels-by-air-and-land/