Sub Ubi

“To find things and play on it.”

Via robogeek.

http://www.youtube.com/watch?v=_RyodnisVvU

Awesome. A funky little rhythm bot.

I just wanted to say that Roborealm looks like a very nicely done set of tools for exploring robotics and vision. I haven’t had a chance to play with it yet, but it is something I’d like to do.

The team is nearing completion of a new firmware for the SRV-1 that provides low-level, low-latency parallelism on the Blackfin-based Surveyor. Some excellent work has been done by Carl and Jon on this port, and I’m very excited to see it in the hands of students this semester.

When we release that documentation, I’ll also release the tutorial booklet that students used on the LEGO Mindstorms at the start of the term. It provided a questions-first introduction to occam-pi on the Mindstorms RCX. These documents, taken together (and iterated/revised a bit) will provide, I think, an excellent introduction to the design of concurrent and parallel algorithms for robotic control on some very cool platforms.

Watch this space!

The last post on this blog was in October. Since then, things have been busy. Over the next few posts, I’ll try and catch up a bit.

For the last three months, we’ve been working hard on the new Blackfin Surveyor SRV-1.

Blackfin SRV-1, image stolen from the Surveyor webpages

We first encountered the Surveyor at AAAI 2007. When Howard “Surveyor Daddy” Gordon updated the Surveyor from a 60MHz ARM with a few KB of RAM to a 500MHz Blackfin with 32MB of RAM, we took notice. And, even better, when it sprouted that oh-so-excellent WiFi tail, we really took notice. (It is so much easier to work with WiFi than the ZigBee radio that was there. At least for us it is.)

This semester, I’m co-teaching ENGR 3390: Robotics with Dave Barrett at Olin College, and we’re using the Surveyor as the platform for the mobile portion of the course. We’ll be using the Surveyor as a platform as a demonstrator where we can introduce students to architectures for cognition on robotic platforms in a parallel-safe way using the Transterpreter and occam-pi. And what we realized very quickly is that the SRV-1 looks like it is just begging to be beaten all to hell in the classroom.

See that processor on top, all nice and exposed? After a team of students shuffles in from the dry, Boston winter—BZZAPT!. No more Blackfin. One good static discharge, and the processor or RAM are gone. Or, those little laser diode wires? Oops! A careless gesture, and they’re yanked out. Or what about a drop from the counter-top? I’m not confident the board would handle the fall very gracefully.

Dave threw together a quick Solidworks model, and dumped it out to Olin’s rapid prototyping machine. This thing is incredible: it prints in 3D in ABS plastic. Send the model, step back, and 12 hours later you have this:

That is a battle-ready SRV-1. The laser mount was removed, and the diodes inserted into the body, which was simply printed with the diode mounts in the right place. The camera hole is oversize, and easily gives the camera a full field of view.

As you can see, the rapid prototyping machine has enough resolution to render depressed text in the body of the bot. This one clearly declares itself as property of Olin’s ENGR 3390: Robotics course.

What you may or may not be able to tell is that the entire top of the box has mounting holes at 1/2″ spacing perforating it; it is amazing what the RP machine can do. This means we can easily screw-mount sensor towers or anything else we might like to the top of the bot quickly and easily, running wires straight down through the body to the SRV-1 board.

Generally, the pictures are low quality because they were taken with the webcam built into my Macbook. I’ll get better pictures at a later point.

The first thing we’re going to have the students in the course do is take the basic Solidworks model and design bodies for their team’s bots. This way, each bot will have a unique body, and the students will have some ownership of the process. However, we already have a few things we want to improve in the basic body before we turn them loose:

