Yay!
I took the SaucerBot to the HomeBrew Robotics Club TableBot Challenge tonight and it acquitted itself nicely. One gentle lap up to the end of the table, a peek over the edge to decide it really didn’t want to go there, and then a gentle roll back to it’s starting point. Very simple, but *whew*. This is where battery life, code and working sensors really need to happen. I have to admit I was a bit nervous because I’d only added a rear IR-ranger the night before and tested it maybe once or twice.

Generally the “Challenge” part of the meeting went really well with nobody’s robot taking a header off any end of the table. My new ‘bot had company on the table too.

Ralph came up with a really cool tablebot that uses bare sonar transducers for object detection. He’s doing the processing of the returns himself onboard rather than using a prebuilt sensor like us mere mortals do. It’s also got a really neat wheel-and-trap mechanism for capturing an object in front of it after the sonar sensors detect it.

Denise and Larry built the “BreadBot” for the Challenge.

It uses contact-switches as a way to tell when it’s reached the edge of the table.

So I’ve got until August to get some sort of gripper or scoop on the SaucerBot and teach it how to find and pick up things. I’ve certainly got plenty of toys and objects I could use for that from when I was training Rivet to do the same thing. I think this is doable.

I made a bunch of progress on the new ‘bot this weekend. I finally settled on a front wheel, choosing a ball caster over a couple other wheeled alternatives. I also got the motors and motor controller hooked up and talking to each other. The Arduino kind of works, but needs to be on a separate battery I think. When testing the two together last night I noticed that the serial comm between the two is a bit futzy when both the motors and the Arduino are on the same battery(nine-volt 1.6Ah), but fine when I’ve got the Arduino plugged into my laptop via USB.
I’m thinking that there’s just not enough juice to drive everything AND provide a solid +5V over the TTL serial lines. . Anyway, I’ll figure it out.
Here’s a short video of it rolling around with the motor controller in demo/diag. mode.

So, what got me to drag this back off the shelf and start writing again ?—A new ‘bot, what else !

Rivet, the CreateBot, will probably always be an experimental platform. I’ve put a lot of time into him for about 2 years now and am not giving up on working on him, but felt the need to start creating from scratch again. Feorlen gave me her dead Apple Airport a few years ago and I promptly gutted it and threw the useful bits like the shell and the metal in the parts pile and the rest of it in e-waste.

Most good things need to age, wine, cheese, fabric, etc. Robot parts are not all that different it turns out. So with the HomeBrew TableBot Challenge coming up, it was time to pull these out and start building again.
State-of-the-bot so far:

It’s basically an old Apple Airport shell on Roomba wheels. The undercarriage is the wall-mount bracket and the wheels are attached by an axle made out of ShapeLock.

Here’s a close-up of the wheel mount being made:

I formed some ShapeLock around long screwed inserted into a screwhole on the wheel assembly. While I was waiting for that to harden, I softened up another chunk and pressed it into the yellow form(really the bottom of a little parts bin) and then melded the two together on the yellow form after heating them both up a second time just enough to where they’d stick to each other.

I haven’t settled on a CPU or motor controller yet but am leaning towards something Arduino based. More details as I get work done on it.

“D for damage with the ‘dillo behavior, with the ‘dillo behavior, with the ‘dillo behavior…”

After the last post I had an awesome 3 weeks in Malawi and then life went crazy with a new job and a whole bunch of other stuff. In one way or another I have been going solidly almost since I stepped foot off the plane at the end of last summer.

So this blog got turfed and that, as they say, is that. Which is kind of sad because a lot of what’s kept me busy has been really cool and, as it says in the “About” page, half the fun is the doing and the other half is the telling. Hopefully there are 1 or 3 of you still out there to tell.

So, I’m here in Malawi to work on a wireless networking project. I just got here today after almost 48 hours of travel, so, at the moment all I have to show for the trip is a bunch of pictures documenting the flights over. The flight from IAD to JNB(stopping briefly in DKR for fuel) was the longest, but for true geeky plane-spotting swottage, it’s hard to beat flying into BLZ on the South African Star-Alliance logo-ed 737 from JNB.

N.B., this post is being sent via a connection we set up from the College of Medicine in Blantyre, Malawi, to the COM Guest House just over the hill. Antenna pointing was done using the diagnostics from a Ubiquiti Powerstation 2 and a SWAG-optimized antenna-pointing algorithm.

