New Version of RTTTL Example

So I spent a few hours today reworking the RTTTL function that Brett Hagman has created (which I got from here), and it was a great example sketch, but it stores the song’s in flash, which is typically fine, unless you have the SD library enabled. I based my RTTTL code in the VDay 2012 project on Brett’s sketch, except it was modified to save everything into a big buffer(and with interrupts).

Now I have removed that buffer, and rewrote it to be a state-based function. Since I’m dealing with many different libraries, I rewrote this to not be interrupt based, so that it is simple to add to existing code. The sketch size is 10650 bytes with all 35 RTTTL ringtones enabled, with only the minimal song enabled, it is 2544 bytes.

Here it is in all its glory. Enjoy!

Edit: I updated it to fix two bugs I found 🙂 Here is a video showing what it sounds like (yes, that is the VDay 2012 video)

My Arduino ran out of RAM!

With the SD card enabled, and a modest size buffer for songs I want to play, when I ran the code on the arduino, it would just keep on resetting.  Very bazaar, I thought it was because of the Tone library conflicting, but it wasn’t! I reduced the song buffer size to 55, and poof, it worked!

Using the avr-size function bundled with Arduino (pointing to the elf file that avrdude generates while compiling), I see the following sections: text = 21840, data = 254, .bss = 1079. The Ram is data + .bss, in this case about 1300. But if you have a 500 byte array, plus other variables within the same function, you have the chance of causing a buffer overflow. You can actually look at the size of the global variables as explained here.

My new general strategy: Monitor ram size with avr-size, make sure my ram usage is below the allowable level in each function I use (and for all functions I’m nested in). I bet this explains why I couldn’t get the Tones working for the controller. Awesome!

I noticed this great video showing someone racing their RC car through the house, with a streaming camera on board that let them see things in real time. Very tempting to get a similar setup for my RC cars… The $300 price tag has me hesitating.

Next Project: Car monitor, here’s a GPS breakout board

This slideshow requires JavaScript.

My next project is going to be the Car monitoring circuit which logs to an SD card, as well as wirelessly broadcasts the information to my controller. The two big new things it will have are this MediaTek 3329 GPS module, and the Motion Plus Gyro.

The store that I purchased this from (for $30), wants to charge $9 for a breakout board for this, which I feel is kind of crazy (with that money, I could add an ATMEGA328 to parse the GPS), so I made a cheap $0.30 breakout board (well components push the board price to 0.50 or 1.00). It has the connections for USART and USB, and I plan to have an RJ45 connector to put this GPS circuit somewhere remote (RJ45 – ethernet connector). Thinking about disguising it in a gum box, but then again, it would be a gum box + ethernet cable coming out of it, so not much of a disguise.

I’ll update the Projects page, but here is the details of the car monitor (which will be similar to my UPC battery backup logging experiment):
– 6 Temp sensors (Engine x 2, Radiator, Transmission, outside, inside)
– GPS (location, speed, time)
– Piezo (maybe alert on high temp?)
– MotionPlus Gyro (sense direction)
– Bluetooth Serial module
– 3.3v system, powered via car battery

I will have the power for the GPS + MotionPlus + BT module controlled using a BSS123 nMOSFET, as explained here. When the car is off (can detect because Alternator pushes battery voltage to around 14.2), it will turn off the non-essential things and enter a sleep mode, where it wakes to determine if it should still sleep. Cars are noisy environments, so I will be using some techniques discussed here to protect the inputs of the ATMEGA328. This project shouldn’t take too long (ha) because most of the framework is there, I just need to add the code to sleep, to use the motionplus, filter the car battery voltage to power my circuit, and to parse the GPS data. Progress!

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).

Having trouble getting remote ADC servo reading thing working

It should be pretty simple. A BT serial module, a servo, and a button. Pretty simple, right? For some reason I can’t get it working, (It being the whole thing).

