My recollection was right, and while the management server appliance proved both annoying to work with and massive overkill for my home projects, I’ve had some luck scraping data out of its web UI.

I wrote a few python classes to make it reasonable to programmatically access the data generated by the cameras and sensors in my backyard chicken coop; you can see the end result at pachube.

The code is available here.  It’s driven by a small db schema that holds basic location info for the monitoring gear and metadata about sensors being watched (e.g. polling intervals and alert thresholds), and produces simple name/value pairs with sensor data satisfying given conditions.  By “conditions” here I mean things like “it’s time to report this sensor value” or “this value changed too much, so I’m reporting on it” — this is by no means meant to replace actual monitoring systems (though it could easily be used to interface with them).

While I wrote fairly thorough pydoc, the overall documentation is hardly extensive, so I’d be happy to answer questions if getting at netbotz data from python is interesting to anybody else.

I’ve been working on some code to scrape data out of the Netbotz web UI (which does not have an easy to use API) and, as I got to working on the data storage backend for the scraper, remembered Pachube and decided to give it a try rather than reinventing what was effectively the same wheel.

I have generally positive impressions of Pachube after a couple of days messing around with it.  It was pretty easy to get going, and after stumbling into one quickly-fixed bug was up and sending data in from my prototype scraper pretty quickly.

I’m using the following python class to simplify the interaction.  It’s trivial, but I didn’t see anything similar already done, so am throwing it here for future google results:

#!/usr/bin/python

# This code is released into the public domain (though I'd be interested in seeing
#  improvements or extensions, if you're willing to share back).

import mechanize
import json
import time

class PachubeFeedUpdate:

  _url_base = "http://api.pachube.com/v2/feeds/"
  _feed_id = None
  _version = None
  ## the substance of our update - list of dictionaries with keys 'id' and 'current_value'
  _data = None
  ## the actual object we'll JSONify and send to the API endpoint
  _payload = None
  _opener = None

  def __init__(self, feed_id, apikey):
    self._version = "1.0.0"
    self._feed_id = feed_id
    self._opener = mechanize.build_opener()
    self._opener.addheaders = [('X-PachubeApiKey',apikey)]
    self._data = []
    self._payload = {}

  def addDatapoint(self,dp_id,dp_value):
    self._data.append({'id':dp_id, 'current_value':dp_value})

  def buildUpdate(self):
    self._payload['version'] = self._version
    self._payload['id'] = self._feed_id
    self._payload['datastreams'] = self._data

  def sendUpdate(self):
    url = self._url_base + self._feed_id + "?_method=put"
    try:
      self._opener.open(url,json.dumps(self._payload))
    except mechanize.HTTPError as e:
      print "An HTTP error occurred: %s " % e

Usage is pretty straightforward.  For example, assuming you have defined key (with a valid API key from Pachube) and feed (a few clicks in the browser once you’ve registered) it’s basically like:

pfu = PachubeFeedUpdate(feed,key)
# do some stuff; gather data, repeating as necessary for any number of datastreams
pfu.addDatapoint(<datastream_id>,<data_value>))
# finish up and submit the data
pfu.buildUpdate()
pfu.sendUpdate()

The resulting datapoints basically end up looking like they were logged at the time the sendUpdate() call is made.  In my situation, I want to send readings from a couple of dozen sensors each into their own Pachube datastream in one shot, so this works fine.  If, instead, for some reason you need to accumulate updates over time without posting them, you’d need to take a different approach.

While the coop isn’t quite done, earlier this week we took delivery of its future inhabitants.  As usual, @amyj has better pictures, but I’ve got webcams and sensors!  You can follow along with the growth and play of our baby chicks here.  They mostly just eat and poop, but they’re really cute while they’re doing it.  [Note: you can click around in the interface to see different views, sensor readings, etc.]

At the moment there are eight chicks, due to an order processing error (we only ordered four).  Hopefully we’ll find the extras a new home soon, and it’ll just be the four again.

