Monday, 29 October 2012

Triple axis accelerometer and gyro - MPU-6050

I splurged some hard-earned Amazon vouchers on toys this month, including a motion sensing break-out board from Sparkfun (via Proto-PIC in the UK).

The MPU-6050 chip is made by Invensense and its blurb says:

The MPU-6050 incorporates InvenSense’s MotionFusion™ and run-time calibration firmware that enables manufacturers to eliminate the costly and complex selection, qualification, and system level integration of discrete devices in motion-enabled products, and guarantees that sensor fusion algorithms and calibration procedures deliver optimal performance for consumers.
Basically this means the chip has some fairly sophisticated processing on-board that handles things like sensor fusion. It does some useful stuff like calculating the overall direction of motion regardless of the chip's own rotation - this saves a lot of heavy floating-point calculations, which is good for integrating with Arduino and microcontroller systems. The accelerometer data can be read using an I2C bus (the linky is a library that builds on the Arduino Wire lib)

The breakout board is fairly simple to use - connect VDD to +3V3, GND to ground (duh) and the I2C pins (SDA and SCL) to the microcontroller I2C pins (A4 and A5 for most Arduinos/ATMEGA chips). The one 'gotcha' I found was that VIO needs to be connected to a reference voltage for the I2C logic to work... connecting this up to +3V3 seemed to work OK for me.

A note of caution - the chip is a 3V3 (3.3V) device so use a level shifter (or voltage divider) if using a 5V microcontroller... I'm using an Arduino mini pro 3V3 and a 3V3 FTDI USB to serial board for uploading sketches. Here's my test rig:

The rig is running off a LiPo battery on the right. The red board is the MPU-6050 accelerometer, the blue board is an Arduino Mini Pro and on the left is a graphical LCD from Adafruit (with a funky RGB backlight). The display is showing acceleration (in x, y and z) on the top row and rotation angle underneath. The circles show the amount of acceleration in each axis (bigger = more).

Software for the Arduino was acquired from here for the MPU-6050 and here for the graphical LCD . A few bodges and Pritstick code let me grab data from the MPU-6050 and push it onto the display. Note that the graphics code slows the whole system down to around 5-10 Hz. The serial only demos are much faster!

What next? Well, aside from building a balancing robot, I'm going to try to make an inertial navigation system... we'll see if its worth reporting on!

Thursday, 25 October 2012

Remote weather station using Raspberry Pi and Arduino

To make the weather station actually useful, the sensors need to go outside. Running a cable to the Raspberry Pi wasn't a good option, so I dug out a pair of XRF serial radio modules to handle sending the weather data over wireless.

An ATMEGA328 chip is used to run Arduino code that pulls raw data from the sensors and pushes the processed weather data over the serial radio link.

Outdoors module for the weather station

The ATMEGA chip sits on a custom board (actually its an Arduino shield prototyping board) that includes a power regulator for the 3V3 rail (for the XRF and sensors) and breaks out headers for the XRF module and sensors. At the moment its connected up with jumper cables, but the intent is to remote the sensors in a box that can have free air movement, whilst the processor, radio and battery sit in a snug, dry box.

The weather data comes from a BMP085 temperature and pressure sensor, a humidity sensor and a light-dependent resistor. More sensors (rain gauge, wind speed and direction) can be added with some code mods.

At the moment the system is mains powered; there is a battery holder for 1xAA rechargeable. The intent was to use a solar source to top up the battery and to use a buck booster to raise the 1.2V battery output to 5V for the ATMEGA chip. Battery life without solar top-up is around 5 hours... not good for the UK in winter! I'm using a low-power mode that only fires up the ATMEGA chip every 8 seconds (using the watchdog timer function) - the system waits 5 minutes between transmitting data. This is an attempt to eek out the power, but I think the honking 3V3 regulator and always-on-XRF are sapping the battery juice. I intend to play with a LiPo battery to see if we can get better performance... the original design intent allowed an output pin from the ATMEGA to drive the XRF such that it could be powered up only when needed to send data over the wireless.

Code to follow...