ELECINF344/381

Interactive web site of Télécom ParisTech's ELECINF344/ELECINF381 Robotics and Embedded Systems classes (a.k.a. ROSE, 2012 session).

Categories

Talking to the FreeIMU

So we recently received the FreeIMU board we will be using for our Ball-E.

As we didn’t have our PCBs ready at that moment, I started wiring the FreeIMU board on a STM32F4-Discovery card I could get, which is using the same serie of STM32F4 processors as our final card will. As stronly recommended by Sam, we’re using ChibiOS, which helps quite a lot the development, since all drivers are already available.

The FreeIMU board is a 10-axis unit. We don’t care about pressure, so we only use the magnetometer (HMC-5883) and gyroscope/accelerometer chips(MPU-6050). The gyroscope/accelerometer chip is rather complex and has several really interesting features:

  • The chip has a built-in FIFO module. Basically you configure the device, and then you just read all infos from the FIFO register. It even supports burst reads, so you can make a single I2C read to retrieve all the informations.
  • It has both a master and a slave I2C bus. The slave is obviously the way to get sensors informations to the microcontroller. The master bus is wired to the HMC-5883, so you can set-up the MPU-6050 to read magnetometer values on its own, and then just keep reading the FIFO to get all the infos you need !

We needed the sensors working quickly, so I chose to bypass this I2C master feature, as the MPU-6050 allows us to, and so the current code speaks directly to the HMC-5883 magnetometer.

I hit mainly two problems concerning the retrieval of those datas:

  • The MPU-6050 needs to have its clock source setted before doing anything, while the register address of this choice is high. That was a problem not obvious to find, since the infos available doesn’t seem to mention this problem. What happened was that the chip wasn’t working on first power-on, but after reset it’s working.
  • The FreeIMU board doesn’t have a RESET pin, so it might happen that the chip is in an appropriate state on reboot. It’s especially true because the current code is polling informations from the board, so the I2C bus is always working. This means that a reset was most likely in a middle of a communication. A fix to that problem is to fake the end of the I2C transmission: put SDA up, and toggle SCL enough times (10 times should be enough.)

So now we have a working board to test various filters on the sensors, to get proper positioning information.

Pierre-Hugues Husson

Possibly related posts:

  1. Tutobot: place and route

1 comment to Talking to the FreeIMU