Connecting a Wii nunchuck to Arduino

May 6, 2013

After getting started with the Arduino Uno, in order to get 3-D accelerometer data from the Wii nunchuck and onto the Arduino, you will need the following:
  • a Wii nunchuck: there are some generic non-Nintendo brand nunchucks available for sale for around $6-7 (like this one) but the reviews on those seemed a bit mixed on their longevity. The official one by Nintendo goes for about $18 on Amazon currently, so I ended up buying a used Nintendo brand nunchuck off eBay to try to get the benefits of both.
  • Nunchucky breakout adapter ($3, adafruit) though there are other kinds of nunchuck adapters as well. This is so that you don't have to cut up into the wires of the nunchuck and can just have something to plug it into instead.
The Solarbotics Nunchucky breakout board adapter comes from adafruit in two pieces, like so:



That piece on the right, mine actually came with 6 pins instead of just 4, but you can just snap off 2 of them. GND = ground and 3.3V = power source, while Data = the data coming in off the nunchuck and CLK = a clock for the serial connection. The nunchuck has standard I2C interface, which allows you to read input from the accelerometer inside (x/y/z force), the two buttons, and the joystick (2 axis). Basically even though you hold it in your hand as one device, the nunchuck is actually all these different devices bundled together into one, and the serial connection allows you to read and distinguish the input from different parts of the nunchuck.

Anyway, the pins need to be soldered to the board so that it ends up looking like this:



My Hackbright instructor Christian brought his soldering iron to do this with some lead-free solder that I just bought for $5 at Radioshack. The soldered part lets you plug the 4 pins into the Arduino board with some stability and conductivity for the data to pass through, from A2 to A5 of the Analog pins:



The Wii nunchuck plugs in to the adapter at the bit with the gold bars. The nunchuck's plug comes with  bits on the sides that you can squeeze to release the locking mechanism for plugging/unplugging it:



VERY IMPORTANT NOTE: plug in the nunchuck with the Nintendo logo facing up! There's a plastic bit on the bottom. The adapter will fit in the nunchuck just fine upside down, but this won't match up with the Arduino code because the pins would be all backwards then. I lost a whole afternoon to this, don't repeat my mistake!

From here, you can get the nunchuck library written by Tod E. Kurt. Of the files in the Github repository, you really only need the ones in the WiichuckDemo folder. WiichuckDemo.ino is the file with the example code that you'd want to focus on, while nunchuck_funcs.h is the library of functions you can call from your .ino file to get data off the nunchuck, like whether a particular button has been pressed down.

When you run these files from the Arduino IDE with your nunchuck all plugged in to the Arduino and the Arduino plugged into your computer, this is what you should end up seeing:



Watching that data come in as you wave the nunchuck around is seriously magical! Tod E. Kurt has some extra info in these slides (PDF file) he used for a class (the relevant slides start about halfway through) but what's in this post should be enough to get you set up. The x, y, and z acceleration data should report values from 1-255 with these directions:



Even when you just leave the nunchuck sitting on the table, it will show some values because it's reporting acceleration, not absolute position in space, so even while in a still position, there will be the downward force of gravity acting on it.

For my project, I basically modified the example Wiichuck code so that it would collect data while you held down the big z-button and stop once you let it go. Pressing down the z-button prints out "start", then while you keep that button pressed down, it collects the xyz acceleration vectors, until you let it go, when it prints out "stop". I also added in a timer library to more reliably initiate collecting data every millisecond (Tod Kurt uses a counter variable in the Arduino's loop), though in practice this actually gives readings about every 100ms due to the nunchuck having a sampling rate of about 100Hz.

How I came up with my Hackbright project idea, Open Sesame

The first half of Hackbright is devoted to working through exercises, from building calculators to a movie rating app, but the second half is for building our own personal projects. The Hackbright application asked for our ideas on what we might build for this personal project and I think most of us had mobile apps in mind originally, but we were warned off from that a bit since that would introduce a lot of extra complexity in just setting up.

After that, I was flailing around a bit for a project idea; I had a bunch of different ideas floating around, like a soil moisture monitoring app (for checking up on my plants in the care of my husband back on the east coast while I was at Hackbright in San Francisco), but wasn't super excited about any one idea. I told Christian that I wanted to do something with an Arduino or Raspberry Pi because I'd never worked with electronics at all before and one of things that had put me off computer science originally in high school is that I thought you had to be one of those people who could built computers from scratch.

That isn't true these days, but it seemed like it would be a very useful skill to pick up for projects with real-world physical usefulness (like this Raspberry Pi-powered cat feeder! I should build this for my parents, saddled with my cat that I can sadly never have at my own home due to my husband being allergic to cats). I am a very pragmatic person and while I very much enjoy pretty things (Pinterest, design/fashion blogs, etc.), I like cooking because I like eating, I like knitting/sewing for the creations that you end up with at the end, etc.--so for me, it's less about the process than about the end result being useful in some way.

I also told Christian that when it came to programming, the bit that I liked best was breaking down a problem to figuring out the solution, and he intuited that once I had proof-of-concept that it would work, I wasn't much interested in implementing the extra stuff, so I wasn't going to be too interested in something that was very front end heavy and require a lot of wrangling with HTML/CSS and such.

Given all that, he gave me this paper published in 2009 by from computer scientists at Rice University called uWave: Accelerometer-based personalized gesture recognition and its applications. It was a bit tough to read through at first but I got to the section on practical applications for it on the same day that a Hackbright classmate gave a talk on 2-factor authentication and a light bulb went off that what the paper was talking about, 3-D motion-based passwords, would save me from the pain of 2-factor authentication!

We have to use 2-factor authentication at work and I've gotten stuck a number of times because I left my phone or forgot the device that gives that 2nd factor. Motion-based password would be something that's pretty easy for you to remember, but pretty hard for someone else to replicate exactly even if they had watched you do it because your hand movements will vary enough that the authentication system should reject them.

So in summary, I wanted a project that had:
  • hardware
  • a clear real-world use
  • more backend than frontend
...and I ended up making a 3-D password system! Pretty cool, huh? I decided to call it "Open Sesame" since that would make it obvious that it's related to passwords, though a couple others suggested calling it Alohomora as a Harry Potter reference--I will have to come up with a Harry Potter-themed name for my next project.

Anyway, I'll be writing a series of tutorials on how I did the project in the hopes that it will be helpful for future Hackbright students or other beginners to electronics projects.