Coming Soon: How to Build a Smoking Ace

Hey everyone,

Next month I will start a simple construction project, demonstrating how to build a "Smoking Ace". It is not always pretty but the goal is to be straight. Please check back in the next few days or weeks to see our progress.

More building on a budget tips

I have been speaking with many people recently about how they build their uav's and larger-scale working aircraft. We were going down the balsa road, which is not so bad. It makes a pretty stiff structure with relatively inexpensive materials. However balsa is graded and strong, light wood is not easy to find nor is it cheap. You can easily run up $300-500/board foot. That is a lot of balsa, I know especially in 3" strips. However, you get the idea that this is not a cheap way to go.

We have been using kiln stabilized wood and it is making a decent product. There have been some issues balancing the stresses in the airframe. Traditional methods more or less work to relax them. My consultations with other people in the community leads me to believe that there may be better construction techniques. The system that we have uses balsa and then fiber glass on top. Our main issue is that balsa takes so long to lay up. To do a good job, it could take upwards of 3-4 weeks of concerted effort to get everything pinned and glued, sanded and filled, sealed and prepped. It is a big job, especially on bigger models with large spans.

OMG the twist, you will make lots of little weights and hooks to untwist your larger pieces as well. In some ways it is a terrifying process for the beginner. It is not hard to do, it can be terrible to do well.Blah blah, no whining. The others use mostly styrofoam cores covered in composites. I have been experimenting this weekend with it too. I have found that you can have a pretty good product with almost no invested time. My realization is that the cheap epoxies available from the hardware store, are easy to handle, water washable, but are way to soft-cured. For these applications, an epoxy chemistry that cures with a hard surface is better than a softer one.

I assume that epoxy chemistries with harder fixing strengths are less easy to handle. We have made several layups and this really is the case. In Florida, it is hard to get away from the humidity and large swings in it. So we lay up outside and bring the layups inside the air-conditioned house. That seems to help even out the handling properties.

The following pictures are using LocTite 60min cure epoxy, 80 oz./yd glass cloth and 3mm depron foam. There are many relief cuts in the foam to help conform to the shape of the fuselage. The pieces are masking taped together, a foam-safe CA glue would work too, but I was trying to limit the number of seams that needed to be joined. Most of the tape is to enforce the shape of the fuselage, not to hold the piece together. Both halves of the fuselage took about 2h to sheet and the glassing took about 20min for one person. It is not perfect, but it is an experiment. My illustrious helpers would assist on the final version for sure.

This model is about 5' (150cm) long and averages 6" (15cm) in diameter.

More Practical Composites

After several weeks of analysis, I came to the conclusion that using a glass or carbon fiber reinforced balsa composite is one of the best ways for us to get the weight out. Our other attempts were plagued with uneven resin densities. We have good luck matching allowables for 2-4 layer lay ups, beyond 5-6 layers we start to diverge pretty badly.

The best results that we have seen is with 60min epoxy and making sure that each layer is well wrung out before it is let cure at normal room temperature, 77F. As the humidity goes over 80% the pots react differently. The biggest issue for the divergence we think is the number of pots of epoxy used. Something happens with the weight and density between the pots.

Make sure that when your layups are done that you have at least a 2-3 layer pot. If you need a much thicker lay up, I would make sure that you make enough for everything. Also it is an issue with the humidity in the room. Do not add alcohol to the resin when you mix in the hardener. If the mixture is missed, it will just ruin the pot. At worst, it will react exothermically and create large amounts of bubbles both make a mess of the part.

Adventures in Composites: Two Bogans and the Art of the Lay... Up

After a year of sitting, our polyester resin had spoiled. So we contacted some people and they said you could do it with just about any medium cure time epoxy. Out into the proper disposal container for petro-chemical waste. Yeah, I went there. Off to the local hardware shop for some epoxy. We bought several batches of 60 min epoxy. Some of the information that our friends told us suggested that we could use isopropyl alcohol to help keep the viscosity of the epoxy down as it is laid up.

