Controller 2.0 – Control, is complete. Now to make compatable things to control :P

This slideshow requires JavaScript.

So here it is, fully built. I went through 2 of the $0.24 cases until I found an arrangement that worked the best. I originally planned to have the LCD on the top, but if I did that, it would be really hard to get it low enough, and to have all of the connectors connected. Notice the extensive use of wire-wrapping, it is awesome!

When I built the boards, i did it slowly, checking my work to make sure I didn’t accidentally short things (a few times I did). Once everything was soldered down, I did a sanity check: Are power, ground connected to the right pins? Are two pins right next to each other shorted? (I did that check with every socket and connector, since that is where that happens. As a consequence, when I first powered everything up, it worked. Everything worked. Another good point, that many can miss, is that I used all new parts, so my original prototype is still here and works as well.

Having that prototype there to compare wiring really helped me in building this, since it showed me errors in the schematic that I made (I corrected them, but still need to make a ‘final’ schematic in Kicad).

So what does it do? As of now, it doesn’t Control anything, but that is the next step. I will create a little arduino project that measures a voltage, displays it on the Control LCD, and turns a servo based on Nunchuck feedback on the Controller. Some pretty simple stuff, just to show off the features of making things packetized. That will get me into temperature measuring for my cars, as well as RC car control.


LCD controller functioning, halfway built

This slideshow requires JavaScript.

So I have made some progress! I brainstormed on how my wireless system will work, and I have come up with something that works. I created a packet that contains a checksum, like this (without commas though, and replaced by bytes 0x0A and 0x0D): ,Dest,Sender,type,Num of bytes,,Checksum,. First I got this basic packet working, then, using that packet, I created different types (3 so far).

The end result, is that I can send the equivilant of lcd.setCursor(X,Y); lcd.print(“String here”);, in one single packet! And it looks like this: 0x0A,e,d,0x02,0x06,0x00,0x00,test,0xCA,0x0D. I can send Nunchuck packets too! (containing state of all things), which means that with this basic system, I can already start making a RC Arduino for my Slash RC car. I decided to start actually making the controller though, since it is pretty complete.

For the actual controller, I will have 2 protoboards, LCD, XBee, BT serial, Piezo, SD card, Nunchuck connector, PS2 connector, and buttons. (I also was successful in using the 74LS164N to drive the LCD only using 2 pins). With the added packet processing code, I’m sitting at 24448 bytes, so it is getting tighter.

Another project in the works, is making a portable programmer, that lets you flash different hex files out in the field, away from the computer. It would have a LCD with SD card so that you can choose which one you want to flash. The immediate usages for it is if I want to use the PS2 controller instead of the Nunchuck (since the PS2 code takes more space). Ultimately i will be able to flash anything, just by connecting a cable from my flasher to it. Pretty awesome in my books, and currently, there isn’t anything like it. I should be able to test the concept with the controller I’m making, having already made the modifications to the FTDI port. Stay tuned for updates!

All controller functions functional! Now I need some remote projects!

This slideshow requires JavaScript.

So I have gotten to a point at which everything for the controller works. SD card, Xbee, BT serial, Shift LCD, PS2, and NunChuck. Pretty awesome. But if all of that code is enabled at once, I would have less than 1k bytes to write actual code to interface with things. In the code I have debugging via serial, debugging via LCD (for the controllers). I do like having debugging for LCD, but there is a problem: the PS2 library takes up 5k bytes. So when I actually build the controller, I don’t think I’ll include a PS2 connector, at least initially.

Breakdown of Sizes
with SD enabled
Everything Enabled: 29024 Bytes
Only LCD debug: 27252 Bytes
Only NUN LCD debug, PS2 disabled: 22550
Only PS2 LCD debug, NUN disabled: 25900
Only PS2 & Nun, no debug: 24690
Only PS2, no debug: 24484
No ps2 or Nun: 20972
With SD disabled
Nun and PS2 disabled:13488
BT disabled + SD + NUN PS2
Xbee: 11910
Everything Disabled:
11886 bytes

I think the optimal configuration would be to use the Nunchuck with LCD debugging information, with SD, XBEE and BT, coming at a total of 22550 bytes, giving me about 7.5k to write my code for all of my interfaced devices.

This has led me to the idea, that my interfaced devices should be giving the controller, the menus it should show. I’m thinking of an initial packet that is exchanged between the two, which has a good amount of strings, that are then saved into flash on the controller, and once data starts arriving, those ‘labels’ of the data will make the data make sense. Another idea is to use the SD card to carry firmware for remote projects, and remotely flash them using the controller on the go, so I can update code for my cars without having to take my laptop down there.

Well here it is:

Continue reading

Finally got XBee, BT Serial, and menu system working… oh and Nunchucks too!

This slideshow requires JavaScript.

Last night I discovered that the software serial library can’t really keep up with what I was trying to do (configuring one module, then configuring the other). I’m sure it was something wrong with my code, but eh. Another thing I discovered was how the Arduino uses 1k resistors to buffer the FTDI connector from anything that may be connected via the serial pins. Using 1k resistors on non-dominant pins, can let you manually choose a dominant port, such as the FTDI. Why would you need to do this? Well if you have the XBee on the Hardware serial, as well as your FTDI connector, you may have some problems downloading (I did).

So I moved the XBee to Hardware serial, with 1k resistors for both TX and RX, which means that I need to disconnect the FTDI connector if I want to use the XBee, which is pretty reasonable (much better than disconnecting the xbee). Once I got that working, I had a menu system that fully let me issue configuration commands, from within it. I do need to do some tweaking on it, but it is good enough to start working on other things. Things like a NunChuck.

I spent quite a few hours tonight bashing my head trying to get this to work. I referenced this diagram, which appears correct. I didn’t realize that it was backwards until I noticed this very helpful post. The diagram shown originally, was for the socket that the NunChuck plugs into, which isn’t what I was connecting to. So once I got that working, I was able to run this sketch, which shows the address of all i2c things on the bus. It was able to detect my MotionPlus and NunChuck knockoffs with ease 🙂 I’d like to also mention that I’m using 2.2K pullups on the CLK and DATA lines for the i2c bus.

So now that I have the NunChuck working, I’m going to make a little menu for it perhaps, or play with it even more, to understand how it works better. I should be receiving parts in the next few days, so the actual controller may be built.  I do realize that this will be a first version of it, but I intend to make it awesome!


Nunchuck Library, from here.

i2C scanner code

Continue reading

XBee and BTM-182 configured via Arduino

I finally got my Ardunio to successfully configure both the XBee and this BTM-182 bluetooth serial module. Why would you want to do that? Well the XBee has six 10-bit resolution Analog to Digital Converter channels, and about 8 digital IO channels (all ADC channels double as DIO channels, so in total about 8 to play with). Another reason is if you want to only talk to one remote xbee module rather than them all, you could change it on the fly. For the bluetooth module, you can perform scanning of available BT things, and connect to them, all using the ‘Command’ mode.

This is another lesson for KISS I think, since when I first started to tackle this problem, I made these fancy functions to handle it. Well that didn’t work at first, but after some massaging, I got it working. Then I tried to get software serial working, but that didn’t work out. (I thought I configured it correctly, turns out I needed to declare inputs/outputs for the SW serial port)

Ultimately I decided to try the simplest while loop to handle the response, which worked out really well. I found out how to get the SW serial working by looking at this example which had SW serial running (the default examples in Arduino 1.0 IDE didn’t setup the input/output). I’ve attached the code below, it’s not pretty, but sharing is caring 😛

What you see in the picture are two NunChucks that I intend to get setup and running, and once they are running, I can send the joystick response anywhere 😛 Once I get some parts in for the controller, I’ll go ahead and build it up. Then something to interface with (plant waterer). Fun times!!!

Continue reading

Wire wrapping is one tool that should always be in your toolbox

This slideshow requires JavaScript.

I see so many people reaching for the soldering iron to make simple cables, when one of the simplest, and strongest, ways of joining two metal posts, is by wire wrapping.  Wire wrapping is a technique of wrapping the bare conductor of a wire around a metal post and has been in use for over 50 years.  It is used extensively in avionics and the space industry for its superior ability to handle vibrations and stresses.  A simple wire wrapping tool can be picked up at a local Radio Shack, as well as a spool of wire wrapping wire (cheapest place for both that I have found).  Here is an interesting PDF on the history of it, and why you should consider learning more about this easy way of making solderless connections.

That in itself deserves a post, but I’ve discovered what I’ll be working on for the next few weeks: Ultimate Wireless Showdown!  I’ll be putting 6 wireless modules through a gauntlet of tests to try to determine which has the best bang for the buck, when it comes to wireless transmission of data using an Arduino/ATMEGA328.  I’ll be testing the XBee Pro Series 1 60mW, XBee Series 1 1mW, RFM12B, Bluetooth Serial, nRF24L01+, and RF2400P modules.

I have outlined the test setup here, so read up on it if your interested, or on any of the other projects I have in the works.  By actually comparing these modules in real world situations, I’ll be able to see which module I should base my future robotic projects on.  So tomorrow I’ll start to get the two boards assembled, sporting a lovely 3.3V LCD and microSD card, with a few buttons for fun.  Which is why I felt it was necessary to improve my serial cables, as shown in the pictures 🙂  Future, here I come!