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