While we’d intended to have lunch, Jacs serves only brunch between 10am and 3pm on weekends.  The brunch menu had some very tasty looking breakfasts (omelets, eggs benedict, various lighter breakfasts, etc.) and a handful of sandwiches.

I was happy to see the moules frites still on the menu, as they were the only thing on the MSB’s menu that I ever found pleasing without caveat (and the only area in which MSB came anywhere close to its generally superior neighbor up the street, Brasserie V).  I don’t know that they’re the same, but my understanding is that there’s some continuity in ownership and/or management between the two, so there’s reason for hope.

I wasn’t in the mood for mussels, though, so I decided to order the burger.  I’m not a huge burger fan, but I do enjoy a good burger once in a while, and find it a reasonable way to form an initial impression of a place like Jacs, given that many of my favorite burgers in town come from generally similar establishments.  (Roughly in order, I’m thinking of The Old Fashioned, Brocach, Brasserie V, and Dotty’s.  Sorry, Weary Traveler, I love the place but the Bad Breath Burger just doesn’t do it for me.)  Jacs’ burger was served on a ciabatta roll with caramelized onions, cheddar, aioli, lettuce, and tomato.  I’d call it solidly ‘good’, but not quite great.  I has asked for it medium rare, but my burger instead showed a puzzling range of doneness:  fully rare on one half, appropriately medium rare for about a quarter, and pretty much medium on the remaining quarter.  Flavors were all good, though if the aioli had simply been described as mayo I probably wouldn’t have noticed that it wasn’t.  The bun was a particular happy note on the burger.  It nearly scared me away from ordering it at all, as MSB also served their burger (which I tried exactly once) on a ciabatta role that I found to be a tough and regrettable distraction from an already non-awesome sandwich.  I don’t know if Jacs changed their bun source or if I perhaps had caught the Bistro on a particularly bad day, but this bun was a clearly positive addition.  Until someone starts just putting their hamburger on the ciabatta from Lombardino’s (hint, hint), I’m comfortable calling this my favorite bun in town.

Amy was about to order the quiche but changed her mind at the last minute when I pointed out that the “Summer Sausage Sandwich” didn’t look as yucky as the name suggested.  Processed meat plays an appropriately subtle role in this sandwich, which otherwise consisted of fresh mozzarella, arugula, red onion, and tomato on a baguette.  She liked it, but didn’t love it.   “It didn’t rock my world” was her comment, but she didn’t regret the choice.

We both chose the soup of the day as our side (other choices were green salad, frites, and a quinoa salad that wasn’t available, presumably due to a new restaurant getting its kinks worked out).  The soup was an herbed new potato (at least until they ran out one cup after filling our order) that I found to be quite good.  I’m a huge soup fan, and based on today’s experience will certainly make a point of trying Jacs’ other soups du jour.  Our daughter Nora (2), inherited Daddy’s soup-loving gene, and also liked it — she kept nuzzling up to my elbow and asking for more tastes.

Ben (5) is still in his post toddler conservative palate phase, and Nora doesn’t eat much (by adult standards), so we ordered the fruit and yogurt breakfast plate for them to share, and a side order of frites for the table.   The granola served with the fruit and yogurt plate was among the best I’ve had, and the fruit and yogurt quite satisfactory.

The frites were excellent, as MSB’s had been.  One cone was plenty for us all to have a nice side snack.  I adore Brasserie V (though I’m still a bit sore about the loss of the duck confit from their dinner menu), but these frites were better than any I’ve had up the street.

The beer list at Jacs is scaled back from MSB’s, but is still exceptional for a small restaurant/bar.  There were about a dozen beers on tap, roughly half of which Belgians of various sorts.  Brasserie V is secure in its position as Monroe Street’s (and arguably Madison’s) best restaurant beer list, but Jacs is no slouch in this department.  I had a glass of the Val-Dieu Grand Cru, which didn’t disappoint.

