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 * (HMC5883L<https://www.sparkfun.com/products/10530>from 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 <wpremerl...@gmail.com> 
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:
#define CTMARGIN 64
#if ( CTMARGIN >= 1024 )
#error ( "CTMARGIN is too large, it must be less than 1024")
#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
Category:Gentlenav