Gentlenav altitude speed control

Kinetic energy control
'''The idea is to use potential and kinetic energy to find equivalent altitude for given velocity.  https://groups.google.com/forum/#!topic/uavdevboard/u4XpUgGdKwM Equivalent energy is used in MatrixPilot in altitude and speed controls. The total of potential plus kinetic energy (total energy) is used to control thrust, the difference is used to control elevator. The basic ideas are described in the attached paper. The equivalent altitude in meters for a given airspeed in meters per second is one half of the square of the airspeed divided by gravity, or 0.0509696 times the square of the airspeed in meters per second. MatrixPilot uses 32 bits for speed/altitude control. The upper 16 bits is the integer portion, the lower 16 bits is the fractional portion. So, you see, the resolution for the control is very fine, much finer than it needs to be. Based on attached paper from the AIAA guidance and navigation control conference 1986. FAA-7.pdf

https://groups.google.com/group/uavdevboard/browse_frm/thread/87bc28b1b9ac8f6e#

Uses the kinetic energy of plane for steering and not the throttle or speed of the prop. To gain speed the plane could dive, instead of increasing throttle thus crashing into the ground if options not correctly set

Autonomous landing
http://groups.google.com/group/uavdevboard-dev/browse_frm/thread/66dd3db5feeed981

sonar landing and logic

Yaw drift comp. uses air velocit
magnetometer

https://groups.google.com/group/uavdevboard-dev/browse_thread/thread/498179cba65470d9

Regarding strong headwinds with the plane going backwards with respect to the ground, I have tested that, it works just fine, because it is the air velocity vector, not the ground velocity vector, that is used for yaw drift compensation.

Magnetometer mounting
https://groups.google.com/group/uavdevboard-dev/browse_frm/thread/498179cba65470d9?tvc=1

I just want to keep everyone concerned posted on the results of my 3 flight yesterday (in addition to my other 3 flights the day before). All 6 flights indicated perhaps *conclusively, of the magenetometer's * (HMC5883Lfrom sparkfun)
 * accuracy* *when: *
 * 1) it is mounted carefuly aligned to UDB4's IMU and *
 * 2) on a location ISOLATED from any magnetic intereference.*

In my case the magnetormeter worked perfectly well when located under the wing as per attached image, thanks to Pete's recommedation.

http://blogs.freescale.com/2012/10/03/magnetometer-placement-where-and-why/

Here's a discussion of the effects of ferrous materials and current-carrying conductors near magnetometers:

He suggests that 5mA is the max allowable current in a conductor 1cm from the magnetometer. (this is assuming a limit of .1 microTesla for the field strength at the sensor)

73, --Mark

Course over ground
Navigate by where you are going instead of where the nose is pointing

https://groups.google.com/group/uavdevboard-dev/browse_frm/thread/6f33ee9e856d73be# Base yaw control on course over ground instead of heading. This is of particular value for high-dihedral, rudder only control, in which it will prevent dutch roll.

crashmatt: Navigate by where you are going instead of where you are pointing. Maybe it also helps with high aspect ratio wings with lots of aileron adverse yaw. What happens if we do an intentional sideslip for landing control? Does heading always settle to cog with some time constant or does it stay correct due to lateral acceleration?

CROSS TRACKING Date: Tue, Apr 9, 2013 at 6:01 AM Subject: Alleviation of the yaw rate feedback: damping of desired cog To: wpremerlani  https://groups.google.com/group/uavdevboard-dev/browse_frm/thread/3d120586495883e1#

.........Once again thanks to Paul Bizard, who sent me down this path by pointing out that, because of transient side slip, navigation controls perform better based on course over ground. Interestingly, that is how MatrixPilot started out. It used GPS course over ground for navigation. Although that obviated the need for wind computation, the latency caused control issues. So, we moved to heading based controls, which required wind estimation. We have come full circle now. With high bandwidth dead-reckoning, latency in course over ground is no longer an issue. ...............

Attached are flight tracks from some comparison HILSIM test flights that I just ran for three different navigation techniques.

The flights were under identical conditions, except for navigation techniques. It was a Cessna flying a butterfly pattern at about 90 knots with a 40 knot cross wind from 255 degrees true direction. Wind gain adjustment was turned off. The navigation techniques for the three pictures were:

HeadingAndCrossWind.JPG : this is the default (non-cross tracking) navigation technique presently in trunk. It is based on the attitude of the aircraft. The wind is included in the geometry computations. Desired heading is according to the desired course over ground from the aircraft to the next waypoint, using feedback only, no feed forward. The feedback loop drives the actual heading (yaw attitude) to match the desired heading.

CourseOverGround.JPG : this is a new non-cross tracking navigation technique in MP_WJP_research branch. The wind is entirely ignored in the navigation computations. The feedback loop drives the actual course over ground to match a desired course over ground to move toward the next waypoint.

CrossTracking.JPG ; this is a new cross tracking navigation technique in MP_WJP_research branch. The wind is entirely ignored in the navigation computations. The feedback loop drives the cross track error and cross track velocity to zero.

The reason that the wind can be ignored in the two new methods is that when the feedback loop drives the actual course over ground to match the desired course over ground, the difference between the two will be zero. When the two courses match, the "crab angles" for the cross wind that would go into a heading computation is the same for the two courses, so it cancels out in the subtraction, and is not needed.

Once again thanks to Paul Bizard, who sent me down this path by pointing out that, because of transient side slip, navigation controls perform better based on course over ground. Interestingly, that is how MatrixPilot started out. It used GPS course over ground for navigation. Although that obviated the need for wind computation, the latency caused control issues. So, we moved to heading based controls, which required wind estimation. We have come full circle now. With high bandwidth dead-reckoning, latency in course over ground is no longer an issue.

My plans for next steps is for Phil, Tom, and myself to flight test the new techniques. If all goes well, I will port to trunk.

Best regards, Bill

On Sun, Apr 14, 2013 at 8:24 PM, Wi

https://groups.google.com/group/uavdevboard-dev/browse_frm/thread/ee66cd0b6403e581  crosstracking committed to branch

I just did an HILSIM test flight of MP_WJP_research, it checked out ok, you are "cleared for take-off".

A couple of things you should know.

1. You will not be able to do a ground check of the nav gains, because navigation is based on course over ground. I plan to add something to the code that will use heading instead of COG during ground tests.

2. There is one cross-tracking parameter that you can adjust, its in the navigate.c file:


 * 1) define CTMARGIN 64
 * 2) if ( CTMARGIN >= 1024 )
 * 3) error ( "CTMARGIN is too large, it must be less than 1024")
 * 4) endif

Basically, CTMARGIN is like HEIGHT_MARGIN, except it is for lateral motion. It is the cross tracking distance at which the cross tracking adjustment saturates. Units are meters. 64 meters is a pretty good number for a Cessna, it might be a bit too large for your Twin Star, you might be better off with 32 instead, but I would not recommend anything less than 32 or greater than 128.

CTMARGIN does not have to be a power of 2, it only has to be an unsigned integer.

Best regards, Bill