Jacs’ location has seen a lot of turnover in the past decade.  The series of predecessors to MSB — the Creole Cafe, Louisianne’s Kitchen, and Papa Phil’s — were all good restaurants.  (The pulled pork po’ boy with bleu cheese cole slaw and pepper jelly from Louisianne’s Kitchen was the best sandwich I’ve ever had, and I miss it somewhat desperately to this day.)  In this same time period, the Pasqual’s directly across the street (with equally challenging parking and similar prices) has doubled in size, and is consistently full.  There may be lots of non-obvious reasons for this disparity, but there is an obvious difference in the kid-friendliness department.  On any given visit to Pasqual’s I generally see more kids than I saw cumulatively over the years in the various restaurants in Jacs’ current location.

Judging by the press surrounding the announcement of MSB’s demise and Jacs birth, this wasn’t lost on the proprietors of Jacs, who made a big deal out of their intent to be more kid/family friendly.  OK, cool.  The intent is visible: the hostess came back right after seating us with a bag of toys for the kids to play with — more fun than the usual crayons + inane puzzle, and less wasteful.  It could use some fine-tuning, though.  The brunch menu didn’t have a kids menu or any obviously kid-oriented items.  Also, the brunch-only weekend daytime menu will probably leave us going less than we would if there were breakfast at breakfast time and a full lunch menu at midday.

I’ll definitely go back to Jacs.  The dinner menu had a number of things that looked good (the small menu at the MSB was both uninspired and uninspiring, leaving me inclined to order ‘meh’ for my few dinners there during its short run).  I’d like to try breakfast there, too, though not being able to eat breakfast until 10am is a bummer.  At least one can compensate with $2 mimosas or bloody marys.

The Cable

I’ve had the necessary cable (straight-through 8 pin mini-DIN) to connect to the serial control connector on the Roomba quite a while, and I’d already successfully cut a hole in the top of the Roomba’s cover to expose the port.  (I used a Dremel, though I suppose you could drill and file if you were careful and patient.)

I cut the cable in half and soldered male header pins to the correct wires to make a 2-pin power/ground connector and a 3-pin connector that had the serial RX/TX line as well as the DD (Device Detect) pin.  (There’s no reason the serial and DD lines need to be next to each other, but it made for a simpler connector, and it’s easy to just assign them proximate ports on the Arduino’s digital pin bank.)  Tod Kurt, author of Hacking Roomba and part of the impressive ThingM studio, has a basic photoset showing a similar cable.  At this point, if you’re looking to do this yourself, you may be wondering which wires in the cable need to go to which pins of the connectors.  I have no idea if there’s reliable consistency in the colors used inside of mini-DIN cables, so I’d suggest figuring this out yourself with your specific cable and a continuity detector of some sort.  The pin diagram on page 2 of iRobot’s SCI (Serial Command Interface) documentation should be all you need.

Powering the Arduino

The power connector from the Roomba is carrying +16V, which is more than enough to power the Arduino (I’m using the Diecimila and Duemilanove versions of the board).  According to the docs, this is within the acceptable input range, but outside of the recommended range.  In my early attempts to hook it up, I seem to have fried a Diecimila board by connecting Roomba’s +V line to the ‘Vin’ header on the Arduino (sometimes labeled ’9V’).  I got it working by running the Roomba’s +V line through a 5V voltage regulator and then directly into the ’5V’ header on the Arduino (note:  it’s important to only do this with a regulated supply, since the 5V header bypasses the Arduino’s onboard regulator).  This worked fine, even if it does mean that the minimal setup is no longer just an Arduino and a cable.  After I fried the Diecimila, I switched to a Duemilanove, though to my knowledge there is no relevant difference in terms of power requirements or tolerance.

OK, It Should Work Now

Based on the research I’d done, I expected that things would more or less just work at this point.  For the software side of my proof of concept, I was using Tod Kurt’s RoombaBumpTurn sketch.  The sketch sends the Roomba forward, then checks the left and right bump sensors in a loop, turning ‘away’ from the objects it collides with.

