Carduino! It’s Alive!!!

This slideshow requires JavaScript.

Just a re-cap: This is a little project that will be embedded into my car, that logs the temperature of the engine, transmission, radiator, and interior to an SD card. If something gets too hot, it will show the warning led (decimal point) as well as make an audible notification (cue mario dying song). It can connect to my Controller 2.0 via a BTM-182 module, and if connected, it will display all 5 of the measured temperatures, as well as the voltage, on the controller (without needing any parsing by the controller). This will be my early alert system to warn me if something is getting too hot. In the future I may add sensors to detect the level of radiator coolant, but that is a nice-to-have, rather than need-to-have. The code for this, will be released shortly (Once I have this in my car I imagine).

It’s done! I admit, I did run into some problems. When I first powered up the Carduino main board, there seemed to be a short somewhere. I removed a diode, which of course didn’t help. After poking around, I discovered that the connections for the package of voltage regulator were wrong. After a quick rewire, it produced regulated 3.3v. After fixing a few forgot-to-solder’s, and a ‘soldered but didn’t make connection’, it fully works. I do need to do some tweaking of the software, so that it turns off at 12.3v instead of 14.0v (since I’ll be using a switch to turn it on/off).

Exciting times! Now I just need to get this in the car, and I’ll be set! I’ll need to take care of potential moisture in the temperature cable as well, but I’ll figure that out as needed 🙂

Needed features completed for Carduino, all that remains is nice to have features

For this project, I broke up the features into need to haves, and want to haves, with the intention that I could call the project complete once all of the need to haves are complete. I wanted a basic engine monitoring circuit that I can put into my cars, and I have that now.

I even added two shift registers with 8 LEDS and a BCD 8 segment display to compliment it. The purpose would be to display the sensor number, and if it is in a good range or not. I will mount this so that the driver can see it and monitor it. If a temperature or voltage exceeds the threshold in a dangerous way (over temp), It will not only sound an alarm, but light the small decimal point of the BCD so that I know something is up. I need to add sleep code, but that’s about it (and controlling the power rail of the BT serial, SD, GPS, and LEDs with a mosfet).

The remaining want to haves include: GPS and gyro. I don’t anticipate any problems with adding those, even though for both of those, I will be forced to use the SW versions of the protocols (serial, i2c) rather than using the on-board module.

I’m going to be doing some more testing of the alerting code (moving the temperature sensors near an open flame, monitoring temp on controller), but once I do that, I’ll start soldering boards up for it (with connectors for Gyro and GPS for future upgrades) and wiring up my car. I’ll be using the MotionPlus as a gyro, since it is so cheap.

The next two projects I’ll be working on is a Gardening bot, and a arduino for my Traxxas Slash RC car. Might be getting some video equipment so that I can see what the car sees, in real-time. Will also look into updating the OpenCurrent to add some goodies, and making a PCB of my controller, similar to the Ardustation.

I look back at the past 4 months, and I see how doing things, while not perfectly, can accomplish things. If I were too afraid to fail, I would do nothing, as history has shown. Some of the lessons I’ve learned: If it’s too hard, break it down. If your losing motivation, try switching your focus. Record everything in a notebook, writing ideas, no matter how silly. And above all, create rather than consume.

Controller wirelessly controlling servo using BTM 182 BT serial module.

It’s alive! My Arduino controller can control things wirelessly, sending and receiving! It sends Nunchuck ‘packets’, and receives display ‘packets’. I created a basic packet system so that I standardize communication between wireless things. Each packet has a checksum, so if a bad packet is received, it can be discarded. Packets have a ‘type’, which can be things like ‘are you there’, to ‘display this’, or ‘here’s nunchuck data’. The beautiful thing about standards, is that I can use this to quickly roll out wireless things, without having to figure it all out again.

This demo is simple, reading an NTC Thermistor and displaying it on the controllers LCD. The controller sends Nunchuck packets to the ATDservo, and it turns a servo based on the position of the nunchuck joystick. It could easily do anything else, since it received the whole controller output. I also have the code for a PS2 controller, but I have it commented out for now, since the library takes up too much space.

What i plan to do with this, is to make a basic voltage monitoring board to monitor the status of a UPC battery as it discharges. It will save the data to an SD card, maybe making measurements every second. I could do it without anything plugged into it, and with something plugged in. Just a quick little experiment, to show everything working. 🙂

As always, the code is below. I use a simple state machine to process each received packet, and I have another function that handles the different types of packets. And it works 🙂 Someday I may make an PCB based on the Controller, using a singular wireless thing, so that it will be quick and easy to carry the controller with me!

Code for controller

Code for ATDservo

This is why it wasn’t working! BTM-182 output voltage out of Spec!

Determined not to give up, I continued on. The next step I came up with, was to swap BTM-182 modules, since maybe there is something fishy with that one? Swapping them didn’t help. So I thought, maybe its a voltage level issue.

And it was.

Apparently the BTM-182 module outputs a high of 1.4V, whereas the ATMega328 expects at least 0.9*Vcc (2.97) when operating at 3.3V (I’m operating at 3.3V). Apparently it worked with Software Serial because the change was enough to trigger an interrupt. A quick solution will be to set the TX of the BTM-182 module as the base input of a BJT, when high, triggers a pullup on whatever I’m controlling. And I’ll verify that it works, before trying everything out.

So ultimately, this chip, for some reason, output 1.4V as the high instead of 2.9 as expected. Looking at the datasheet, it seems that it believes that it is operating at 1.8V, not 3.3V. Quite strange. Lesson: Fully understand your parts, before you try to start working with them, because things may be go smoothly until you hit an unexplained snag. I hope to not make this mistake again!

The problem of SW serial dropping things will be still present on the controller, so I may need to change the usage of my packets to be more of a ask-give relationship, rather than give, give, get (occasionally).

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: http://pastebin.com/JudSCJNN

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!

Control.ino.

Nunchuck Library, from here.

i2C scanner code

Continue reading