UAV Path Correction

[ALtitudeap]

When having your UAV move from waypoint to waypoint, how do you account for drift from wind. do you create a "window" of variation so that it doesn't "oscilate" back and forth on its way there?

[danstrider]

If you can estimate wind, you can account for this in your heading solution. There are a few ways to estimate wind; you can just fly a big 360 deg circle and deduce your offset and viola, you know what the wind is! Alternately, just fly with a heavier wing loading and reduce the reaction to cross winds by flying faster, or get a faster rate GPS to speed up the correction from your current position to your desired position along the path (*this last one depends on your guidance algorithm).

What's your setup? You can narrow people's suggestions a lot if we know what you're using :-)

Dan

[ALtitudeap]

i am using the Parallax Basic Stamp 2p with a GPS board and a coprocessor to handle the math. I know the formula to calculate, Distance



D = 60 ACOS [ SIN Lat1 SIN Lat2 + COS Lat1 COS Lat2 COS (Lon2 - Lon1)]


Where: D = Distance (in Nautical Miles)

Lat1 = Original Latitude in decimal degrees

Lat2 = Destination Latitude in decimal degrees

Lon1 = Original Longitude in decimal degrees

Lon2 = Destination Longitude in decimal degrees

and also Direction



360 - cos C1 = (sin Lat2 - sin Lat1 * cos D ) / ( cos Lat1 * sin D )



C1 = course angle at point one.

D = the distance from point one to point two. (degrees)



D = 24.79721689 in nautical miles

Distance in degrees = Distance in Nautical Miles / 60

D in degrees = 24.79721689 / 60

D in degrees = .4132869482


but with this information , if i know my destination waypoint and my leaving waypoint, what type of math do i need inorder to create a solid flight path. one person i talked to suggested that i make an artificial waypoint every 20ft between waypoints but there's got to be a better way Right?

[ALtitudeap]

i have a website that i just got started working on. My uncle and i live in different cities so we will use this forum to keep intouch and share code. www.altitudeap.com/phpBB

[danstrider]

In controls, we would say the point to point is tracking (start and end points defined, but not how it gets there) and staying on the path is regulation (at any point in time trying to be where you want it to be). You need to add a regulation loop to keep you on line with your desired path.

Search for "best helmsman method" and you should turn up another way to do path following. The 20ft ahead method also works and is actually similar to best helmsman.

You could also remember that the plane is basically just a velocity vector: it goes in the direction of the nose. If you know the wind vector, you can sum the wind and desired vector to find your needed heading vector to sideslip toward your desired destination. Perhaps this would be easier coding for you.

Just fuel for the fire.
Dan

[ALtitudeap]

thanks Dan for the help.

[clolson]

I'm jumping into this a bit late, and I'm not a controls person, so forgive me if I jumble up the terminology a bit ... but if you have the code already to compute distance and heading between two points then couldn't you do something like this:

1. Compute the heading from the start waypoint to the end waypoint. This is your ideal track.

2. Compute the heading from your current position to the end waypoint.

3. Compute a heading error: current track - ideal track. (Possibly factor in a distance based gain?) With a small amount of trig, you could calculate your distance off the ideal track. It's been a long time but sin(heading_error) * distance = cross track error (I think.) :-)

4. Compute a new target heading which might be something like: the current track heading + cross track error * gain.

If your position and track is taken from your gps, then you really don't have to worry about wind. (You never really know which way you are pointed, just which way you are traveling.) With this approach, a change in wind could push you off your ideal track, but a constant wind won't force a constant error, the UAV should always be trying to get back to the ideal track.

Curt.

[lvspark]

You might want to save these Aerosonde nav papers before they fade away..

http://www.aa.washington.edu/faculty/rysdyk/papers/

[mlbco]

An often overlooked issue in courseline guidance is the difference between the GPS heading rate and the aircraft yaw rate. Most guidance schemes use some type of feedback of the heading error to form a turn rate command which is accomplished by a combination of rudder and aileron deflection. The turn rate is often measured by an on-board gyro orented along the yaw axis. The difficulty arises when one tries to regulate a GPS heading using a body-axis yaw rate gyro. The kinematic relationship between the GPS velocity vector's yaw rate and the aircraft's body axis yaw rate is also a function of the prevailing wind. I've seen many UAVs fly lovely courseline tracks on calm days, yet go unstable when travelling upwind on a windy day.