I was excited on my first attempt to see the Roomba ‘wake up’ shortly after connecting my cable to the board.  Then:  nothing.  Hmm.

By default, the Roomba’s SCI talks at 57000 bps, and the code was assuming that data rate.  I didn’t recall having changed it during previous times hacking around with the Roomba, but just in case I changed the serial speed to 19200 and, sure enough, the Roomba jolted forward shortly after powering up the Arduino.  OK, cool, so there was at least basic connectivity.

I didn’t really have a reason to run at the slower serial speed, so I threw a quick one-time change into the setup() function to reset the baud rate back to 57000:

// [re]set baud rate to 57600
sciSerial.print(129, BYTE);  // BAUD
sciSerial.print(10, BYTE);   // 57600
delay(100);

*Now* It Should Work, Really

With basic serial connectivity established, I went on to verify that basic bumping and turning behavior worked as expected.  In short, it didn’t.  Most of the time letting the Roomba collide with something (or even just manually pressing the sensor) did nothing;  perhaps 10% of the time it would cause the Roomba to turn.  In order to verify that I really was getting commands to the Roomba, I added a short sequence of actions called from the setup() method:

void dance() {
  xbSerial.println("top of dance()");
  updateSensors();
  goForward();
  delay(1000);
  goBackward();
  delay(1000);
  stopMoving();
}
...
void stopMoving() {
  sciSerial.print(137, BYTE);   // DRIVE
  sciSerial.print(0x00,BYTE);   // 0x0000 == 0
  sciSerial.print(0x00,BYTE);
  sciSerial.print(0x00,BYTE);
  sciSerial.print(0x00,BYTE);   // 0x0000
}

The Roomba jogged forward, and backward, just as I’d expect.  This left me pretty much convinced that sending commands was working fine, and that my problem was in reading sensor values.

At this point I really started to feel the lack of debugging information.  While I was pretty sure my problem was in sensor reading, it was certainly time to validate my overall expectations about program flow, as well as inspect return values from the sensor checks, etc.  Debugging is always more of a challenge on an embedded platform with no display/keyboard, but my typical answer for this when using the Arduino — “I’ll just println() to the serial port and monitor it over USB” — doesn’t work here, for two reasons.  First, the serial port is being used by the connection to the Roomba.  As if that weren’t enough (and it is), the Roomba is driving across the floor, and I wouldn’t want to chase after it with my laptop.

Remote Wireless Debugging with XBee

Fortunately, there is a good answer to debugging the code running on the Arduino sitting on top of my Roomba as it scoots away from me:  Digi’s XBee modules.  I’ve been playing around with these for a different project recently, and at a basic level they provide an easy wireless link with a serial interface.  Interfacing with the Arduino is a snap with the XBee adapter kit from the outstanding adafruit industries (sparkfun also has a breakout board I’ve used with success, but it requires a bit more of a surrounding circuit — nothing tricky, but not as easy as adafruit’s).

The attentive reader might now be wondering:  I just explained that my serial port was already spoken for, and the XBee module has a serial interface.  So how does this really solve my problem?  Enter NewSoftSerial, an updated version of the Arduino software serial library, which basically lets you drive a serial interface from any two digital I/O pins on the Arduino.  [Yes, I could also use this to debug directly over a serial line, which would be an option if you didn't have a pair of XBee modules and didn't mind potentially chasing after your Roomba.]  I had a pair of XBee modules already configured to talk to each other (details of that are far outside the current scope).  One module got connected to a couple of pins on the Arduino, and the other to my laptop via the trusty FTDI USB TTL-232 cable.  On the laptop I then ran a simple serial terminal with ‘screen’ (any terminal program would do), and voila — I can println() from the vacuum cleaning scuttling across the floor and see it on my laptop from across the room (or halfway down the block, for that matter).

With basic visibility established, I was able to dig further into what wasn’t working with regard to sensor readings.   The sensor reading routine in RoombaBumpTurn is pretty straightforward:

