R7 Project

So the latest project is starting off picking up pretty much where the R6v2 ended up.  After the relative success of R6 the v2 sported a sleek new head, the very cool TPA081 from Devantech and the CMUCam2.  It never got past the initial testing before wanting move beyond the Atom Pro micro and the desire to make a GPS guided outdoor bot.  The Netburner project started off great but lack of base and a good controller board prove too much for the latest collapse.

The R6 base was the best yest.  Two decks, good motors (with as yet unused encoders) a hefty power source (at least until this near disaster) and a sensor rich tilt head.  The v2 iteration added a great brushed aluminum head and the CMUCam2 but the project was abandoned shortly after.

So this project is cleverly named R7 (I don't think the Netburner project was ever given an R number designation, it was a disembodied brain only).  It will reuse the entire R6 base, including the v2 head.  But is will sport an new brain, the arduino based BotBoarduino board from lynxmotion. It's basically an implementation of the arduino ATMega328 on my beloved BotBoard.

Since the base will be no different than R6 and the great head has yet to be used to it's potential I think I'll start off working on the head behaviors first.  Once again the highest goal of the robot will be to seek out people and interact with them.  The head will play a big part in this.  The base navigation will mostly be used to find someone using the TPA and camera based motion detection.  The movement of the head will let the person know the robot is interacting.  That and it's native language of beeps and tones.

Robots Return

Dusted off the Robot Room.  Well actually it was a couple days of cleaning and organizing but the lab is looking better than ever.  Upgraded the PC and monitor too!  Sifting through the bins of raw parts and components memories slowing come back to me.  But like always, only memories.  The technical details will come back more gradually.  For now the decade old documents will get me started.  Most things seemed to have survived the five year hiatus.  I was for sometime convinces the robot would not come back, lost to the effects of lamictal et al.  When we began cleaning for dad coming it spilled over into the work room and after a quick bird feeder, started on the layers of electronic treasures.
So with a new board in hand and a half finished R6v2 I set off on another robot build and all that comes with it.  Brace yourselves, robots are coming.

The connector problem

One real drawback with the development board is the lack of connectors. A board designed for a hobby robot controller needs lots of well designed connectors for hooking up sensors, servos and other peripherals.
The Handyboard used a female header that was nice because the layout was such that you could make connectors that couldn't be plugged in backwards, like this.
So far my favorite is the Atom Bot Board from Lynxmotion. It has three pin male headers separated into groups of four. Each group can be tied to either 5v or battery voltage, so you can use them for sensors and R/C servos. It has a built in buzzer and leds too. There is a 5v linear regulator that provides adequate power for small projects.
In order to get the Netburner MOD5213 connected to the outside world I need to make some connectors. One choice would be to simply toss the dev board and design a new board from the ground up. Without ruling that out completely, let me think about this for a second.
The dev board offers a few goodies of its own that I'd be giving up. It has two RS-232 standard connectors tied to two of the MOD5213's three UARTS. There are pull-ups for the i2c bus, a real-time clock, four LED's and a 3.3v linear regulator too. If there's a way I can use all this and still add all the connectors and things necessary for the robot, I want to do it.
Well, there's a small prototyping area on dev board, I suppose I could use that. But point-to-point wiring connectors, regulators and level shifters, even if it would all fit, won't do. Something a little more permanent (and elegant) is required.
So I've decided to go with a small daughter card that would plug into the the dev board. That way, I can continue to use the dev board and all it's goodies to develop code on a stable, tested platform and have all the connectors, regulators and level shifters on a separate board.
There are two (unstuffed) headers on the dev board that connect to all 40 of the MOD5213 pins. I soldered female headers into each to receive the daughter card. These headers also make nice plugs for prototyping circuits. The card itself is being designed with ExpressPCB. More details and the current design file are on the Robot Room website.

Servos and more...

I found some code from the Netburner forum for sending R/C servo pulses. It uses the Gerneral Purpose Timers to send the pulses. Once the timers are initialized all the work is done in an interrupt service routine. There are four GPT channels so there are four R/C servo channels available.
The Sabertooth motor controller can use R/C pulses as input, so having the servo code working allows me to test that as well. The only real question was whether or not the Sabertooth would accept the 3.3v pulses. Since the MOD5213 is a 3.3v device all output voltages are 3.3v. I hooked up the motor controller using a few jumpers and booted the Netburner.
To test it I just used the routines from the R/C code to change the pulse widths using a terminal emulator connected to serial port 0. After a few presses of the '+' key the 'bot lurched forward. A few '-' and it crept back. Awesome!

GPS is Working

Implementing a NMEA parser to read GPS data proved to be easier than expected. Turns out there's lots of code out there and getting it to work with the Netburner controller was effortless (almost).
Using a standard language like C/C++ is such an advantage when it comes to reusing code. The parser I used was a C++ class originally compliled in an MS Windows environment. Just one change to the headers (which was not standard) and the code compiled in the Dev C++ environment for the Netburner MOD5213. Trying to get this to work in a proprietary language (like the BASIC compilers that are everywhere thanks to the "Stamp" controllers) would have been lots of work.
Having saved a ton of time on the code, I figured I should do something stupid so I could waste a few days trying to figure it out. Turns out the MOD5213 and the GPS are both 'DCE' RS-232 devices so a Null Modem adapter was needed. Sorry, but that just didn't occur to me. A trip to Radio Shack solved the problem.
Anyway, the controller is working great with the GPS now. The parser runs as a separate task and updates the latitude, longitude, time, etc. Since all the serial I/O is done with interrupts, the GPS parser task is "fire-and-forget".

Robot Room Website

I've created a google pages site for The Robot Room. Project details and resources are available there. Updates on progress will still be tracked here, as well as ideas, comments or questions.

The current controller project is at http://drewweng.googlepages.com/newcontrollerproject

Netburner Dev Kit

The Netburner dev kit arrived today and after some software installation (it actually quizes you to see if you remember the license agreement.!.) and a com port configuration I compiled and downloaded my first test app.

It's good to be working in C again...semicolons are back!!!!

The MOD5213 has a boot monitor that can be accessed at start up. A terminal program (one is included in the dev kit.) connected to UART0 on the dev board is used to access the monitor. There is a delay (5 sec is the default) during which sending an 'A' (<- note it's case sensitive) will start the monitor. Allowing the timeout to expire will start your code which means you have to wait for the monitor to timeout out before your code will run. Luckily, it's easy to lower the time out. You do this under 'Setup' ( <- note the menu isn't case sensitive). I set mine to 3 seconds. If this starts to seems too long I need to cut back on the caffeine...

The dev board offers a few things to play with strait away. There are four leds and a putleds() function that sets the leds to the last four bits of its int parameter. It's nice since I got the mandatory led flasher test app working without even knowing which pins the leds are connected to.

That's a good sign, since one of the decision criteria for the new board was a good support lib. Just by starting a new project all the required include files for the RTOS, serial output (interrupt driven), etc. was created by the IDE. The putsleds() function is in a header called utils that is not added to the project by default. Having all that stuff working out of the gate is huge... Networking in a day... I get it!

Now let's try out the I2C real-time clock to see if using the i2c bus is just as easy...