Quaternion IMU Drift Compensation: Magnetometer

  One of the most important sensors on a vehicle that needs to navigate between physical locations is a magnetometer.  Like a person who uses a compass for land navigation, the magnetometer provides a static reference toward magnetic north allowing for movement in a desired direction.  The information from this sensor comes in the the form of 3 orthogonal values that give a representation of the magnetic field surrounding it.  In the following post I will explain its benefits, its challenges and how I use it in my complementary filter.

Quaternion IMU Drift Compensation: Accelerometer

  I will now explain how I perform gyro drift compensation in the pitch and roll directions using the output of an accelerometer.  In a future post I will discuss using a magnetometer to counter gyro drift in the yaw direction.  Before going into the theory and math, here's a quick overview of what an accelerometer is.

Fast Quaternion Integration for Attitude Estimation

  One of the central challenges in creating a flying machine control system is attitude estimation.  The better the estimate, more correctly the control system can make flight adjustments.  The better theses adjustments are, the better the aircraft can go where it's supposed to go or stay where it is wanted.
  I will be writing a series of blog posts that go into detail describing how I have chosen to design my IMU complementary filter for attitude estimation.  Each post will introduce a new sensor and explain how I use it to enhance the output of my system.  To begin with I will start with the gyroscope.

MIOS: Multi-Copter I/O Shield for the Arduino Due

  As I previewed in my last post,  I am making an shield to fit the Arduino Due that will simplify connecting the RC reciever, motor ESC, and I/O for sensor communication.  The PCB's for the shield came this week and below are pictures and some explanations.

Quadcopter Inertial Position Tracking

  Although I am sure I will enjoy every aspect of building this quadcopter,  it is the Inertial Position Tracking (IPT) feature that I'm most excited about.

  In a traditional small quadcopter, there is no ability for it to track its own current position internally.  The flyer moves the controls and the 'copter moves in what ever direction is requested.  Once the flyer stops giving the aircraft commands, it will attempt to stay in one position.  The challenge a "dumb" quadcopter like this has is that since it doesn't know where it is, it won't be very good at staying in one position.  If a gust of wind blows it away, it will react to attempt to stop moving, but it won't really know how far to go to get back to where it was before the wind came.

  This is where the IPT system comes in.  In simple terms, it uses the readings from the 3 axis accelerometer and readings from the three axis gyro to detect how the quadcopter is moving.  Using some math, it then figures out how far it thinks the 'copter has moved since the last time it did it's calculations.  It then "adds" this very small bit of movement to it's last position to figure out where it is in relation to a reference point.  To begin with, I will make this reference point the place where the copter takes off from.  Returning to the wind gust example above, the IPT will "see" the quadcopter move off course, and it will then be able to return to it's previous point with a high degree of precision.  All of this without any input from the flyer.

  Once this IPT system is implemented, it would be very easy to start giving the quadcopter a list of locations to visit.  For example, it could be programmed to watch the inputs from the flyer.  If there is no commands for a "long" period of time, the 'copter could then return to it's start point and land itself.  More advanced exercise could involve carrying a video camera and tracking a straight line and then circling a predetermined circle as part of filming a movie.  This could allow for getting shots with very little setup time and no worries about hiding camera cranes or tracks or cords.

  One question you might ask would be why not just use a GPS mounted to the aircraft?  The main reasons are accuracy, update rates, and indoor operation.  Although GPS technology can be relatively accurate, it generally can't be more accurate than 3-10 feet (1-3m).  This just isn't good enough for precise flying.  The rate at which an affordable GPS receiver updates is usually only a couple of times per second.  This is not often enough for precisely tracking unless the 'copter is moving slowly.  If you want to fly in a building it can be impossible to get a GPS signal.  By using IPT it is possible to get around most of these problems.  Having pointed out these issues, I really think it could be exciting to combine GPS with IPT.  In this situation, the quadcopter could use IPT for it's precision while also using GPS to get positional information that would allow the aircraft to relate easily to the rest of the world.  It could be very useful to plot a flight plan using google earth and then have your 'copter fly that path.

  Given my optimism for IPT, here's some possible challenges to my project.  I am using cheap off-the-shelf sensors.  There's a possibility they won't be accurate enough to give the precision I need.  The math involved is somewhat complex and needs to happen pretty often to keep up with the quadrotor, it's possible an 16MHz Arduino won't have the processing power needed.  I will very likely end up with two processors to make this work (one to fly the quadcopter and one dedicated to IPT).

  Well... I intended to get into the math behind IPT in this post.  Instead of looking at it in detail I'll just give you the following.  Because the quadrotor can be in any orientation, there is no super simple way to figure out how a small move in the airplanes X/Y/Z or Roll/Pitch/Yaw relates to the out side world.  This is solved by using a 4x4 transform matrix.  The small incremental moves of the aircraft that the sensors observe are "plugged" into one of these transform matrices (I use plugged loosely.. it actually takes 29 trig functions, 16 multiplies and 4 additions).  The magical part is that when this incremental 4x4 transform matrix is multiplied by the 4x4 transform matrix that represents  the aircraft's previous position, a new 4x4 matrix is created that represents the current position and orientation.  I'd love to claim credit for this, but this type of math operation is used heavily in both computer graphics and robotics (among other places).  It's a ridiculously powerful and elegant solution to very complex problem.

  Time for this post to stop.  Sorry for the wall of text.  Let me know if you have any questions.