void updateSensors() {
  Serial.print(142, BYTE);
  Serial.print(1,   BYTE);  // sensor packet 1, 10 bytes
  delay(100); // wait for sensors
  char i = 0;
  while(Serial.available()) {
    int c = Serial.read();
    if( c==-1 ) {
      for( int i=0; i<5; i ++ ) {   // say we had an error via the LED
        digitalWrite(ledPin, HIGH);
        delay(50);
        digitalWrite(ledPin, LOW);
        delay(50);
      }
    }
    sensorbytes[i++] = c;
  }
}

After adding some basic println() breadcrumbs (not shown here), it quickly became clear that this function simply wasn’t returning a value that suggested it had correctly read the bump sensors.  The clearest indication of this was when I added some code to check the value of i at the end of updateSensors().  The SCI doc is pretty clear — you ask for sensor packet 1, you get 10 bytes back.  However, I was consistently getting 2 bytes, or 4 bytes, or 3.  Once in a while I’d get 10 bytes, but it was rare.

This is good.  This is progress.

Other People’s Problems

I googled for notes from others doing similar things, and found a number of examples.  Actually, I found a surprising (but at this point encouraging) number of people having problems reading Roomba sensors from Arduinos.  Some of the closest matches were:

• “Roomba SE Receiving Serial Data” on the Robot Reviews forum
  A long thread, most of which is exploring a possible hardware inconsistency between the Roomba’s serial signal and Arduino’s serial port.  The original poster is also working with the RoombaBumpTurn code, it seems, but near the end of the thread it spontaneously starts working, with no changes having been made (huh?).
• “SERIAL COMMUNICATION NOT WORKING!!!” on Robot Reviews
  This one starts out with a similar problem description, but concludes that the Arduino Diecimila (the previous generation) works with the Roomba, while Duemilanove (the current) doesn’t.  I am certainly not a hardware guy, but from my understanding of the differences between these boards that doesn’t sound likely.
• “Software Serial” on the Arduino Forum
  A relatively short thread, this starts out referencing the hardware issues speculated on in the first thread, and concludes with the original poster successfully getting sensor readings after switching the Arduino<->Roomba serial connection to use a software serial driver rather than the Arduino hardware.

I also encountered a few posters who noted that they’d had different amounts of success by changing the amount of time the code waits after sending the sensor read command to the Roomba and starting trying to read results.  The default in RoombaBumpTurn is 100ms, one person noted that 64ms seemed to work, and I found I’d get more readings (roughly) the lower I set the delay, but I’d also get more phantom readings (i.e. where the Arduino thought a bump sensor had been activated when none had).  In any case, regardless of the duration of the delay I never anything close to accurate, and never was able to consistently see 10 bytes of data coming back from the Roomba.

Solved!

The theme of inconsistent serial interfaces between the Roomba and the Arduino was too prevalent to ignore.  I was skeptical about it largely because, as I understood the hypothesis, it should have meant that no Roomba-controlling Arduino code connected via the built-in hardware serial interface would work, and there are a number of hints (including, primarily, the RoombaBumpTurn code) that it was working for some people.  After more or less running out of other things to try, however, I decided to give it a shot, and switched my hacked-up copy of RoombaBumpTurn around so that it expected the XBee to be connected to the hardware interface and used NewSoftSerial to connect to the Roomba SCI port.

And that did it.  Immediately, everything worked.

In Conclusion

I think the good folks in the Robot Reviews forum have nailed the issue, and that the current levels produced by the Roomba are too low to consistently register on the Arduino’s UART.  I can’t explain how that is consistent with the “now it works .. I don’t know what I changed” stories I found in a few places, or how anyone has consistently controlled Roombas from the Arduino’s hardware serial port.  In addition to using a software serial interface, user kg4wsv on the Arduino forum suggests a pair of back-to-back TTL signal inverters to buffer and bolster the current on the signal coming from the Arduino;  I haven’t tried that yet, but it could be a useful alternative if your program was going to use frequently talk over the SCI connection (as software serial is relatively expensive, computationally).