• The body doesn’t have anywhere to grab on to in the back; as you can see, it is just resting on the SRV-1’s aluminum body. Our plan is to wrap around inside of the treads, where there is just enough clearance for us to sneak the body down. This way, we provide more protection for the boards from grit and the like, and can attach across the base of the bot on the underside.
• We need blinkenlight mounting holes build into the body. This way, you can just push an LED up from underneath, and it will sit flush with the housing. We can wire them into the GPIO pins inside, and have all the wires hidden from view, and safe from snags on obstacles.
• A view hole needs to be left for viewing the state of the three LEDs on the Blackfin’s motherboard.
• A mounting point for a header board could be built into the body, so sensors could be attached and detached outside; this depends on whether we expect to be doing much of this kind of prototyping with different sensors or not.
• Mount points flush with the body wall for IR and other sensors on the front/back/sides could be very useful. We have a number of interesting sensors for the students to characterize and use, and mounting them safely inside the body would be a good idea.
• The antenna should probably be above the ground plane; we could run a cable from the current point, under the body, and up to the top, where we could easily grow an antenna mount.
• We have blue and yellow plastic coming in, which will produce a lasting color. Otherwise, we have to paint, which is less durable and a mess to work with. (Well, as messy as spray paint ever is, anyway.)
• I want my robot’s body covered in dimples (and maybe some through mounting holes) that are compatible with a certain plastic building toy that rhymes with Tierra del Fuego.

Those were the immediate improvements that we saw could be made.

We’re really excited about the course, and I think both Dave and I are pretty excited about how cool the bodies for the Surveyorcould be. What’s really awesome is that they are printed in ABS plastic, and have a wall thickness of roughly 3/16″ of an inch. (I haven’t measured; that’s just my eyeball estimate from memory.) I pounded on it with my fist (off the Surveyor), and I hurt my knuckles. In short, the body is tough. The ultimate goal is to make it possible for a student, in their excitement, to give the Surveyor a kick on the field of combat (or drive it off a table), and have the bot be in a good condition to survive the fall.

Over the next two weeks, this body will evolve a lot. We’re going to be playing with it, and then 24 of Olin’s energetic, creative engineers-to-be are going to rapid-fire evolve it to their hearts content. I think we’ll end up with something very, very cool. I’ll post pictures and Solidworks models as the body evolves.

Amazing.

Carrie found a note about a Roomba. She sent it to me via IM. I sent the seller an email saying I was interested, and included my phone number. He called me within 45 seconds of hitting “send”. I’ll pick it up tomorrow.

Hopefully it was a $50 well spent. My hope is it does OK around the house, or serves well in student projects. Perhaps I can find a way to work it into Software Design this semester… I’ll have to look into getting a Bluetooth serial module or something so that students can play with it from their laptops.

We ran into something interesting the other day on the LEGO Mindstorms. In particular, something to do with time.

You see, the LEGO is a 16-bit machine. This means the largest number it can represent is 2^16 - 1, or 65535. This is OK in most cases, but I want to note that the LEGO’s clock runs at millisecond speed. That means that it ticks over once per millisecond. The number of milliseconds we can count before the clock rolls over is… 65,535.

If there are 1000 milliseconds in a second, that means that we can only count up to 65 seconds before the world ends. Now, this is fine for James Bond movies (where the hero always has one minute to accomplish his death-defying task), but we kinda want to be able to measure longer amounts of time than that.

In occam-pi, we can do this in some very cool ways. So, consider this a brief introduction to timers in occam-pi, and more specifically, how we can neatly create timers that ‘tick’ at arbitrary intervals without too much effort. I’ll continue this later in another post that explores how I build up to having timers that let me measure hours, days, weeks, and even months on the LEGO Mindstorms. For the moment, I’ll start with some basics about timers.

To start, occam-pi has a notion of a TIMER built into the language. This is kinda cool. If I wanted to write a process that would delay for some number of milliseconds, it would look like this:

PROC delay (VAL INT timeout)
  TIMER t:
  INT the.time:
  SEQ
    t ? the.time
    t ? AFTER timeout
:

The process takes one argument, which is a timeout value given in milliseconds. The timeout value has a type, which is VAL INT. This means that it is an integer, and furthermore, we cannot change it—any attempt to modify this value will result in a compile-time error. In other words, we’re saying it is a constant within this PROC.

