K9 2013 Mark 1 (Big SHR)
Edit: 2 Dec. 2013-New photo of external USB access added.
As I mentioned with the SDT, today is the 50th Anniversary of Doctor Who's first broadcast. K9 is a robot I've been working on for years in a stop-and-go fashion. I'd run into a design problem, let it sit for a few months, have a brilliant idea, come back to it, get bored... you know the drill. I finally set myself a goal of having something to show today in honor of The Day of the Doctor.
K-9 Mark I differs from SDT in several ways, most notably that its function is totally different. It's now mobile, the thermopile sensor is gone, the PIR sensors and laser are not functional but the sonar is, etc... The only real commonality is the chunk of plastic it's made out of and the servo that moves the head.
Like the original K9, I've always planned development of the unit in four "Mark" stages. Each of these would have enough of a functional difference from its previous iteration to really be considered a separate robot (though I don't intend to send two of them off to Gallifrey or E-space with Leela or Romana. My wife's name is Sarah Jean however, so keeping Mark IV with us seems appropriate.)
This is the most basic version. (I won't go into the planned upgrades for each personality here, opting instead to list each as a separate robot project in its own time. I'll be glad to have Mark IV written up by the 60th Anniversary at this rate.) It's essentially a giant Start Here Robot based on an Arduino Mega 2560 with an ISD1760 Audio Board, an L298D motor controller and a power breakout board.
The audio samples came straight from the BBC website. It took me a couple of tries to get enough level that you could hear his audio cues on the speaker. I went through two different amplifier boards before I just gave up and re-recorded the cues to the chip with normalized files, so now I some extras, but you can always use a cheap Chinese board for something.
There's really no point in sharing the code on this one-it's mostly Pin declarations after all. (EDIT-I did attach a .zip with the full sketch and text file of the pin descriptions for every used pin on the Arduino, whether attached or not at this time.) This is my first time using the Newping library though, and I kind of have a beef with it. For one thing (and not really an issue here) it's pretty big compared to the function I usually use, but I'm not a big fan of the fact that it returns a 0 beyond the maximum (5m) limit of the sensor. When I discovered this problem, I must have fumed for an hour on the exercise bike. "That's gonna send a lot of false obstacles to the loop!" I thought. Of course the solution was simple:
I just am used to a simpler condition at this branch I guess, and I didn't want to change. Incidentally I didn't add the 0 default condition to the ping reads when the unit looks left/right, but I haven't seen any evidence that it resulted in the "wrong choice" (ie, that it caused the unit to head off in the direction of the nearer obstacle. Of course, I didn't test it anywhere that there was more than 5 meters to move around in...) Still, there are lots of methods in Newping that probably don't need to be compiled onto a microcontroller with limited flash RAM.
I'm not terribly happy with the Banebots wheels in tandem with the motors I purchased. They work best on real hardwood floor. On laminant they barely grip, and on carpet they fight to move. I may have to reconsider the layout of the inside as a result for ballast, placing the batteries over the center of the motor axis.
Some may remember DAUGFOETUS, which used the same base that you see above but navigated using an MMA7361 accellerometer. I haven't given up on that (indeed, I think in the video you can see that I need some manner of "stop" detection, if not crash detection.) The problem seems to be that on a larger platform, the accellerometer isn't sensitive enough to use OddBot's method. However, that's not to say that it won't detect whether it's still moving. A simple check for motion on the axis of forward travel in the main loop would be enough to tell the unit that it had "hung up" on the carpet or run into an obstacle outside of the sonar's field of view. A machine at this level isn't likely to attain a steady enough velocity that the accellerometer would read no accelleration while in motion. You could probably log an array of the perpendicular axis reads to see what side an impact or obstacle came from without too much trouble.
As you can see in the video, when the head is close enough to tcome into contact with a wall when it "looks around," it's pretty lightweight and the body will push away rather than stopping the neck. The construction materials are almost all plastic. The body is part of a wastebin and the head and base are made from expanded PVC sheet and pipe (with zip-ties for the "eyes.") The only structural metal is aluminum L-channel used to mount the motors to the base.
So to sum it up, this was a little bit of a rush job, not something I'd normally publish or representative of a step forward in my development, but it is "done" in time to honor a geek institution-The Doctor. Which brings me to a gif I just found yesterday and feel compelled to include here, even though it has a very odd message:
(Please don't. That would be robo-bestialty in a sense.)
December 2 Edit:
I decided I didn't want to open up the unit every time I made a slight adjustment in programming so I put a panel mount USB access in under the "tail" today:
Yeah, maybe it's a little immature. I can't resist thinking of it as a Universal Serial Butthole. But I don't think there was really a better place for it though. Anyway, I'm a married man and I got my wife's permission first so it can't be too bad...