EasyStar guided to waypoints by GPS. It is stabilized by an IDG300 gyro and a simple accelerometer. The processor is an olimex ARM7 board. The code doesn't contain any floating point operations. The 3D waypoints are programmed via SD-card.

Views: 2522


3D Robotics
Comment by Chris Anderson on November 13, 2008 at 11:28pm
Nice one! Are you doing altitude hold, too?
Comment by Wim De Wilde on November 14, 2008 at 11:37am
Thanks!

Yes, it does altitude control by slowly changing the engine speed. Normally I program it at 150 meters ASL for the whole flight, but in principle it can be changed from waypoint to waypoint. This is the altitude control info for the flight of the video:


If the speed gets too low because it is flying upwind (like just before 40s), it decreases the angle of attack to speed up. Otherwise the GPS course measurements could get corrupt. This causes a drop in altitude, from which it recovers. You may wonder what the spikes in the engine profile are. Well, this is my audio "downlink" to keep track on the flight phase (waypoints reached etc).

This is the altitude info plot on a longer flight on a day with less wind. You see it climbing to its cruise altitude:


3D Robotics
Comment by Chris Anderson on November 14, 2008 at 12:58pm
So when you decrease the angle of attack, you doing that with just the throttle (no elevator control)?

Altitude data came from GPS? If so, which module did you use (and 1Hz or 5Hz)? Did you find its altitude data accurate enough?

I'm impressed you did the gyro/accelerometer integration without floating point. Some sort of simplified Kalman filter or did you use some other algorithm?
Comment by Wim De Wilde on November 15, 2008 at 2:00am
No, the AoA is adjusted by the elevator via accelerometer feedback.

The altitude data came from GPS. I'm using the EB-85A module (bought for $55, http://www.ohararp.com/products.html). This is an excellent 5Hz module, easy to handle and fairly robust. I'm often flying from the same spot. By comparing the altitude after landing in the log files of different flights, I see the absolute altitude variation is around 12 ft. I've never seen any altitude outliers during more than 20 flights, although the unit is often losing 3 to 4 satellites during turns (9 - 11 sats at level flight).

It uses complementary filtering. I think a true Kalman filter would cause more pain than gain.
Comment by Chris Jones on December 7, 2008 at 10:10am
That seems exactly like what Im trying to do. I'd love to know how you were able to navigate from one waypoint to another without using floating point arithmetic!
Comment by Wim De Wilde on December 7, 2008 at 2:43pm
Hi Chris,

To know the heading to a waypoint you need to calculate the angle of the vector (x,y) = (aimed north - current north, aimed east - current east) with the x-axis, in which east and north are longitude and latitude converted to 'equal' metric units (obtained by multiplying with constants; fixed point example: number x 1.625 = number + (number >>1) + (number >> 3)).

I wrote a fixed point function based on the CORDIC algorithm that computes this angle. Here it is:

long angle(long x,long y)
{
//this function computes the argument of (x,y), in degrees, restricted to [-180,180[
long hoek = 0;
const long rothoek[9] = {5760,3400,1797,912,458,229,115,57,29};
long xa, ya, xan, yan;
short k;

if (x < 0)
{
xa = -x;
ya = -y;
if (ya < 0)
hoek = 23040;
else
hoek = -23040;
}
else
{
xa = x;
ya = y;
}

for (k = 0; k < 9; k++)
{
if (ya > 0)
{
xan = xa+(ya >> k);
yan = -(xa>>k)+ya;
hoek = hoek + rothoek[k];
}
else
{
xan = xa-(ya >> k);
yan = (xa>>k)+ya;
hoek = hoek - rothoek[k];
}
xa = xan;
ya = yan;
}

return ((hoek+64)>>7);

}
Comment by Chris Jones on December 11, 2008 at 6:47am
Cheers for that. Quite interesting. It looks a bit like arctan. I was thinking about using a lookup table. From the looks of things the hardest part is converting lat/long values into delta x y values using the haversine formula etc.
Comment by Wim De Wilde on December 11, 2008 at 10:04am
Chris,

You don't need haversine for lat/lon conversion. Conversion to X and Y is just a scaling. The longitude scaling depends on the latitude (cos(lat)), but this can be constant for the whole flight. The error will be minor unless in extreme cases (intercontinental UAV or UAV for north pole pictures or so). You get the right constant from a small look-up table, based on your initial latitude.

I subtract the initial X and Y from the next ones to keep the numbers small and intuitive. The rest is straight forward 2D geometry.
Comment by Chris Jones on December 12, 2008 at 2:47am
Thanks all this stuff is really useful!

Not related at all but I a while back I was thinking about using GPS navigation on these guys. I would have had floating point but they spend most of thier time indoors :-(

http://www.914pcbots.com/community/
Comment by abu saleh on February 1, 2011 at 5:40am

if we use the haversine formula instead of ur function, what r the consequences?

what i understood with ur project is that, we dont need that much INS AND GPS INTEGERATION for the navigation of uav?

meaning, we just stable the uav via gyro n accelerometor and navigate it using the coordinates(longitude n lattitude)?

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Groups

Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service