With all of this sorted out, my Roomba is now running the simple bump & turn algorithm (I added a few pauses to make it easier to see exactly what sensor readings the code got).

I remember when Ben used to say “Happy Day” instead of Happy Birthday. I don’t know when he stopped…you never know when they will stop doing those things…you always noticed the “firsts”, the “lasts” seem to slip by…. I wonder when the last time Nora will make her little snoring sound when she lays down to sleep or notices something sleeping or puts her babies or animals to sleep …

Indeed.  For years I’ve intended to more systematically capture the countless precious moments, hilarious tidbits, etc. that our kids produce on a daily basis.  It occurred to me that posterous.com, which I’d briefly toyed with over the holidays but not really found a real use for, would be perfect for this.

And so I now intend to start recording those moments — the things the kids say that make me smile or laugh, the fun things we do, et cetera.  At the risk of  overwhelming cheesiness, John Lennon put it well:   “life is what happens to you while you’re busy making other plans”.

Here it is.  Honestly, it will probably bore you with its detail.  I’m the intended audience, I’m just keeping it public.  So follow along if you’d like.

• my delicious stream (bookmarks)
• twitter
• google reader share
• linked.in
• facebook
• friendfeed
• last.fm
• boxee
• posterous (new, sort of blog-like, with very simple multi-media publishing)
• yelp

If we know each other and you’re on the above, send me a friend/link invite so we can connect there as well.

I’ll still occasionally post here (probably about as often as I have the past few years), though by far most of my day-to-day activity is in one of the above.

I had a near miss at a failblog-worthy photo when I happened upon the following scene in an airport last week:

The title of the book isn’t really visible in the hastily-taken cell phone camera shot, but it’s The Seven Habits of Highly Effective People.  Seriously.

Twitter seems to be back now.

I’ve been working on a simple wireless light, temp, and motion sensor.  Light was a trivial CDS photocell connected to the analog port of the arduino.  My first attempt at temp is using the Dallas Semiconductor DS-18B20 digital one-wire sensor, which is pretty slick for $4.25.

There was some good sample code on the main arduino site, but I spent a small bit of time to flesh it out more completely, adding the ability to configure sensor resolution and extracting the temp value from the returned data.  Code is here, if this is interesting or useful to you.

A few of the cards, though, had the record of an idiom mixing game my colleagues and I played back in the day (I’ve had the distinct pleasure of working with strongly multi-disciplinary and linguistically inclined geeks).

At its basic level, the game produced comprehensible phrases that amusingly combined two familiar idioms, such as “there are other fish to skin”, or “there are other cats in the sea”.

These are good for a chuckle, but not fundamentally anything more than language slapstick. Some combined idioms of similar intent in ways that made more vibrant images than did the originals, such as

“that opens up a whole new can of monkeys”

(A “can of worms” is one thing, but monkeys make everything funnier.) Rather than just “getting ducks in a row” or having things “fall in line”, we had

“all the ducks are falling in line”

Other are amusing but confusing, and almost seem as if they mean something, at least until you actually think about them. Example:

“Happier than a clam in pigsh*t”

The pinnacle of our mixed idiom game, though, were those hard to find combinations whose meanings were a novel blend of the original idioms. Most of these tended to mockingly riff on various elements of commonly accepted corporate-speak.

“I’m just putting them on the table as I see them”

for example, takes the casual (if sometimes cowardly) innocence of the defensive verbal communication standby “I’m just calling them as I see them” with the trite business-ese of “putting something on the table” to create an all-new description of an impetuous laziness thrust upon others.

Better still, in my opinion, is the lighthearted cynical foreshadowing of:

“We’ll burn that bridge when we come to it”

But my favorite, by far, is a sadly apt commentary on organizational politics gone awry:

“I dropped the ball in your court”

Have more? Oh yes you do … comment away!