robotguy.net/Blog

I haven’t been working on the Pocketwatch much because I am waiting for the display, and I have been rather nervous about constructing the encoder/switch with my limited mechanical abilities. But tonight I was putting off starting the last Harry Potter book (Don’t tell me! I haven’t read it yet! *fingers in ears* NAH NAH NAH) and I decided to head into the lab and fiddle around. I ended up picking up the pocketwatch and constructing the switch mechanism. It actually turned out rather well, nice and smooth, not wobbly. It still needs finishing, but here it is:

The tiny disc magnet is glued into a slot in the plastic shaft on the left. The bushing is made from a drilled out and turned down 2-56 nylon standoff. Pressing down on the shaft engages the tactile switch with a satisfying *CLICK* and spinning the shaft will cause the hall effect sensors to sense the rotation.

The encoder started as a sketch:

Then Prowler50mil on the Steampunk Tactile forum suggested using one magnet and two hall sensors. Great idea! I built up a demo to try it out:

Lo and behold, it works!

I have been struggling for a while with the lack of user input on the PDA project. I had considered adding an interface through the RF transceiver, but that would mean I would need to be near a PC. I have been unable to find any pushbuttons that I like to install on the face. So I did the next best thing. A sharp sideways tap on the right side of the enclosure brings up a menu, with a small circle next to the selected item:

Tilting the unit in the y direction moves the selection circle, and another tap selects the item. It still needs a bit of tweaking. It seems much easier to tilt in the x direction, because I tilt the unit towards my face when looking at the screen, and that makes the selection circle move down the llist.

Here are links to a few thing I found during my research into tiny user interfaces:

• TiltType: An Accelerometer Based Text Entry Method
• Sensing Techniques for Multi-Device Interfaces (PDF)
  
• Shake Them Up! A Movement Based Pairing Protocol
• Bringing Sketching Tools to Keychain Computers with an Acceleration-Based Interface
• GUI Development: Embedding Graphics Part I Part II
• Variability in Wrist-Tilt Accelerometer Based Gesture Interfaces
• Detecting Freefall with Low-G Accelerometers,Measuring Tilt with Low-G Accelerometers

While waiting for my RF boards to arrive from Sparkfun, I started another project (ooh, look! Something shiny!). I have always liked building things that I could carry around with me, so I decided to build my own PDA. I had the graphic LCD and plenty of processors laying around. I figured adding an RF link back to the PC would not only make it more functional but also help produce code that would be useful for the Spoka project. I also figured that I could combine it with my Tricorder project (notebook pages 3-12) and add as many sensors as I could fit in this little OKW enclosure.

The processor is an ATMega32. I have added a 128 X 64 graphic LCD, a 2.4GHz RF Transceiver, battery-backed real time clock, 2 axis accelerometer, linear Hall effect sensor, and a white led flashlight. The IR receiver is not connected yet. I still plan to add an RGB color sensor and an IR transmitter.