~Phillip

<< Previous Quadrotor Post | Next Quadrotor Post >>

Quadcopter Q/A #1

My dad asked me a couple of questions about the project.  Since this information will be of interest to some of you I will post the questions and my reply below.

Do you know if a single Arduino MCU will do the whole job?To minimize software complexity and improve real-time response,you might consider splitting the application into a "stability control" MCUand a "high-level control" MCU. Of course, this introduces thecomplexity of inter-processor communications.    DAD

My response:

Ah, you've been reading my mind.. 

  My Arduino and 6 degree of freedom accelerometer + gyro should arrive early next week.  Until then, the short answer is I'm optimistic.  I'm aiming for a 50Hz loop, but I think I can keep it stable at ~35Hz.  Any lower than that and I'm pretty sure I'll have to go to two Arduinos.   

  Going to two Arduinos has been on my radar ever since I decided to add the inertial position tracking (IPS), as I was afraid the math needed for the IPS would take a single Arduino.  Now that I've figured that part out I'm thinking I might be ok.  In the IPS math, I was able to reduce the number of trig function calls to 6 which I "pre-compute" and store at the beginning of each position update.  The position update then uses the stored values instead of recomputing.  This has reduced my trig calls from 29 to 6.  I don't know how expensive trig calls are yet, but I don't think 6 of them will break the bank. 

  I'm using an accelerometer that has a 32 slot FIFO buffer.  The communication will be over a 400kHz I2C buss (which I've estimated will take 5ms to transfer all 192 bytes).  I Believe the buffer will give me a little extra breathing room when it comes to how often I need to do a position update to keep a reasonable degree of accuracy.  The raw accelerometer data will be averaged as a form of filtering and a single position update will be performed based on that data.  I can also pull an interrupt signal wire from the accelerometer and run it to the Arduino to force a function call when the buffer is full.  The data collection rate on the gyro accelerometer can then be adjusted to make sure this happens at an reasonable interval. 

  If I have to go to a 2nd Arduino, then it will also communicate on the I2C buss.  I believe the information I would need to pass would take less than 1ms on a 400kHz buss. 

  For as much time as the important stuff takes, the biggest potential time sink in the whole program is reading the inputs from the RC receiver.  Servo updates are only sent out at a 50Hz rate.  So If I get "unlucky" while watching for pulses from the receiver I could spend 80ms to gather all four inputs (down to a 13Hz loop and NOTHING else has been done).  To mitigate this, I only watch one input per loop execution (and cross my fingers and hope that I don't have to wait the whole 20ms).  This may make for a slightly "laggy" feel to the controls, but since the IPS+autopilot will automatically correct for external disturbances, I don't think it will be an issue. 

Let me know what you think. 

 As an addition to the last section on watching for the RC inputs, I may eventually try tracking the pulse arrival times and then try to schedule the input watching function just before I expect to see a pulse.  But for right now, I'm ok with with scanning each RC input at ~10hz. 


~Phillip


<< Previous Quadrotor Post | Next Quadrotor Post >>

Quadcopter Project Overview

I've been bitten by the bug to build a small R/C quad copter. For those you who are not familiar with these air craft, watch the two following videos:

  These type of air craft fly by varying the speed of each of the motors to allow it to tilt to move while also making small adjustments to keep it from flipping over and falling out of the sky.  They constantly require very many small adjustments to keep them stable, so a processor acts to keep the aircraft stable while also responding to the flyer's inputs.

  I have a couple of goals with this project:

1. Have fun 
2. Build something I can fly with my other friends who do R/C aircraft
3. Build the airframe from scratch, but I will be purchasing motors, propellors, etc...
4. Do all of the controls programming from scratch using an Arduino
5. Use the Arduino and sensors to make an inertial position tracking system
6. Control the aircraft by by using the R/C control to move the desired location, the 'copter will then do it's best to reach the new location, and stay at the location.
7. Eventually add magnetometer to add an additional external point of reference for navigating
8. Eventually add a gps

  I will be writing more on the technical aspects of this project as I continue.

~Phillip

************ | Next Quadrotor Post >>