We then declare two local variables: one of type TIMER and one of time INT. In sequence, we then read the current time into the variable ‘the.time’, and then use a funny bit of syntax to do our delay:

t ? AFTER timeout

This is some ugly stuff—something I wish they had done differently in the language. However, occam is over 20 years old, so we’ll cut it some slack. This syntax says “delay until timeout milliseconds have passed.”

And that’s it. What’s nice about this PROC is that it does not block other processes from doing their stuff. So, it effectively says “sleep, but let other people run around and do things.” Very cool.

Now, we can’t use this process to delay for more than 60 seconds or so, because the LEGO Mindstorms is limited by a maximum of roughly 65K milliseconds. Since I want to be able to do nifty things that involve timing out for more than 60 seconds, I want to start by writing a ‘ticker’ process that will generate clock ticks that I can listen for at intervals other than milliseconds.

PROC tick.generator (VAL INT delay, CHAN BOOL tick!)
  TIMER t:
  INT timeout:
  SEQ
    t ? timeout
    WHILE TRUE
      SEQ
        timeout := timeout PLUS delay
        t ? AFTER timeout
        tick ! TRUE
:

This is only slightly bigger than the previous PROC. The tick.generator has two arguments—a constant (VAL INT), and a channel that carries booleans (CHAN BOOL). The channel is an output channel because it has been decorated with a !. (The compiler can figure this out for itself, but good style dictates that we put the ! on the channel end in the PROC definition.)

Again, I declare the local variables t and timeout, read the current time, and then drop into an infinite loop. This loop increments the timeout value, delays, and then outputs a signal on the boolean channel. Now, I can put this and a few other things together to create a complete program. This will execute just fine on your desktop, so if you paste it into your JEdit window, save it as “ticker.occ”, compile, and run, you can see what it does. (Note that I’ve defined constants for SECONDS and MILLIS; on the LEGO, you would redefine MILLIS to be 1.)

VAL INT MILLIS IS 1000:
VAL INT SECONDS IS 1000 * MILLIS:

PROC delay (VAL INT timeout)
  TIMER t:
  INT the.time:
  SEQ
    t ? the.time
    t ? AFTER timeout
:

PROC tick.generator (VAL INT delay, CHAN BOOL tick!)
  TIMER t:
  INT timeout:
  SEQ
    t ? timeout
    WHILE TRUE
      SEQ
        timeout := timeout PLUS delay
        t ? AFTER timeout
        tick ! TRUE
:

PROC tick.seconds (CHAN BOOL tick!)
  tick.generator(1 * SECONDS, tick!)
:

VAL BYTE flush IS 255:
PROC show.seconds.tick(CHAN BYTE kyb, scr, err)
  CHAN BOOL ticker:
  PAR
    tick.seconds(ticker!)
    WHILE TRUE
      SEQ
        BOOL tmp:
        ticker ? tmp
        scr ! ‘x’
        scr ! flush
:

The last process, ’show.seconds.tick’, demonstrates how we don’t always have to name our processes to run them in parallel. First, I declare a channel to carry boolean values (remember, channels are like wires—channels carry information from one process to another.) Then, in parallel, I want to run the process ‘tick.seconds’ and an infinite loop that I’ve written. The process ‘tick.seconds’ gets one end of the channel ‘ticker’—in particular, it gets the end of the channel that will be written to.

In the infinite loop, I do a few things in sequence. First, I declare a temporary variable that is only valid for one line of code. That is, it exists just long enough to read from the ticker channel into the variable ‘tmp’. This is because I don’t actually care about keeping that value, but I have to read from the channel into something. After reading from the channel, I output an ‘x’ to the screen, and then I flush the screen, so that the output is actually shown.