I was out near SFO Friday afternoon last week and took some time to hang out @ the park there along Old Bayshore Hwy. The cool thing about it is that the park stretches from just short of the McDonnell Rd. gates to about a mile down the road, so the paths sit right in the corner there between 1L/R and 28L/R. I happened to hit it at “magic hour”, i.e. around 14:00, when all the Europe and Asia-bound flights are taking off. There was this parade of 747s and 777s landing and taking off for about 45 minutes. I know I saw UA 900, the SFO->FRA flight and there was a Lufthansa 744 not too far behind it.

I really am trying to post here more than once a month, really…

So Sun Labs and the Santa Clara chapter of IEEE RAS had a small “SPOTcamp” yesterday morning where people could come down to CMU West with their SunSPOTs or buy a set if they didn’t have one and work through some demos and HOWTOs or generally hack about on SunSPOTs.

It was only about half a day, from 8:30 ’till 13:30 or so, but I had fun, and, more importantly, got to poke at the guys from SunSPOTWorld in person and grill them about some bugs I was seeing, questions I had, etc.

I upgraded to the latest SDK, “blue”, which appears to have solved a number of bugs, including some UART and Solarium annoyances. I brought the ‘bot and with minor tinkering got one of the demo apps working with it to control the camera servo. The basic idea is that you breadboard up a circuit to control a servo with one ‘SPOT and a flex sensor with the other and the ‘SPOT with the flex sensor sends the resistance values it’s seeing wirelessly to the servo SPOT, telling it how to control the servo.
The picture up top is of the setup. YouTube video is here

There’s so much cool robot stuff going on recently, I couldn’t resist a post rolling in a bunch of different things that have really tripped my geek bits, esp. the robotics ones.

This is actually from a few months back, but I just heard about it the other day:
The Yellow Drum Machine is just a way cool freakin’ robot that finds objects, taps on them using stick attached to a servo and then samples the tap.
If it likes what it heard, it beats on it some more with another “drumstick”, playing back the first sample and riffing off it. I really want to build one…

I took some neat pictures of the first ever Pleo/OrbSWARM encounter at RoboGames 2008. No small robotic dinosaurs were harmed during the event.

I went and saw WALL-E last night at a midnight showing with a bunch of other local robogeeks and came away totally impressed, charmed and overwhelmed with the kyoooot. You really should go see it. This time, in addition to maintaining their excellence in story and visuals, they really managed to get the characters to emote convincingly. In fact it probably took a movie like this to accomplish that because there’s little actual dialog in it. I’m betting the screenplay probably reads rather like the one for 2001 since there isn’t a really line of dialog in either movie for the first 20-40 minutes or so.

Anyway, you should go see it.

Finally, somebody over on RobotStockNews discovered this video by Mr. Pitiful
which has sort of a Squirrel Nut Zippers swing/klezmer-ish kind of sound to it.

BayCon commissioned me to build a cambot for their BCTV division this year. I took it to BayCon 2008 over the weekend of 5/23-5/26/08. I think it mostly went pretty well. There were a few glitches here and there, but overall I think it did pretty well for a first time out. I’ll post more about that later. This is mostly about the design and construction of the ‘bot.

The hardware platform for this robot is a iRobot Create using the SonarBot software and hardware with a Targus tripod mounted to an acrylic base screwed into the 6/32″ mount points on the Create. I decided to go with a tripod rather than fashion a custom “stalk”-type mount. I did this partially because I thought it would be more stable and not wobble as much as a monopod, but also because I wanted the screw-down mount you get with most tripods. That way I could interchange cameras from the simple 2-servo pan/tilt video-sender I have mounted on it up at the top of the page, to a regular digital camera to something like a Gigapan. While the cambot is based on the Sonarbot platform, there are a few differences/enhancements.

Improved connectors/wiring.
The Sonarbot is a test and development platform, so I made it with the idea that things could be added/removed/cut off and hacked on with impunity. Since the CamBot was commissioned work, it’s essentially a production model robot so I had to make it look as clean as possible. So the wiring has been pretty much reworked. Rather than running wires right into DB9s, I used the Sparkfun DB9 breakout board and soldered some right-angle stripline header to that to provide modular connectors that could be easily (dis)connected.

Remote Control.
I needed a remote so that you could direct the bot around to a photo/video point-of-interest. It got built at the last minute, so it’s the result of a few fevered nights with my soldering iron, a BoArduino a stack of project boards from Radio Shack and a bunch of other components. It works and has a wonderful sort of bespoke quality to it, but it was a real pain to build and has convinced me to start learning an EDA tool like GEDA or Eagle so I can make a board I can stick in a Playstation or Xbox controller for the next version.