I got it so that it would send the ADC value, and display it on my controller, but sending NunChuck packets didn’t work. Packet checks out, but it didn’t seem like the remote ATMega328 actually was processing it? Was it a library conflict? I checked the libraries, and there might be a conflict. The software serial library depends on interrupts to function, and if another interrupt is running, it will block them (such as software servo library, or Servo in Arduino). Another thing I realized more, is that the software serial library can only send or receive, it cannot receive while sending.

I tried to eliminate the hardware from the equation. I attempted to hook up the BT Serial modem directly to my USB to TTL adapter… but nada. The bazaar thing was, when I connected the BT serial TX and RX together, it echoed fine (tested by sending chars through BT serial on CPU). Maybe it’s the breadboard?

Moved it to another board, and tried out the BT module by itself. Success. Put in the ATMega with a simple TX/RX serial echo sketch.. Nada. The funny thing is, if I use SW serial on the ATMega, it works! If I send ‘t’, it responds with ‘t’. With ‘test’, it shows ‘tXXX’, where XXX is some random character. This is the limitation of the SW serial library (and my sketch) because I had it receive 1 character, and send it back. When it got the second character, it was still sending the first, so it couldn’t process it. So HW serial doesn’t work, but SW serial does? Maybe its the chip.

I’ve tried reflashing the chip, but it didn’t work…. Till I figured out that I forgot the 16MHz resonator… Doh! I’ll try to get this working tonight, cause I really do enjoy making progress on things…

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!

What to do when your project seems ‘too grand’

http://news.nationalgeographic.com/news/2005/10/1006_051006_pythoneatsgator.html

From the NationalGeographic.com

Just as this snake learned (or didn’t), sometimes you’ve got to realize if what your trying to do is ‘too much’. How do you define too much? It’s subjective, but for me, I notice it when my motivation is loosing steam. I noticed it for my wireless testing project, just as I’m noticing it now. When confronted with it for the wireless testing, I let myself go work on another project. This time I wont.

I think when your motivation is starting to stagnate, it’s a good time to look at your goals from a fresh set of eyes, and ask yourself what is the minimum needed to get this project complete, at least for this revision. And if we look at the recommendations of Fredrick Brooks in The Mythical Man-Month (I linked to a good summary of it), we can see that in most cases, the first design of something should be discarded. The logic being, when you design it the first time, you have no clue what your doing. The second time, you know much more about making ‘thing’, and you can use your experience to make ‘thing’ better.

So instead of switching projects, I’m redefining my goals, to achieve the core set of features needed to get it up and running. I already feel motivated to get this completed!

Brainstorming about Platforms vs Products

I found this really interesting rant about platforms quite inspirational. A short summary is that if your focus is on making products without being concerned about creating a useful API, it will be harder for people to make things that take advantage of your product. Like facebook and farmville. What does this have to do with robotics?

Well, Arduino is a platform (a very successful one). Many many people have written libraries that works with it, which is why I moved to using it over programming in bare C/C++. JeeLabs has a platform, the JeeNode with different ‘Ports’ that use the Arduino platform (platform on a platform). I have noticed that my past projects (and the controller) are just products, not platforms. When creating my original RC controller and car, I had two distinct code bases. But the focus on creating common drivers (to interface directly with the HW), and API functions that handle those drivers, hasn’t been high on my todo list.

I’ve been struggling to create a packetized communication method to communicate between the controller and anything else, mainly because I couldn’t see the big picture. I couldn’t grasp how the pieces fit together, but now I think I can. By organizing things into layers( HW-ATMega328, Arduino 1.0, Driver, API, Program), I can now see how everything fits together, and how I need to organize things like that, which is essentially a platform. My high level programs will interface with this API, which will handle the nitty gritty details.

I think I’m going to organize things, so that all I’ll need to do is to initialize a library, which will contain all of the low level functions for the API. The challenge will be then to just use the API (ie interface functions) to do things. I’m not sure how this will effect the size of the code, but this may be a good way to do things, because then I could more easily use the same code for different projects (like the Ports library for JeeLabs). This seems like the best way forward, and forward I go!