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.
Friday, August 31, 2007
Thursday, August 30, 2007
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!
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".
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".
Sunday, August 19, 2007
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
The current controller project is at http://drewweng.googlepages.com/newcontrollerproject
Thursday, August 16, 2007
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...
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...
Sunday, August 12, 2007
New Robot Controller Project
I've started work on a new robot controller based on the Netburner MOD5213. After lots of searching I settled on the Netburner controller for a few reasons:
- Price for the performance is outstanding. The module is only $39 and sports a 32-bit Coldfire processor with lots of hardware peripherals.
- Development Support. The dev kit includes a controller, board and complete C/C++ compiler and IDE for $99.
- Lib support. The dev kit includes the uC/OS RTOS, libs for interrupt driven SCI, A/D and GPIO support.
- The controller is NOT 5 volt tolerant so a scheme for interfacing 5v sensors will need to be developed (optoisolators or a simple voltage divider come to mind).
- The dev board does not have ready made connectors for external hardware. I have started working on a daughter card that will plug into the dev board to address this.
Sunday, July 29, 2007
The Robot Room

Thought I'd post a picture of where I spend time working on the robot...
It's hardly neat, but lately I've noticed how many things I DO have on hand...3 sizes of shrink tubing... all kinds of cutters and crimpers and strippers...
The one thing I couldn't live without? My Fluke DMM!
An the one thing I jones for most? An Oscilloscope!
Thursday, July 19, 2007
Definate problem with the AE-35 Unit!

Wednesday, July 18, 2007
Subscribe to:
Posts (Atom)