Fixed the Processing sketch that attempts to measure distances based on acceleration. (It was off by a factor of 10. Guess who didn’t convert from g to m/s^2.) Anyhow, instead of compensating for tilting in code, I built a rail:
Of course, this doesn’t mean I might not have to take the orientation into account at some point. Still, with the rail I can roughly measure the moved distance as the change in acceleration happens almost exclusively on the x axis.
Drifting is quite bad, though. I’ve got a good 15cm of travel on the rail and measuring movement that’s done right after the measurement starts (within a couple of seconds) seems accurate within +/- 1 cm. But when measuring a completely stationary sensor over a time of 30 seconds, the measurement may have wandered off even beyond 40cm. Currently, I’m fresh out of ideas on how to counter this.
I figured that building a data glove that can track the hands position in 3D space may be quite difficult measuring the accelration of the glove alone. Because the MPU-6050 is able to produce orientation data (as a quaternion), one could of course track the hands position from the shoulder on onward. The shoulder would be a “fixed point” with a ball joint. Having sensors on the upper and fore arm measuring the direction where the arm is pointing to (and knowing one’s arm’s length), one could calculate the location of the hand in relation to the shoulder. It’s not ideal for motion capturing either since the shoulder is capeable of subtle movements, but I think it might be the way to go.
After connecting the MPU-6050 again to an Arduino, initializing the DMP and realizing that the accelrometer data is in *signed* 16-bit integers, I’ve got the following:
- Looks like the default setup is for the 4 g range. That’s very nice.
- The x- and y-axis are fairly precise, but in my case, the z-axis shows slightly less than 0.9 g, when it should be 1.0 g. I wonder if it varies from chip to chip..
I converted the previous demo for the analog accelerometer for the MPU-6050. You can download the thing here. (There are 2 Processing sketches: one showing the 16-bit measurements and one showing those measurements converted to g forces.)
Also: I wrote a Processing sketch that tries to measure a traveled distance based on the accelerometer. It just uses the s = 0.5 a * t^2 + v*t formula. Currently the results are way off. But this is partly, because rotation isn’t taken into account. Tilting the sensor one way causes it to “accelerate” into two directions (because I compare the acceleration to a pre-measured offset). So, there is plenty room for improvement. I uploaded it here. (Use the same sketch for Arduino as in the aforementioned “mpuAccelerometerDemo”.)
Jeff Rowberg has written an excellent library for the MPU-6050. It encapsulates the basic functions and hides all the I2C traffic management. You can download the code directly from github. You’ll need the I2Cdev files and the MPU6050 stuff. Copy the files to Arduino’s workspace’s “libraries” directory (for example “My Documents\Arduino\libraries\“) under directories I2Cdev and MPU6050. If the “libraries” directory doesn’t exist, you need to create it.
Basically there are two ways to use the MPU-6050 with this library: 1) Include the “MPU6050.h” header for all the basic functionality that is also documented by the official Register map or 2) instead include the “MPU6050_6Axis_MotionApps20.h” header to gain access to the reverse engineered DMP (Digital Motion Processor) functionality.
The library’s code is documented in a way from which you can generate a nice HTML documentation using Doxygen. It looks a lot like JavaDoc. (The Doxygen installer puts the Doxygen user’s guide in HTML-format into program’s folder. For example in my case the folder “file:///C:/Program%20Files/doxygen/html/doxygen_usage.html“) In short: To create documentation from the code you’ll need to type two commands from the command line: “doxygen -g configFile” and “doxygen configFile” (replace configFile by name of choice).
That, or you might just look at the readily available MPU-6050.h documentation online.
I think the best (and only) way to explore the DMP-functionality is to examine the Teapot demo. Just upload the example code to an Arduino. When connecting the MPU-6050 to an Arduino, remember also to connect the interrupt signal (INT pin on the MPU-6050 to Arduino Diecimila or UNO’s digital pin 2) as the MPU-6050 with DMP is set up to fire interrupts whenever it has data ready.
To visualize the Teapot on the PC, you’ll need to have Processing installed and copy an additional toxiclibs library into Processing’s workspace’s libraries folder (much like you had to add the MPU’s libaries to the Arduino IDE’s libraries folder). If the folder “Processing\libraries” doesn’t exist, you’ll have to create it. Then save the Teapot demo “MPUTeapot.pde” under “Processing\MPUTeapot” (or the Processing IDE will later ask you to move the file to this directory).
I made a few changes to the MPUTeapot demo as it – in my opinion – didn’t properly catch the data packages sent by the Arduino..
InvenSense also has an official Teapot demo. I tried to run it, but it seems I’m missing a winusb.dll and didn’t really bother to investigate further. It should work though – I’ve seen it on youtube 🙂
As it turned out, the fancy pants dial didn’t cope with negative values very well. It does now. Apparently I didn’t expect to measure negative values.. Also, I’ve uploaded an example about logging stuff into a text file. (Maybe I’ll one day figure out an easier way to do this.)
Made a small Arduino and Processing sketch to display data from an older analog 3-axis accelerometer: the MMA7260Q by Freescale (a spin off company from Motorola). You can download the code here. I tried to keep it as simple as possible.
I’ve wired the accelerometer up to handle 4g, which seems alright for faster hand gestures too. It can be maxed out by very quick hand movement and slapping, though.
Wanted to do this for a while, so here it is. A as-simple-as-can-be dial indicator done with Processing. Feel free to download it if you want. (The code may not be super easy to reuse, but I’ve added comments and some tweaking should be doable, I suppose.)
From concept to implementation.
I’ve done some hobby electronics using primarily through-hole parts, so SMDs (surface mount devices) are somewhat new to me. (I haven’t been paying much attention to them, because I tend to use vero boards or self etched PCBs without solder mask or other fancy things.) Notes-to-self:
- The MPU-6050 comes in a 24-lead QFN package. This sucks, because it will be harder to solder than a QFP package.
- Soldering 0805 packages by hand should be OK
- Pick and place machines should be able to handle down to 0603 packages, but not every machine can do 0402 packages. (Heard this on The Amp Hour, I think.)
- Also, DX sells SMD soldering practice boards. I might try this out…
Here is a pic to demonstrate scale