Remember that occam-pi channels are blocking channels. That means that my infinite loop will stop every time it hits the line ‘ticker ? tmp’. It will wait until the process ‘tick.seconds’ has written a value, and then the loop can continue. Also, it is important to remember that every time you see a channel read (eg. ‘ch ? var’) or a channel write (eg. ‘ch ! var’), the Transterpreter deschedules the currently executing process, and goes and runs something else. This way, everyone gets a turn to execute. This is why the delay process I introduced earlier does not block everything running on the system, and why we can write infinite loops as casually as I have here… because each one contains a channel communication.

In my next post, I’ll follow up with how to extend this into timers that can last for days or even weeks on something as small as the LEGO Mindstorms. Also, I still need to follow up on our subsumption code for the Surveyor—but that will come, perhaps, after this timer exploration. In fact, this came up because we were trying to run our code from the Surveyor on the LEGO, and we discovered that having a 32-bit timer (like on the Surveyor SRV-1) is very handy, while having a 16-bit timer (like on the LEGO Mindstorms RCX) is a bit annoying… where “annoying” means “Hey! Our code doesn’t work!”

I recently caught sight of the article Subsumption for the SR04 and jBot Robots over at the Dallas Personal Robotics Group’s webpage. What is sad is that the first thing that David Anderson goes into is technical details regarding their timing loop. Sadly, timing has nothing to do with implementing the subsumption architecture. Our recent explorations on the SRV-1 demonstrate this nicely, I think.

At AAAI, Jon and I implemented code for the mini-robotics-challenge that was hosted in our session. We had to program a robot that would:

1. Wander as far from its start point as possible in 30 seconds, avoiding obstacles
2. Return as close to home in the next 30 seconds.

This is a trivial task, but all the participants were using robotics platforms they had never seen before, and had roughly 1.5 hours to implement their solutions. Having first seen the SRV-1 just a day before, we had ported the Transterpreter to it, and had basic motor control and access to the IR sensors. Using this, we looked at the problem, and tackled it by implementing a three-layer subsumption architecture.

At the lowest level, we wanted our robot to go forward. We wanted a higher-level behavior that would avoid obstacles, and a third, even higher level behavior that would (after 30 seconds) replay the motor commands that had been generated in the previous 30 seconds (causing the robot to retrace its steps). This is a bit odd as subsumption architectures go (having a layer that suppresses everything below it simply to replay previous actions), but it yielded a very clean implementation.

What follows is the network, and a step-by-step decomposition of how it worked.

Each orange box represents an occam-pi process; in some languages, you might call these “threads”. However, in occam-pi, processes have certain properties. First, they are completely sealed, and therefore, no other process can manipulate their state; for example, anything in the “forward” process is completely isolated from the “avoid” process, and visa versa. Also, occam-pi processes are incredibly light-weight: we can run hundreds of these processes on robots the size of a LEGO Mindstorms or the SRV-1, and therefore casually write highly concurrent programs for very small robots.

The arrows in this diagram are channels; they carry data from one process to another. In fact, channels are the only way two processes can communicate with each-other. First, they are unidirectional; you can only talk in one direction down a channel. Second, they are blocking, meaning that once committed to a communication (either a send or a receive), the communicating process deschedules, and waits until the other half of the communication is carried out. This explicit synchronization makes it easy to reason about many different processes taking turns doing computation and communicating between each-other.

Level 0: Going Forward

With this brief background in occam-pi, you can begin to piece together the network. The forward process sends motor commands to a suppressor process (S1), which communicates on to another suppressor process (S2). This then communicates to a delta process (which copies its input to two outputs). One of those outputs flows to the motors, and the other to a process called record, which records all the motor commands sent to it. In the common case, both suppressors are inactive, and motor commands flow around the network as depicted below:

Level 1: An object detected

When an object is detected, the avoid process kicks in. Note that it does not “turn off” or “disable” the forward process—both are always running concurrently. However, suppressor S1 becomes active when the avoid process goes active. It does this when it detects something in front of the robot using the IR sensor. It then begins sending commands to pivot the robot to the left. (This is a pretty dumb robot, really.) These new commands are routed through S1 instead of the commands from forward, and the robot pivots away from the obstacle (and records the pivot as well).