An intuitive way to see this effect is to imagine you are ridge soaring an RC glider and flying into a wind that nearly equals the flight speed. Your velocity vector over the ground (i.e. GPS heading) is into the wind and very small in size. If you turn the nose even a few degrees in heading to the right or left, the ground speed vector (i.e. GPS velocity vector) will jump 90 degrees (or more) in heading change, and the glider will traverse across the ridge while still appearing to be pointed mostly into the wind. What is happening here is that a small change in body axis heading results in a huge change in groundspeed heading because of the effect of the wind. A control system that feeds-back groundspeed heading error into yaw rate commands can go unstable because of this amplification effect of the wind. Most successful autopilots have some way of compensating for this.

The systems I've worked with use a PID (proportional, integral, derivative) controller to feedback of the cross track error into the heading command. Heading command changes are accomplished with a turn rate control loop that is compensated for the wind effects mentioned above.

Steve Morris

[alexcmag]

Maybe it is a dummy idea, but...

I was looking for GPS protocols, all have a "True heading" information on the stream that tells the direction of movement, based on the offset of current position and previous position.

How about using this heading information to instead of compass heading information?

Maybe calc the difference between true-heading and compass-heading and use this angle to correct the trajetory, until they are close enough.

[clolson]

Maybe it is a dummy idea, but...
I was looking for GPS protocols, all have a "True heading" information on the stream that tells the direction of movement, based on the offset of current position and previous position.
How about using this heading information to instead of compass heading information?


I think this is a great idea from a navigation perspective. In many ways, the effects of a cross wind simply factor out.

However, Steve makes a good observation with respect to turn rate. Think about flying up wind and then doing a 180 turn down wind ... plot an imaginary ground track in your head. Then think about flying downwind and turning back up wind, and other various turning manuevers. If the wind speed is significant relative to your aircraft's speed, the ground path through these turns could involve long slow turning through part of the turn and extremely tight turning through other parts or the turn. You have to be prepaired to handle very rapidly changing ground track heading versus very slowly changing ground track heading, even though the plane is maintaining a constant slow turn relative to the airmass. Steve points out that as the winds increase, this can throw a monkey wrench into many control algorithms that weren't designed to expect this.

I'm flying a Kadet Senior ARF which is relatively slow, so this is something I'm going to have to pay close attention to as I enter the navigation phase of my project. I think I'll be fine with my approach, but it will definitely be something to test and watch for. Thanks for the heads up Steve. :-)

Curt.

[AFSL]

In terms of navigation (GPS output) and flight 'dynamics':
the direction of travel is referred to as "course", whereas
the direction of the nose of the aircraft is "heading".

Similarly we can now say that the changes are:
"coure-rate-of-change", and
"yaw rate" (= the heading-rate-of-change)

The awkwardness occurs due to "yaw-rate" being part of common piloting language, yet in navigation language the important change in direction is "coure-rate-of-change".

(one could in fact claim that: "heading has no bearing on navigation", but that might be the last time you're part of your local hangar talk... the idea is that if the aircraft is reduced to a base ball, it still has a course and it can still navigate, yet heading is irrelevant.)

The point that Steve makes here is oddly rarely mentioned but significant:
An often overlooked issue in courseline guidance is the difference between the GPS heading rate and the aircraft yaw rate...
...The kinematic relationship between the GPS velocity vector's yaw rate and the aircraft's body axis yaw rate is also a function of the prevailing wind.
In fact, for fairly mild numbers (e.g. windspeed 10m/s, airspeed 25m/s, bank anlge 30deg) the difference between "course-rate-of-change" and "yaw-rate" can be upto 70%

The reason for guidance stability problems can typically be traced to the effect that inertial speed has on the response to bank angle, which leads to the above phenomena.

Interesting stuff.