The source code was compiled with WinAVR and is available here. The library for the graphic LCD is from Gregor Horvat (http://www.indata.si/grega/) for the compatible HD61202 controller. After updating a few deprecated commands, it worked first time! I can’t remember where I got the library for the DS1307 clock that I converted for the DS1305. If anyone recognizes it, please let me know. The defines for the NRF24L01 came from S. Brennen Ball.

As you might be able to see from the screenshot, I am currently reading the battery voltage (upper left), magnetic field strength (upper right), x and y acceleration (lower left), and the current time (lower right). The cross-hairs and “bubble” in the center of the screen form a 2-axis level. See the picture of it in my hand for an example with the unit tilted on one axis. The RF transceiver is working well and capable of exchanging data with a PC base unit that connects via serial at 115200 baud.

(BTW, my order arrived from Sparkfun, but I’m having so much fun with this project, I may not get back to Spoka)

OK, so there’s nothing here about hope. I just couldn’t resist the Star Wars reference.

I did however succeed in implementing PWM on the RGB LEDs last night, so I now have 24 bit color for each eye. It turned out to just be a simple interrupt routine. Of course this solution is brute force, and takes up a *!@$load of the processors time (it interrupts every 256 clock cycles). Oh, well. I’ll worry about optimizing it later if I need to. Here’s the interrupt routine if anyone is interested.

ISR(TIMER0_OVF_vect){
if(pwmCounter>rred) LEDPORT|=R_RED;
if(pwmCounter>rgreen) LEDPORT|=R_GREEN;
if(pwmCounter>rblue) LEDPORT|=R_BLUE;
if(pwmCounter>lred) LEDPORT|=L_RED;
if(pwmCounter>lgreen) LEDPORT|=L_GREEN;
if(pwmCounter>lblue) LEDPORT|=L_BLUE;
if(++pwmCounter>254){
pwmCounter=1; //reset counter
LEDPORT&=~(R_RED|R_GREEN|R_BLUE|L_RED|L_GREEN|L_BLUE); //turn off all
}
}

After a tiny bit of playing around with the color scales, I ended up implementing the first one in the list in the previous post, simply because I could do it programmatically, rather than as a large lookup table. I’m not really happy with the map though. I’d bet the linear optimized map or rainbow looks better (check them out with this java applet). Here’s my colormap function:

void scale1(unsigned char value){
if(value<128){
SetRGB((255-(2*value)),2*value,0);
}
if(value==128){
SetRGB(0,254,0);
}
if(value>128){
SetRGB(0,(255-(2*value)),2*value);
}
}

I also ordered a Mirf with a tiny ceramic chip antenna so that it would fit inside the light. Hopefully iy will be here before the weekend, since I’m taking a 4/5 day weekend to work on the project.

I was just realizing that I didn’t put values in for the LED current limiting resistors on the schematic, so I thought I would add a little detail regarding their values and how I chose them. I decided from the start to limit the current through each LED to 15 mA. Each PIN on the AVR can source 40 mA so no problem there, but the entire chip can only source 200 mA total. 7 LEDs X 15 mA = 105 mA. Should be no problem. Plus room to spare when the device is AC powered.

First and easiest was the red. I placed my meter in diode check mode and measured the voltage drop across the LED (Vf) as 1.74V. Measuring the battery output as 3.8V, we get a margin of (3.8-1.74=2.06V) which must be limited to .015A. Dividing the two we get (2.06V/.015A=137Ohms). Putting a 220 and a 330 in parallel gives me (220*330)/(220+330)=132. Close enough.

The blue and green LEDs had too high of a Vf for my meter to read in diode check mode. I knew however that the blue LEDs in the original circuit had a 20 Ohm resistor, so I figured that anything larger should be OK, so I scrounged around and found some 47 Ohm resistors. I soldered these to the LEDs and applied the power, then used the meter to measure the voltage across them. I got 3.16V for the green and 3.07 for the blue.

Green: (3.8V-3.16V=0.64V) (0.64V/0.015A=42 Ohms) Just leave in the 47 Ohms.

Blue: (3.8V-3.07V=.73V) (.73V/.015A=49 Ohms) Again, just leave in the 47 Ohms.

Worst case voltage should be 4.8V when the AC is plugged in. This will give (4.8-1.74)/132= 23mA for the red, (4.8-3.16)/47=35mA for the green, and (4.8-3.07)/47=37mA for the blue. All within the per-pin limit of 40mA. Total output would be (3*23)+(2*35)+(2*37)=213mA. Hmmm, I wouldn’t put out a production unit with numbers like that, but for a hack, it’s not too far off.

I was explaining to my wife the kinds of things I could do with this when it is PC controlled, like changing color according to the speed of a download. This reminded me of an article I saw a while back, “Rainbow LED Indicates Voltage with Color.” This article gives a nice mapping of value to color for the range of 0-255, but it is centered around 128. In other words 128 gives black (all off), <128 gives bluish tints, and >128 gives reddish tints. This might be handy for some things, but not for others. So I did some research on “color scales” and here are a few interesting links:

http://www.ks.uiuc.edu/Research/vmd/current/ug/node76.html

http://www.cs.uml.edu/~haim/ColorCenter/ColorCenterColormaps.htm

(Continued from previous post..)

After removing the LEDs, I marked the outside of the shell to indicate where the eyes and nose were on the rubber cover. Then I modified a small prototyping board to fit into the space, aligning the eyes with the marks made previously. (Notice that the marks are on the same side of the shell as the hole for the plug. Whoops. I had to redo them on the other side)

Then wire the new pcb up, program it and install in the housing for a test (notice my chip-clip programming adapter. It’s handy)…
Red Green Blue White Mouth

I was at Ikea the other day (they just built one in town, so i get to go all the time) and saw a rechargeable nightlight that I thought would be cool with some RGB LEDs. As I was working on the RF link yesterday, I realized that I could make a wireless, pc-controlled RGB LED light. So I headed over and picked up a Spoka from Ikea. This thing is just begging to be hacked. It comes with a 4.8V 400mA wall wart, and an internal 3.6V 550mAh NiMH battery. The silicone rubber outer cover diffuses the light nicely.

Contents Nightlight

Once you get the plastic shell out of the silicone rubber cover (it takes some work), remove the bottom by releasing the tabs on either side. Then split the shell by releasing the tabs at the top (circles), and prying lightly. There are two alignment posts on each side (arrows) that are a snug fit.

After a little circuit tracing, I had the schematic: I should be able to take out the LEDs and place my circuit in the same spot in order to keep the battery/AC/rechargeable portion working.
I am planning 2 RGB LEDs (That’s all I have at the moment) behind the eyes, and a red LED behind the mouth. I’ll use a small AVR (maybe a 2313) and the MirfV2 with a ceramic chip antenna for the RF.

A buddy of mine (Thanks, Peter!) gave me a couple of these motor/wheel combos from HSC Electronic Supply. He said that since they were not geared, they weren’t torquey enough for a robot, but after a little brainstorming, we came up with this application…

Just a little shimming to get the right distance between the wheels so that the ball is grabbed correctly, and ZOOOM! This thing really gets a ping-pong ball moving, hard enough to hurt. For anyone else who want to try this, I am using a 5V power supply, but I am thinking 6V worth of NiCads ought to work well. The motors in parallel pull 4 amps on startup and about 1.5 amps no-load. They are quite loud as you can hear in the video, so don’t plan to sneak up on anyone.

I am thinking a tube for auto feed, a solenoid to press the ball into the wheels, a few ping pong balls, a motor controller on each side to allow for spin, and this thing could be really cool.

Here’s my new blog, blah, blah. We’ll see how often it gets updated. The new WordPress online interface should help with that though.

Hack A Day is having a design challenge/contest so I decided throw my hat in the ring. Since the management at my work put the kibosh on lunchtime BZFlag, those of us who are adolescent-at-heart have been looking for a new game to play that doesn’t involve the company network. I came up with the idea of “Cubicle Tag”, where everyone wears a small PCB with an IR transmitter and receiver. One board is designated as “it’ and beeps or flashes, something annoying to make you not want to be “it” anymore. Pressing a button on the board will send an IR signal, which will set a receiving board to be “it”. So it’s kind of like laser tag, but less laser and more tag.

Here is a preview of the PCB.