Information like this is when it gets exciting. We found out a few things. You can paint the alcohol onto a layer to help flow the epoxy and to reduce the bubbles and flatten wrinkles. I would suggest that pour some alcohol into a cup and paint it on where you need it. Each layup will be different so it is hard to say where you would have issues.

There were some bubble generators in the seam where the semi-mold met the backing. This is probably pretty obvious, but it was due to training air under the resin laden cloth. Our mold also had several regions with nearly perpendicular sections which were hard to wet. In areas like that, I would suggest liberally pre-painting. Be careful not to pool the resin in the bottom since that is not where you want the part to be strong. Another observation was to make sure that when each layer is put down, both people should work in the same direction. Do not work the resin from the nose and the tail. It makes wrinkles and other defects.

It is very important to make sure that each layer has as much of the resin out, or at least even distributed as possible. This means that all of the bubbles, wrinkles and puddles need to be worked toward the edge of the layup. A roller and brushes are the weapons of choice for this work. The handle edges are great for wringing out excess resin from tight radii.

The Girls Love the Long Ball, But the Boys Love the Spin

Someone once told me that it is not the boom, it is all about the shock wave. I guess that is true, you need to feel the motion of the ocean.

You ask, what does this have to do with gyros? Well, if you cannot figure out how fast it is twisting, there is no way to know how far your ball will go. Yeah, actually a lot, since driving a golf ball is not a momentum problem alone. The dimples hold the boundary layer on and make it go much farther.

Gyroscopes are cool, I have the neat little 300 deg/s board from SparkFun, built on a 3DOF IMU. I soldered on some pins so that it is easier to connect to. Connected the ground to the system ground and connected each of the signal pins to a separate "connector". Really, easy and I am a bit electrically declined.

I then set up an easy pseudo code system to watch the ISensor.DataUpdated method. That lets me see the phidgets.datachanged event in my little API. The delegate that I use for ISensor.DataUpdated feeds my smoothing algorithm. I use the smoothing algorithm to keep out shorts and wonky voltage changes that happen. This would feed the Kalmann filter which I still do not have.

I then feed these data updated events into an ArrayList and do my Runge-Kutta routines on them to integrate the unknown functions. This running integration is how I get an approximation of the position of the gyro. Remember gyros return the rate of change of the gyration, an angular velocity so to speak.

We can do a simple integration to get back to a position.

xi = xdot*dt+xi-1

for constant timestep dt and the previous position, xi-1.

I will put some code together for the next post on this.

Phidgets Accelerometers, the Magic of Three-Axes

The three-axis accelerometer is a piezo-electric accelerometer that is about 1" square. It is pretty good and have never seen any issues with drift or orientation issues. It measures each axis in units of g Do not forget to convert to your units, so a reading of 1.2 is actually an acceleration of 38.6 ft/s/s. I just make a little helper function to convert the readings when the phidgets_accelerationchanged method fires.

Hopefully, that will help clean up your code by reducing the risk of double converting units. Even NASA makes this mistake. One of the first things that I set up is a library of unit converstion factors. That way it is less risky if the user wishes to see the measurements in , mks or cgs and my software interanlly uses US Customary slug-ft-lbf. I do not do any conversions in the code. Just read the electrical signals from the transducers and convert them to real units, consistent with the system. Do not try and convert back and forth within the code, it will just be miserable to find.

You convert to any system that is different than your base unit system until you display the data. You can easily set a flag in the display object that shows the data to the user and multiply out the measurements at presentation time via the decoration pattern. To be honest, the Phidgets API is awesome. It makes short work of connecting and managing their instruments, so the code to start an interface kit is not so different from the accelerometer.

do
{
//System.Threading.Thread.Sleep(10);
if (acc0.Attached)
{

Console.WriteLine("_acc0 attached");
//accelerometer events
acc0.Attach += phidgets_Attach;
acc0.Detach += phidgets_Detach;
acc0.Error += phidgets_Error;
acc0.AccelerationChange += _acc0_AccelerationChange;
}
else
{
Console.WriteLine("retry : " + retry + " waiting for acc0 attach");

}
retry++;
} while (retry < 10 && !acc0.Attached); #region helperMethods #region Phidgets event handlers ///

