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


A complementary filter for a IMU

I recently talked about getting informations from the FreeIMU board. This gives us raw data from acceleroscope and gyroscope. Both of them can give some informations about the attitude (pitch, roll) of the board, but they both have some flaws, even if they are perfect sensors (which they aren’t):

The gyroscope only gives the rotation speed, so the software has to integrates the value, which means there will most likely have integration errors, and thus a drift.
The accelerometer gives the acceleration + g, so when the device is not moving, we get g, which gives us pitch and roll. But when there is some acceleration, the values can’t be used.
The gyroscope’s drift is mostly slow, whereas there is an acceleration only on short period of times, so we can combine both of those sensors to get the actual attitude.

One usual way to merge them is to use a Kalman filter. It is a very effective way of merging, and the result can be quite incredible. But it is really complicated to understand and implement. The theory behind it assumes the knowledge of physics of the problem, which doesn’t help its complexity. It actually works without this knowledge, so it’s still a possible solution.

Anyway, as I mentioned before, the noise from the gyroscope and from the accelerometer is not a white noise, but has some specific spectrum, and gyroscope and accelerometer’s noises have quite a complementary spectrum, which leads to another possible filter to merge gyroscope and accelerometer informations (it can also filter magnetometer informations actually): It’s called a complementary filter.

The idea is to apply a low-pass filter on accelerometer, since its values are correct only at low frequencies, and add the complementary (ie the sum of the high-pass filter’s transfer function and the one of the low-pass filter is equal to one) on gyroscope’s data. That way, we filter out high frequency noise of the accelerometer, and low frequency noise of the gyroscope.

So, that’s the theory. To implement such a thing, an easy way we’ve chosen is to use an exponential filter: v_{n+1} = v_n*t + x_n*(1-t), where t is a number between 0 and 1. I’ve chosen t = 10/11 for a sensor frequency of 60Hz. The complementary filter is w_n = x_n-v_{n+1}.

Again, to have as simple code as possible, the current implementation doesn’t even use a FQA, which obviously leads to problems on some specific angles. For our bot, this is no problem, since the range of possible pitch and roll are short, we can take care of being in a safe area.

Today, we also got the Kalman filter to work, so we could compare both approaches. Even thoguh Kalman is still working better, the complementary filter is working properly, and should be enough to control the bot properly, at a way lower cpu processing cost.

Pierre-Hugues Husson

First life signs of our board

Yesterday we got our PCB soldered, next step is obviously to test it. First happy thing was that the board didn’t get on fire when powering it on.

We created a new ChibiOS project that will be the base for our code. To do things the proper way, we also made a new board folder, which is specific to our PCB. It specifies all the settings of the various GPIOs on the µC, such as the alternate functions.

One minor problem we hit, is that stm32f4 isn’t supported in the openocd build that is running on lab’s desktops, so we had to build master branch of openocd’s git. Thanks to Sam, that was an easy task. After that, the JTAG just worked out of the box.

Once everything was setup, first functions we’ve tested is powering on/off the red led, and the serial port. Testing them made us realize that the serial port has actually been wired the wrong way, TX on the usual RX pin of the micromatch. Hopefully, we aren’t the only group to have failed on that, so we can use SaMoRa’s serial cable :-) .

Another mistake on the schematics we found out, is that one encoder plug isn’t properly usable: one pin is on a timer, while the other one is on another timer. This is no big problem, since it can easily be done in software, and that it seems really unlikely we’ll use encoder.

Yet another mistake on the PCB, is that the plugs aren’t named, so we need a map to know what function is on what plug.

Anyway, despite the various problems, all the features tested are working, so that’s great news !

Pierre-Hugues Husson

Ball-E’s PCB has been soldered !

Today we received Ball-E’s PCB, and thanks to Alexis P. and Matthieu, it has already been soldered !

It doesn’t appear so, but it’s actually quite huge: about 20cmx10cm , Matthieu’s challenge will be to place it somewhere safe on our robot !

Pierre-Hugues Husson

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

Architecture choices and some theory for Ball-E

Today, we discussed with Alexis and Samuel concerning the architecture of our bot.

First choice to do, is the computing system to use. This leads to the question of the processing power needed by the various algorithms used for the control engineering. We have to search further and test actual code to be sure, but already existing ball bots use low power systems, like Pentium running at 200MHz or microcontrollers, so we are quite confident that a STM32F4 should be enough for our needs, and we need at least a STM32F4 to be able to control 3 motors and receive informations from the rotary encoders.

Another choice is the communication between the Ball-Es, and the communication with other devices, like phones. Our first choices were to use Zigbee to communicate between Ball-Es, and bluetooth to communicate with smartphones. Alexis suggested the use of WiFi, because we will most likely need high bandwidth when setting various parameters of the control. At first sight, I was afraid of the complexity of such a choice, because i thought we would have to implement a TCP/IP/Wifi stack, but there are some smart wifi chips available, which already includes those stacks, and can be talked to with simple protocols like SPI or UART, so we decided to use WiFi instead of Bluetooth for external communication.

Yesterday, Matthieu and me continued to work on the physics of Ball-E. First step we have already partially described is to establish the kinematics of the problem. The part we put here before was wrong, we were working on a case that isn’t general at all: we were asuming the wheel was in the falling plane, which is wrong. Another parameter we forgot was the fact that the angle between the robot and the vertical is not constant… Yes we want our bot to get straight back. So we did again all the maths, with a new parameter, which is the position of the wheel around the axis of the bot. With this new parameter the formulas are getting even more complicated, but we eventually found a relation between the movement of the bot on the ground, the rotation of the wheels, and the change of bot’s pitch.

The second step is to take in account the dynamics of the problem, which is quite similar to a reverse pendulum. Using the theorem of angular momentum, we can find a relation between the velocity of the bot, its acceleration, and the change of angle of the bot. Combining those two relations should give us the commands we need to give to the motors to go the way we want to.

Now is time to get ready for tomorrow’s communication challenge !

Pierre-Hugues Husson