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.

Complimentary Filter Example: Quaternion Based IMU for Accel+Gyro sensor

  In this post I am going to post the code for a simple 6 degree of freedom version of my complimentary filter.  This should give anyone who wants to better understand what is going on an opportunity to play with the actual code.  In future posts I will explain how to add a magnetometer and then give the code for a 9dof complimentary filter.

Multi-Copter I/O Shield v2

Hello all,

  Today I will talking about my experience with my multi-copter i/o shield and where I'm going with it.  Over a year ago I built my first MIOS (Link).  This post is one of the most popular on my blog.

The original MIOS

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.

More Fun

  It's been a while since I posted last, so here's a quick one for me to tell about where my quadcopter is and introduce my next project.

  My current quadcopter is flying well.  It has proved quite durable as I started at zero with 'copter flying experience and this one has shrugged off most of my silly mistakes.  I have a lot to learn, but it has been a great learning tool so far.

  Now on to my next adventure.  Arduino announced about a month ago that they were coming our with a 32 bit ARM based board called the "Due" that would be roughly code compatible with the 8bit processors.

Arduino Due

Quadcopter Quick Update #2

  Here's another quick quadcopter update.

  I'm still waiting for my motors and ESCs to arrive before I begin building up the frame.  They should be here this week, hopefully sooner than later.

  I have connected the Accelerometer/Gyro sensor to my Arduino.  It took a little bit of work, but I now have good data coming from the accelerometer.  The gyro seems to have an introverted personality as I have not been able to get it to communicate.  I believe this is due to it needing a 3.3v I2C buss and the Arduino provides a 5v buss (although the accelerometer runs off of 3.3v, it can accept a 5v buss).  I have ordered a level translator to solve this problem.  Hopefully the 5v buss didn't fry the gyro.

  The coding is coming along well.  I estimate that I am over 3/4 of the way done, and I believe the most difficult tasks are completed.  I have made up a flow diagram to show my control loop.

  Quadcopter Control Loop

  Once I am able to get both sensors working, I will be able to start testing the code and debugging more.

  At this point the compiled code is arround 9k in size, so I am optimistic that when finished I will easily fit in the 30k that's available. I will be looking at my memory usage next to make sure I'm not going to run out of the 2KB SRAM I'm allowed.  Right now I estimate my loop time to be 15ms not including the time to scan the RC inputs.  I may use a second Arduino just for watching the RC inputs as they will only come every 20ms and if I start watching for them at the wrong time, I could waste a huge amount of time doing nothing.  I would then transfer the the inputs from the second Arduino to the first through the I2C buss, which should only take 0.2ms.

  That is all for now.

Phillip

<< Previous Quadrotor Post | Next Quadrotor Post >>

Quadcopter Quick Update #1

   Here's a quick update:

 I received the Arduino Pro Mini today and the 6 degree of freedom accelerometer and gyro sensor.

  Yes, they are that awesomely small.  I soldered a right angle header onto the end of the Arduino that has the pin-out for serial data transfer.  I can now attach my FTDI cable that emulates a com port with a USB connection.

  I haven't had much time to work with it yet, but I was able to run a quick test to see how quickly my position update function will run (the one with the fancy math).  With semi random and arbitrary non-zero inputs it takes 2ms to run through all of the math.  It only takes 1.5ms if all of the inputs are 0... not that that will ever happen in real life.  I would love for this number to be much lower, but at 10% of my ideal total loop time I don't see it as being a deal breaker.  We'll see how much time everything else takes.

  Next step is to connect to the sensor and figure out how to communicate with it.

Phillip

<< Previous Quadrotor Post | Next Quadrotor Post >>

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 >>