/// handle the phidget device discovery events
///

/// /// protected void phidgets_Attach(object Sender, AttachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " attached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Attach( Sender, Args) :: " + _exc.Message +
"\n");
}
} //phidgets_Attach
///

/// handle the phidget device discovery events
///

/// /// protected void phidgets_Detach(object Sender, DetachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " detached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Detach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Detach
protected void phidgets_Error(object Sender, ErrorEventArgs Args)
{
try
{
Console.WriteLine("phidgets error : " + Args.Code + " " + Args.Description);
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Error( Sender, Args) :: " + _exc.Message +
"\n");
}
} //phidgets_Error
///

/// reads the acceleration from the Phidgets accelerometer
///

/// accelerometer object/// essentially an array of three doubles, one for each direction measuredprotected void _acc0_AccelerationChange(object Sender, AccelerationChangeEventArgs Args)
{
try
{
rawAcc[Args.Index] = Args.Acceleration;
}
catch (Exception _exc)
{
Console.WriteLine(
className + " protected void _acc0_AccelerationChange( Sender, Args) :: " + _exc.Message + "\n"
);
}
} //_acc0_AccelerationChange
#endregion

Another helper method that is constantly requested is converting from accelerations to roll and pitch. You can do the trigonometry yourself, but if gravitation is assumed to act in the -Z direction you can work out the basic orientation of the accelerating object. This can be fooled by large or quick orientation changes, but for the most part sampling frequency can fix this. So I would make sure that you do as little as possible that may muddy the event handler system. They are really fast and that is a good thing in this case.

///

/// calculate the euler angles from the local accelerations
///

/// acceleration toward the right wing, g [gravity multiples]/// acceleration toward the nose, g [gravity multiples]/// acceleration toward the ground, g [gravity multiples]/// headingprivate static void accel2euler(double Ax, double Ay, double Az, double Compass, out double[] EulerAngles)
{
EulerAngles = new double[3];
try
{
double g = Math.Sqrt(Ax * Ax + Ay * Ay + Az * Az);
/* Roll */
if (g != 0)
{
//EulerAngles[0]=Math.Atan2(Ay,Az);
EulerAngles[0] = Math.Atan2(Ay/g, -Az/g);
}else
{
EulerAngles[0] = Math.Atan2(Ay / 1, -Az / 1);
}
/* Pitch */
if (g != 0)
{
//EulerAngles[1] = Math.Asin(Ax/-g);
EulerAngles[1] = Math.Atan2(Ax / g, -Az / g);
}
else
{
EulerAngles[1] = Math.Atan2(Ax / 1, -Az / 1);
}
EulerAngles[2] = Compass; /* Yaw */


}
catch (Exception _exc)
{
throw new Exception(className + " public static void accel2euler( , " + Ax.ToString("0.000") + " , " +
Ay.ToString("0.000") + " , " + Az.ToString("0.000") + " , " +
Compass.ToString("0.000") + " ) :: " + _exc.Message + "\n");
}
}

The one thing you will notice is that you cannot get the yaw from the accelerations. That makes sense if you think about it, flat rotation perpendicular to gravity would not be measured. I usually run a compass in the systems too. That makes the 3-1-3 rotation easy to move between body reference frames and global reference frames. I would suggest that you multiply out the cells for the rotations in a separate method each so that you can just multiply them by calling each method in turn with an argument of the last rotation.

How to Connect and Communicate With a Phidgets Interface Kit in C#

I have a bunch of there 8/8/8 kits. They are great. First, I would suggest getting their newest API package for your favorite platform.

I use visual studio, so I will have biased examples. I could regurgitate their examples, but mine hopefully don't suck.

From a simple command line application. You may get into some static thread issues, but they are generally avoidable.

in your main()...

try
{
InterfaceKit ik1 = new InterfaceKit();
ik1.open();
}
catch (Exception _exc)
{
Console.WriteLine("interface kit error : " + _exc.Message + "\n",);
}