Level 2: Replay!

The trickiest bit of work comes when we begin replaying our movements after 30 seconds have passed. The live portions of the network look like this:

The replay module suppresses the output of both the forward and avoid processes. It also inhibits communications between the delta process and the record process; this is because we definitely do not want to be recording the playback! (We made this error, initially; it yielded very strange robot behaviors, and usually ended in both a crash of hardware and software.)

The replay module requests actions from the record process, and then plays each of those actions down the channel it has to S2; these are routed through to the run.motor process. The end result is that our robot replays all of the actions that were recorded over the previous thirty seconds.

It seems so complex!

It may, or it may not—it depends on how you like to think about control systems for embedded devices (like little robots). I prefer this model, where nowhere in my code am I worrying about timing—instead, I’m just worrying about where my data is flowing. In this case, I’m flowing motor commands from one process to another, and I’ve written special processes (the suppressors and inhibitor) to control how that data flows through the network. The language and runtime are responsible for handling the concurrency—not me.

For a C programmer, this is a completely foreign idea. However, it is (I believe) the case that C is generally useful only for very specific tasks, like hardware interfacing. Handling complex data structures, complex data flows, and any kind of concurrency or parallelism is something that should be left to the compiler, not the programmer. Put another way, we as programmers are too error prone to be left on our own writing complex control loops, and languages like occam-pi are a first step towards managing that complexity.

As always, we encourage you to take a look at RoboDeb if you’re interested in the intersection between robotics and concurrent programming languages. We’re very, very close to releasing the newly revised LEGO Mindstorms runtime, which will let you explore occam-pi on your Mindstorms as well. (Our NXT port will follow that release.)

What about the code?

Most of the code for this was written in the twenty minutes before the robotics competition. I could go into the code here, but for the moment will beg off (it is a beautiful day, and I’d rather be outside). However, you can see the code online in our Subversion repository.

If you want to know more about the code, drop me an email (matt at transterpreter dot org), and I’ll put together a post that goes through it in more detail. You might start with Jon Simpson’s paper Mobile Robot Control: The Subsumption Architecture and occam-pi (PDF), as it goes through a similar process network, and includes code for the inhibitor and suppressor processes. (It will be more readable than anything I hack into the ‘blog, anyway.)

On March 29th, we gave our first Google TechTalk!

You can hit the link to go to the Google Video site. So far, we’ve had quite a few views, and apparently, people enjoy it (according to the ratings, anyway). We had a hard time targeting the talk; we rewrote it several times before giving it, as we couldn’t decide how best to approach the work we’ve been doing for the last four years. Do we dive straight into how we can use a language like occam-pi for abstracting over clusters, or how we can build safer, concurrent software on embedded platforms?

In the end, we gave an introduction to the language, and then focused a bit on how we can convert parallel models of software directly into code, and motivated this using Jon Simpson’s work with the subsumption architecture on small robotics platforms. We received many positive comments on the talk, and one person did say they thought it was light on “hard-core” detail. But what can you do in 45 minutes with an unknown audience?

In the end, we gave a good talk, and were excited to be able to share our work with the Googlers there and who are now catching the video on-line. (And, for that matter, anyone else who wants to see what we had to say.)

Certainly, it was a lot of fun. And yes, the food in the cafeterias at Google really is that good.

We spent the first three days of last week taking part in the AAAI 2007 Spring Symposium. In particular, we joined the Robotics and Education track with about 50 others interested in using robotics to teach everything from introductory programming to vision, pathfinding/planning, decision making, and all the other tasty bits of artificial intelligence.

Scribbler

Turtle

We saw some very cool projects and platforms. I really liked Roomba Pac-Man (where students program Roombas to wander hallways and vacuum up messes in a pac-man like way), and the Scribbler (while not very aesthetically pleasing) is a cute re-creation of the LOGO turtle. (I’ve provided a side-by-side comparison of what these two robots look like; the original turtle was, I think, far more attractive.)