Loading/Ballast
Unlike the Sonarbot, the Cambot has an actual payload to carry and balance. Under the weight of the tripod, the acrylic deck would bend at the front and back so I had to figure out some way to support it to prevent stressing the deck and also causing the camera(and image it sent back) from flexing and rocking while the robot moved.

I used the cargobay tailgate from another Create and stacked it on top of the one already in place on the CamBot to provide support and ballast in the back. If you look closely, you’ll see that the 2nd tailgate fits right underneath the tripod deck and provides a solid place to anchor the rear leg of the tripod.

The front presented a bit of a challenge because any support solution would not only have to support the weight of the tripod and prevent bending/flexing of the deck, but also allow the front bumper to move so the robot could tell when it bumped into something. I played around with a couple ideas and settled on the above solution. I cut some lengths of acrylic rod that were tall enough to support the deck against the weight of the tripod and attached them to the underside of the deck with hook-and-hook velcro. This anchored them solidly in place, but also let the bumper slide under them as it moved. The weight of the tripod provides enough downward pressure on them so they push against the bumper and don’t flop around from only being mounted at one end.

Diagnostic mode.
I wrote some POST code that tests the sonar sensors and other bits on the ‘bot and has a beep and light code to indicate status on its various systems so faults could be easily diagnosed. Normally, I would get at this via attaching a debug cable to the soft UART port on the Sonarbot. This can be expanded to confirm that other peripherals are working on the robot if necessary.

Programming port adapter.
Since the deck of both the Sonarbot and Cambot obscures the Command Module Programming port or at least makes it interesting to access, I made a port adapter to bring the USB B-Female port up above the deck so you can attach a matching USB B-Male cable to the Command Module without having to fish it around underneath into the Programming port.

The tripod itself is mounted to the deck surface with pads of industrial strength hook-and-hook velcro. I’ve been able to quite reliably pick the ‘bot up by the tripod and not have it let go. So the velcro is more than capable of bearing the weight of the ‘bot. In the future, I’d still like some sort of fetters or clamps to lock the tripod feet into place on the deck, while also allowing the tripod itself to be more easily detatched from the robot itself.

Code
Code is coming. It will appear as soon as I’ve cleaned it up a bit and merged it into the SonarBot package. There’s not really a whole lot of difference between the two code-wise and I can see both the POST and remote-control functionality being useful to have in the SonarBot package anyway.

it’s coming. Hopefully after RoboGames.

In the meantime, I realize that this might make me appear to be A. a heathen or B. woefully behind the times, but might I say that Netbeans is the first IDE I’ve actually found I enjoy using, instead of merely tolerating or wanting to immediately hurl against the wall with all possible force ?

Mostly, I think this is because it doesn’t really get in my way. It puts warnings/info/errors in little icons on the side of the main edit pane and only occasionally pops up windows or tooltips and those quickly go away of their own accord instead of staying on top going

“STOP! FORFEND that thou shouldst speakest such vileness to me!! Fix immediately this heap of offal thou hast dumped into mine pristine edit buffer lest I be forced to pull this session over to the side of the road!”

with the correspondingly solitary, helpful and cheery “OK” button just waiting to be clicked on.

Now before anybody says “But that’s how $MY_FAVORITE_IDE does it too! Where have you been for the past 15 years??” I have to say that I was scarred at an early age by some truly horrid CASE tools which set me against anything other than the most minimalist of text editors. Oh, sure I would pop my head up every few years to see if there was anything out there that was better, but I never really fell in with the Church of EMACS and everything else along the way seemed to be a marketing person’s idea of “easy”, which tends to mean “wrap a GUI around it and call it ‘user friendly’, even if it really is just TECO with a toolbar across the top”

Smultron has also been usable, but has it’s own quirks and irritations(mostly around how it manages “projects” of source files) that forced me to write some of the code for the SonarBot in vi so I could actually get it done without (again) wanting to hurl my laptop at the nearest solid object. Me ?—picky about my dev environment ?—naaahh. I just don’t want to have to keep buying new laptops…

I’ve been writing a remote control for the SonarBot/CamBot platform in J2ME for the SunSPOTs and I noticed as I was tapping away at the code this morning that I was actually finding the stuff that NetBeans was doing was helpful. Warnings light up along the side right away when I , say, define a new variable or change the calling parameters of a method, but disappear equally quickly when I’ve finished adding the necessary closing curly-brace or semicolon.

Am I totally going to abandon vi for Netbeans?—no, but I’ll use it when it makes things like programming the SunSPOTs easier than not using it. Which is all I really want from any of my tools. Be helpful, but mostly stay out of my way.