This is pretty simple, and just opens the IK for management. You have to set up some events. In a constructor method, I dump the following code after you execute the Open() method.

do
{

if (ik1.Attached)
{

Console.WriteLine("ik1 attached.");

//interface kit events
ik1.Attach += phidgets_Attach;
ik1.Detach += phidgets_Detach;
ik1.Error += phidgets_Error;
ik1.SensorChange += _ik1_SensorChange;
ik1.OutputChange += _ik1_OutputChange;
ik1.InputChange += _ik1_InputChange;
}
else
{
Console.WriteLine(("retry : " + retry + " waiting for ik1 attach");
}
retry++;
} while (retry < 10 && !ik1.Attached);

I like these do loops for the initialization setups. Why, because it retries and does not fail just because. It says which instrument is having an issue before it proceeds. I use the phidgets_xxx methods to have a standard system for handling the major Phidgets methods .

#region Phidgets event handlers
///

/// handle the phidget device discovery events
///

/// /// protected void phidgets_Attach(object Sender, AttachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " attached.");
}
catch (Exception _exc)
{
throw new Exception(className +
" protected void phidgets_Attach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Attach
///

/// handle the phidget device discovery events
///

/// /// protected void phidgets_Detach(object Sender, DetachEventArgs Args)
{
try
{
Console.WriteLine(Args.Device.Type + " detached.");
}
catch (Exception _exc)
{
throw new Exception(className + " protected void phidgets_Detach( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Detach
protected void phidgets_Error(object Sender, ErrorEventArgs Args)
{
try
{
Console.WriteLine("phidgets error : " + Args.Code + " " + Args.Description);
}
catch (Exception _exc)
{
throw new Exception(className +
" protected void phidgets_Error( Sender, Args) :: " + _exc.Message +"\n");
}
} //phidgets_Error

Then some simple methods to catch changes per port. I connect different instruments to each port. I have to calibrate the readings for each port so that the readings make sense directly from the Read() methods.

protected void _ik1_SensorChange(object Sender, SensorChangeEventArgs Args)
{
try
{
InstrumentType _type = InstrumentType.notset;
int _index = 0;

switch (Args.Index)
{
case 7:
_type = InstrumentType.notset;
_index = 4;
break;
case 6:
_type = InstrumentType.notset;
_index = 3;
break;
case 5:
_type = InstrumentType.notset;
_index = 2;
break;
case 4:
_type = InstrumentType.notset;
_index = 1;
break;
case 3:
_type = InstrumentType.notset;
_index = 0;
break;
case 2:
_type = InstrumentType.notset;
break;
case 1:
_type = InstrumentType.gyro;
gyro.SetRollData(
convertVoltageToUnit(InstrumentType.gyro, Args.Value, 1));
break;
case 0:
_type = InstrumentType.gyro;
gyro.SetPitchData(
convertVoltageToUnit(InstrumentType.gyro, Args.Value, 0));
break;
}
if (_type == InstrumentType.ultrasonicRangeFinder)
{
rangeFinders[_index] = convertVoltageToUnit(
InstrumentType.ultrasonicRangeFinder, Args.Value, _index);
}
Console.WriteLine(className +
" instrument change " + _type + " value: " + Args.Value);
}
catch (Exception _exc)
{
Console.WriteLine(className +
" protected void _ik1_SensorChange( Sender, Args) :: " + _exc.Message + "\n");

}
} //_ik0_SensorChange
protected void _ik1_InputChange(object Sender, InputChangeEventArgs Args)
{
try
{
}
catch (Exception _exc)
{
Console.WriteLine(className +
" protected void _ik1_InputChange( Sender, Args) :: " + _exc.Message + "\n");
}
} //_ik0_InputChange
protected void _ik1_OutputChange(object Sender, OutputChangeEventArgs Args)
{
try
{
}
catch (Exception _exc)
{
Console.WriteLine(className +
" protected void _ik1_OutputChange( Sender, Args) :: " +
_exc.Message + "\n");
}
} //_ik1_OutputChange

///

/// converts the read value, probably in volts to the correct units
/// this will also apply a 6:4 smooth, old value*0.6 + new value*0.4 to help
/// smooth out the readings
///

/// type of instrument read, to get the correct coeefficients/// reading of the instrument/// some instruments are indexed/// the calibrated value
protected double convertVoltageToUnit(InstrumentType Type, double Reading, int Index)
{
double _value;
try
{
int _InstrumentTypeIndex = 0;
double _old = 0;
switch (Type)
{
case InstrumentType.accelerometer:
_InstrumentTypeIndex = 2;
_old = rawAcc[Index];
break;
case InstrumentType.gyro:
_InstrumentTypeIndex = 3;
_old = gyration[Index];
break;
case InstrumentType.pressureStatic:
_InstrumentTypeIndex = 0;
break;
case InstrumentType.temperature:
_InstrumentTypeIndex = 1;
break;
case InstrumentType.ultrasonicRangeFinder:
_InstrumentTypeIndex = 4;
_old = rangeFinders[Index];
break;
case InstrumentType.servo:
_InstrumentTypeIndex = 5;
_old = servos[Index];
break;
case InstrumentType.notset:
break;
}
double A = double.Parse(
AppSettings["instrumentCalibration" + _InstrumentTypeIndex + "A"]);
double B = double.Parse(
AppSettings["instrumentCalibration" + _InstrumentTypeIndex + "B"]);
double C = double.Parse(
AppSettings["instrumentCalibration" + _InstrumentTypeIndex + "C"]);
//apply basic filter to smooth the data
// value = Ax^2+Bx+C
if (_old != 0)
{
_value = 0.6*_old + 0.4*(A*Reading*Reading + B*Reading + C);
}
else
{
_value = A*Reading*Reading + B*Reading + C;
}
}
catch (Exception _exc)
{
throw new Exception(className +
" protected double convertVoltageToUnit( " + Type.ToString("0.000") +
" , " + Reading.ToString("0.000") + " ) :: " + _exc.Message + "\n");
}
return _value;
} //convertVoltageToUnit

It is pretty simple. I then just use events to manage the reading of the ports or inputs. It is really easy at this point. I put the whole session into a System.Timers.Timer loop or a Console.ReadLine system to control the starting and stopping of the application.

Wing Loading, Bah! Land It Like A Man! Full-Throttle and Nose Up!

Recently, we have heard lots of talk about our normally well loaded wings. The balsa versions of our planes work great, and have normal stall speeds around 15-20mph. That is great for normal flying. They are hybrid flying wings and should fly like a Dutch Roll resistant frisbee.

I have been building the carbon fiber and Aluminum versions. They are a bit heavier than we expected, but that is due to real materials. We certainly will take out some of the fat in future revisions, but I think that the issue here is approach speed. You bunch of sissy girls. These planes are UAS, unmanned means the computer should be doing the work to bring the plane in on glide path. I hope our spars are strong enough for the cut the power approach.

What the heck am I talking about? Nope, never been asked that in polite company either. Wing loading is a relative measure that comes out of the basic low-speed aerodynamics of any fixed-aircraft. In some ways, it is a measure of the relative performance of a device with respect to constant thrust. It is most easily expressed as the mass of the aircraft divided by the wing area.

This essentially describes how strong the pressure difference must be between the surfaces to keep the plane in the air. Considering that the higher the wing loading, the larger the drag due to lift turn will be. This will change the trim characteristics of the plane in cruise and require more thrust to keep the plane above stall. Any F-4 or F-15 driver will tell you that more thrust is the answer to everything.

"The critical limit for bird flight is about 5 lb/ft² (25 kg/m²)^[3]. An analysis of bird flight which looked at 138 species ranging in mass from 1x10^-2 to 10 kg, from small passerines to swans and cranes found wing loadings from about 1 to 20 kg/m^2[4]. The wing loadings of some of the lightest aircraft fall comfortably within this range. One typical hang-glider (see table) has a maximum wing loading of 6.3 kg/m², and an ultralight rigid glider^[5] 8.3 kg/m²." - wikipedia

The wing loading also changes the stall speed. If you have to use forward speed to generate enough lift for a given flight regime, you have to go faster to balance the weight of the aircraft with the lift generated. In a flying wing, you cannot just pick the nose up, roll control has to be gentle. The old adage "Little planes add flap, big planes add power" is our friend. If you were interested the effect of wing loading on stall speed is expressed as the following.

v^2 is the stall speed

g is the acceleration due to gravity

Ws is the wing loading, mass/wing area

rho is the density of air

CL is the coefficient of lift of the net wing

Another interesting equation, is the rate of climb. This is just a force balance between the net acceleration, lift generated and the weight of the device.

ac is the climbing acceleration

Ws is still the mass wing loading

vc is the new airspeed

rho is the density of the free stream air

CL is the coefficient of lift of the net wing

g is the acceleration due to gravity

The wing loading term is in the denominator, so if you want to climb faster you need to lower the wing loading, or increase speed. Increasing the speed is way more fun than having gossamer wings. More Power!

We are not so bad, we are in the 23-35 kg/m^2 range for our wing loading depending on the equipment load out. Less than a some gliders. We however, cannot skimp on pimping the power plant. As if we would do that.

Aircraft                Wing Loading (kg/sq m)
swan           10
Buzz Labs Schoolgirl UAV         23
Nieuport 17         38
Cessna 152         51
B-17                    190
F-104                  514
A380                  who cares, it is an airbus
B747                   740

We already know you can do your approach at a reasonable speed, but why? Sensible approaches are for people who do not think that 10 ft/s  sink rates are for roller coasters. Land It Like a Man, Full Throttle and Both Hands on the Stick. Or, just let the autopilot do it, it can tell how far it is from the ground and cut the power at stall two inches off the ground.

If the women don't find you handsome, they ought to find you handy!

Basic Quantities and Some Trigonometry

So You Want to Build a DIY Autopilot

Accelerations

One of the most important quantities for you to measure are accelerations. If your two or more-axis accelerometer is mounted along the traditional axes of the aircraft it will be the easiest to code for. The three traditional axes are:

• From the nose through the center of gravity on the line of symmetry, the Y-axis, roll
• From the center of gravity out of the fuselage toward the tip of the right wing, the X-axis, pitch
• From the center of gravity away from the earth, the Z-axis, yaw
  
     

Figure of Rigid Aircraft Axes

So, now for some basic Trigonometry, everyone remembers SOH CAH TOA.

In general, the following picture is true for a vehicle moving through space.

Figure of the Direction of the Force of Gravitation on a Body

As you can see from the image, the angle of pitch relative to the surface of the earth is the same angle offset of the weight vector relative to the z-axis in the body frame of reference. If we put our accelerometer so that one of its axes is parallel to the body's z-axis at its center of gravity we are measuring this offset vector. Which is really neat, because it means that we can express the angle of the body in level, non-accelerating motion as ratios of the accelerations

Pitch: 

The angle theta between the actual gravity vector and the measured gravity is related to the pitch of the aircraft (pitch = theta + 90°). If we know theta, we know our pitch! Since we know the magnitude of the earth’s gravity, simple calculus gives us our pitch angle:

accelerometer = cos (theta) * gravity

theta = acos (accelerometer / gravity)

And since pitch = theta + 90°

pitch = asin (accelerometer / gravity)

Woot, we calculated the pitch orientation of our airplane using an accelerometer. Pretty easy, huh?

The real formula that we need to use for the software looks like this:

pitch = atan2(accelerometer / gravity, z / gravity)

Common piezo-electric accelerometers return in units of, g, 32.17 ft/s^2 or 9.81 m/s^2. We also know some more things about the flight that let us calculate the angles relative to the ground. More on this later, it is a bit more than basic trigonometry to describe. These equations assume non-accelerating flight. You can use a magnetometer to get the relative plane in space with less math, but magnetometers generally take more interface programming in my experience.

Roll:

Roll needs a second accelerometer with an axis perpendicular to the first so that we can figure out the resultant vector between them and then the angle. Essentially the vector between the accelerometers becomes the "gravitational" acceleration and the relative readings lets us calculate the angle with an atan2 function. The second accelerometer will have some other things to manage such as the effects of the distance between them on the accelerations measured. Physics fun and none of the boring class.

Yaw:

Yaw is the hardest of the angles to measure. The only answer is to use a magnetometer or a compass. In many ways, yaw can be solved by dead reckoning. Dead reckoning is all that is important for most of the projects in the DIY garage. They will be covered later.

Next we will discuss gyroscopes and the beauty of rates and integral calculus

How I started writing a DIY Autopilot

My intention still is to write my own c# based autopilot. It is not trivial as I found out. Lots and lots of details are needed. The first thing that needs to be done is to determine the instruments that you will need to measure the quantities that you need to know to control flight. Even this seems to be a matter of opinion. For a reference, I found every group that I could that was writing their own version.

From my perspective the quantities that we need to know to control flight are:

• air speed, ft/s or m/s
• altitude, ft or m
• orientation, roll, but pitch is good

These are intrinsic quantities that are really easy to do yourself. Air speed is the model's forward velocity. Altitude is the vehicle's position relative to the surface of the earth. Pitch and roll are the angles of the vehicle relative to the ground. Let me rephrase that, roll is the angle between the right wing and a plane parallel to the ground. Pitch is also known as angle of attack. Pitch is the angle between the plane at the center of the vehicle located on vectors from the center of gravity to the right wing tip and the center of gravity to the tip of the nose and the relative wind.

At the beginning you will need to measure the following quantities:

• air pressure
• acceleration in at least two directions
  

Pressure taps are the easiest ways to measure air pressure in a flying vehicle. Piezo-electric accelerometers are cheap these days and are really accurate. In the next post we will talk about issues with these instruments and the physical quantities that you are actually measuring and how to use those as a basis for a control system.

For all of those inch haters, a quick note about units. You can do this in any unit system. It is unimportant. I will write a quick post on the conversions between the US Customary System and the metric (mks) system. Remember metric is actually several unit systems in one and you have to keep them consistent. Oh, and for those trying to buy nuts and bolts, Japanese manufacturers use odd metric sizes, European use even metric sizes, and the US Customary System/SAE is in units of 1/64th of an inch. So SAE/SAME will have three bolt sizes for every bolt size in the two metric systems. Remember that the thread counts are different though.

In my opinion, if the units are managed consistently then the issue is one of presentation to the user. Part of the display system of my code will show you how to do this with a simple object oriented approach.

Tiny 2.11

I need another u.fl connector-based antenna for the ground station XBee Pro modem. I found some at Sparkfun. Per advice, the best plan is to go for the cable and duck route. All of the electronics will be boxed to make them easier to shield from the high current wiring from the batteries to the ESC to the motors.

My current plan is to use:


SMA duck antenna

u.fl to SMA cable

Tiny 2.11 Out of the Box

For those of you following these projects, I have tried to wing an autopilot myself. It actually is getting there, but I thought. Better to get to market with a product before we spend five years debugging stuff that was just a dead end to begin with. I was reading around about each of the other projects on DIY drones. I was considering the Ardurino autopilot, but was a bit concerned of writing ANSI C at a register level. So I went with the Paparazzi autopilot which is well received and more finished to a level where I was willing to get my feet wet.

I got my Tiny 2.11 from Chebuzz in California/UK.

"unpaid recommendation" The guys at Chebuzz are great, I do suggest buying from them. They are better priced for the American market than the other assemblers, have great service and are willing to answer even my bone-headed questions. "unpaid recommendation"

Out of the box, well it came in a normal padded envelope. I was eagerly trying to figure out what each board did. Having returned from vacation, I had forgotten what I had learned. So, here are the parts I received from the "Everything You Need" kit from Chebuzz.

XBee Pro modems
modem0modem1modem2modem3modem4

Main Tiny 2.11 board with pico blade connectors
top
bottom

ESC throttle wire
black and white two pin