Showing posts with label Quadrotor. Show all posts
Showing posts with label Quadrotor. Show all posts

Wednesday, January 22, 2014

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

Tuesday, June 26, 2012

Quadcopter Build Status

  In this post I will be covering the final assembly of the quadcopter frame and the mounting of the electronics.
Picture 1 - Wiring

Thursday, June 21, 2012

Quadcopter: Inertial Position Tracking - RIP


  Yep, you read that title right.  IPT is dead.

  After playing with my sensor for the last few months, I finally opened up an excel spreadsheet to figure out what kind of accuracy I need to make IPT work.  Using some rough figures,  I need a sensor that is at least 1000x+ more sensitive & accurate than my current one.  One set of numbers I used suggest that 5000x is probably closer to what I need.  Another way of looking at this is that my current sensor has a resolution of roughly 0.004g while I need something closer to 0.0000008g.  There are sensors which provide ~2x more resolution, but clearly that is not going to be sufficient.  Sensor drift over time and temperature will also be a significant issue.  Similar accuracy issues exist with the gyro unit.

Saturday, April 7, 2012

Quadcopter: Accelerometer Data Filtering

  Today is the day you have all been looking forward to.  Today I will be spilling my guts about filtering accelerometer data.  Ok, I might be one of the few people who gets excited by data filtering as I have been looking forward to writing this post.  This is written to be understandable by a broad spectrum of people.  I apologize to those who are technically advanced and find this tedious.


Sunday, April 1, 2012

Quadcopter: Frame Assembly


  I spent some time this last week making the center frame plates and assembling the main frame components.  I took some pictures while doing it so you can see the process.

Thursday, March 29, 2012

Quadcopter: Inertial Position Tracking Tech Update #1

  Here's a quick update to the status of the technical aspects of the Inertial Position Tracking (IPT) part of this quadcopter  project.

Tuesday, March 27, 2012

Quadcopter: Parts Arrive and Motor Mounts

  After waiting for what seemed like forever, the remainder of my parts arrived yesterday.  I placed the order on the 3rd of March and naively selected the airmail option from Hong Kong.  A mere twenty-three days later, it arrived.

  There is four motors, four speed controls, and two batteries in the picture.  I purchased the motors looking for a light option as I am trying to keep this quad reasonably light.  The prop-saver part of the motor is smaller than I expected, so we will see if that becomes a problem.  The mounting holes are too small for #2-56 screws, so I will need to make them slightly bigger.  The batteries are 1800mAh 3S rated for 40c-50c discharge rate.  That much current is way more than I need for these motors, but I may want to use these for other motors or other projects where the current will be useful.

  Getting ready to ream the motor mounting holes and drill holes in the carbon fiber motor mount sticks.

Reaming the motor mounting hole to increase them from 0.080" (2mm) to 0.095" (2.4mm).  This should allow a little extra room to take into account the imperfections in the hole spacing on the motor and in the mount stick.

   All four holes reamed.  Cute little motor.

   Drilling the holes in the motor mount sticks.  The sticks are 1/4" (6.4mm) square carbon fiber.  The motors will be mounted with steel #2-56 screws.  The sticks will be glued to the body and screwed with #4-40 nylon screws.  I have bolted down two strap clamps to position the sticks so that all of the sticks are drilled the same.

   Here you can see all eight of the motor mount sticks.  You can see that the holes on the one end are larger to accept the #4-40 screws while the other end has smaller holes for the #2-56 screws.  The carbon fiber sticks are hollow to reduce weight.

That's all for today.

Phillip

<< Previous Quadrotor Post | Next Quadrotor Post >>

Monday, March 19, 2012

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



Tuesday, March 13, 2012

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

Sunday, March 11, 2012

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

Saturday, March 10, 2012

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

Thursday, March 8, 2012

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