In terms of platforms, many people are doing “tethered” robotics, where they either physically or wirelessly tether their robot to a PC. This is, I think, unfortunate, as I feel it takes something away from the process of programming the robot—it is a remote control process, as opposed to an autonomous one. However, like many things, it depends on what your pedagogic goals are. However, I do look forward to a few things: I think the Qwerk is a neat (part of the TeRK project) and we hope that we have a chance to work with it sometime in the future. It’s a powerful computational platform with a lot of nice outputs for motor and servo control, as well as managing a host of sensor inputs. Likewise, the Blackfin Handyboard is a very powerful platform, and will also be great to begin exploring, as it provides some very flexible programming options in the form of two Xilinx FPGAs. Fred and Andrew did a very nice job with the board design, and I expect many cool things will be done with this platform.

We also saw David Miller’s XBC/Gameboy combination, which I now have a Gameboy to try this out with (once I have a budget to get the rest of the bits, which is actually the expensive part). However, the really fun new platform was the Surveyor Robotics SRV-1.

Howard wrote about our experiments with the SRV-1 on his weblog, and I’ll add a bit here, and followup in a later post with some more detail. We were given an SRV-1 to borrow on Monday evening, and did very little with it, as we were missing critical software. Tuesday, during coffee breaks and the like, Christian ported the Transterpreter to the SRV-1. In less than two days, we saw a new, ARM7-based robotics platform, and had the Transterpreter running subsumption code on it. In three days (that is, the day after the conference), Christian had vision working.

I went ahead and stole a picture from Howard; here, you can see the end-result of our hacking, which is that we won the AAAI Robotics and Education robotics programming challenge. We did this with the SRV-1 after having seen it for the first time on Monday, having ported our runtime to it on Tuesday, and having seen the challenge on Wednesday morning. We managed a (not-quite-working) 3-layer subsumption network that tackled the challenge in about 20 minutes of furious hacking; I’ll write more in detail about our code (which we’ve subsequently cleaned up and corrected) in a followup post.

For now, we’re still kicking around San Francisco and the Bay area, enjoying two days off before flying back to England on Wednesday.

Sunday I take off for San Fran, and am pretty psyched. Christian, Jon, and I are heading to the AAAI Spring Symposium to talk robotics and concurrency with a bunch of other robotically-minded people; that fills our time between Sunday and Wednesday. Thursday, we’ll be giving a Google TechTalk, which should be very fun—at least, we’re planning on enjoying the talk immensely. Then, we’re thinking (but aren’t committed) to doing a little bit of light camping, as this time of year can be soooo nice in the Bay area.

We don’t have housing nailed down for Palo Alto Sunday/Monday/Tuesday, but I think we might just grab a hotel near Stanford. It will be a bit pricey, but otherwise, we’re dealing with cars, and parking, and commuting, and… that’s not so much fun. We’ll see.

I’ve touched base with a few friends in the area (dbort and Tzu), but I’m wondering if there’s anyone I missed. Is there anyone who reads this blog who is in the Bay area I should try and say ‘hi’ to? Is there anyone who reads this blog who knows anyone in the Bay area I should say ‘hi’ to? (I think that’s one degree of separation; more degrees of separation than that, and I suspect I only want to know them if they’re going to give me money for my ideas on fixing email, or if they want to give us a place to sleep.)

This is very, very exciting. I mean… very. Exciting. Very.

OK, so I just like talking about and playing with robots. What can I say?

Sadly, my Roomba arrived dead-on-arrival. I’m waiting for a UPS label to mail it back (along with the bits that fell out of its innards upon opening). Given our timeframe, I don’t think I’ll order another before going back to England.

And it looked like such a good toy, too. I had visions of plugging my Gumstix into it, and writing my own vacuuming algorithms on the Transterpreter.