MiMu BLOG

Getting quaternions out of the ArduIMU

My goal today was to get the ArduIMU sending quaternions.  I couldn’t get the official ArduIMU firmware to compile not could I install their software, so I decided to start from scratch.  I knew this would not be a small code project so the first thing to do was to gain an understanding the Arduino IDE, compiler and general coding style.  This was extremely frustrating and I really don’t like the way use of .pde and .ino files.  In the end I decided I would write everything in C++ and used the core libraries as a reference for style.

The core libraries use a pseudo singleton class approach.  A class is name is that of the library with the word “Class” appended (e.g. SPIClass).  The .h file then contains an external reference to an instance of the class named after the library (e.g. SPI).  This object is defined in the library .cpp file.  It is a simple approach that minimises code and results in simple usage at the application level, so I went along with it.

// SPI.h
class SPIClass {
};
extern SPIClass SPI;

</pre>
// SPI.cpp
#include "SPI.h"
SPIClass SPI;

I had already used the MPU-6000 (gyroscope and accelerometer) and HMC5883L (magnetometer) in other projects so getting them working was fairly straight forward.  I don’t know why the HMC5883L I2C address is 0x1E but this works reliably and the expected address 0x3C dosn’t work at all.  It is disappointing that the ArduIMU uses I2C for the HMC5883L and SPI for the MPU-6000 rather than sharing I2C as this wastes 3 I/O!  I started by plotting the individual sensor values in real-time using a C# app I wrote.  It was Immediately obvious that there are communication errors on both the SPI and I2C bus causing random spikes in the data.  I’ve seen these kinds of errors before and suspect it is due to poor electrical design or poor peripheral configuration.  I’m not so impressed with the ArduIMU design and suspect the forma.

Redesigning the ArduIMU PCB and manufacturing our own version in small volumes would defeat the purpose of using a low-cost, off-the-shelf board so we are just going to have to work around these errors.  The spikes are probably going to be an issue for the drum beat detection algorithm Tom and I wrote. Fortunately, these errors would not be too much of an issue for a AHRS algorithm so I wrapped up one of my open-source AHRS algorithms in C++ and went straight for the finishing line.  I was really impressed with how well it worked.  I was previously worried that the 16 MHz 8-bit Arduino would struggle but it was updating the algorithm and sending all data at 100 Hz with around 40% idle time!

The ArduIMU gloves are developing quickly and will soon be able to do everything Imogen’s gloves.  All that remains is to…

• Calibrated the gyroscope, accelerometer and magnetometer
• Got the RGB LED and vibration motor working
• Work with Tom to integrate the ArduIMU gloves with Glover