Actually, calculating the slip/skid angle from the IMU data is not as easy as detecting it and using it in a control loop to eliminate it, which I assumed was the intent. If you actually want to know the value for some reason I'd have to look into it further....
Angle of attack indicators, or lift reserve indicators (similar, but a little different) are sometimes useful. Mostly knowing the angle of attack is useful for avoiding stalls, which generally comes into play when flying heavily loaded at slow speeds. However, again, the vane approach is only necessary if you want an accurate and quick measurement. We can compute angle of attack (the actual value) based on pitch data from the IMU and 3D velocity vector from the gps. So if the update rate you are looking for is comparable to the gps update rate and you want an accuracy on the order of a degree, I think we can calculate it well enough with the info we already have.
Also, while AOA indicators are useful for avoiding stalls, the primary instrument used for this purpose is airspeed, which is easier to measure (no moving parts).
Gagarien from this post compared AOA and airspeed which resulted in my curiosity of using an AOA sensor as a complementary sensor and if it would benfit MatrixPilot.
“AOA can be more usefull than airspeed eg. given AOA well calibrated would result in a certain airspeed irrespective of wind direction etc. can be set up for maximum endurance, best climb rate, auto land were you can be assured the lowest airspeed without stalling etc.etc. ---- my 2 cents.”
My reading indicates, concerning side slip, that side slip is mainly used to create coordinated turns. I was unaware however, that side slip is more difficult than initially perceived to detect and use in the control loop. This is mainly my perfectionist striking up discussion on the subject so thank you for enlightening me.
In summery do you suggest AOA and side-sip are overkill for RC plane attitude control and more hassle than worth it?
Jack, There are two versions of MatrixPilot to consider. MatrixPilot2.0.3 and the "Head of Trunk" in the subversion repository. The latter probably has a lot more functionality (I'm losing track of MatrixPilot 2.0.3 it seems a long time ago now).
In the latest version in SVN, you can specify various mode of AltitudeHold independently for stabilized mode and waypoint mode.
// Altitude Hold
// Use altitude hold in stabilized mode? In waypoint mode?
// Each of these settings can be AH_NONE, AH_FULL, or AH_PITCH_ONLY
#define ALTITUDEHOLD_STABILIZED AH_PITCH_ONLY
#define ALTITUDEHOLD_WAYPOINT AH_FULL
With AH_FULL and when in stabilized mode, your throttle control on your transmitter becomes a height control instead of a throttle control. At full "throttle", now "height", the plane will travel to the maximum height set further down in the options.h file.
// Min and Max target heights in meters. These only apply to stabilized mode.
#define HEIGHT_TARGET_MIN 25.0
#define HEIGHT_TARGET_MAX 100.0
As you decrease the "height" on your transmitter, the plane will eventually descend down to HEIGHT_TARGET_MIN above ground. A certain amount of the minimum travel of the Throttle stick is kept reserved so that you can still shut of the Throttle completely when you move the stick to absolute minimum
In Waypoint Mode, and with AH_FULL set for waypoint mode, the plane will obey instructions primarily from the waypoints.h command file for height. It is vital to set the following parameters correctly ....
// The range of altitude within which to linearly vary the throttle
// and pitch to maintain altitude. A bigger value makes altitude hold
// smoother, and is suggested for very fast planes.
#define HEIGHT_MARGIN 10
// Use ALT_HOLD_THROTTLE_MAX when below HEIGHT_MARGIN of the target height.
// Interpolate between ALT_HOLD_THROTTLE_MAX and ALT_HOLD_THROTTLE_MIN
// when within HEIGHT_MARGIN of the target height.
// Use ALT_HOLD_THROTTLE_MIN when above HEIGHT_MARGIN of the target height.
// Throttle values are from 0.0 - 1.0.
#define ALT_HOLD_THROTTLE_MIN 0.35
#define ALT_HOLD_THROTTLE_MAX 1.0
// Use ALT_HOLD_PITCH_MAX when below HEIGHT_MARGIN of the target height.
// Interpolate between ALT_HOLD_PITCH_MAX and ALT_HOLD_PITCH_MIN when
// within HEIGHT_MARGIN of the target height.
// Use ALT_HOLD_PITCH_HIGH when above HEIGHT_MARGIN of the target height.
// Pitch values are in degrees. Negative values pitch the plane down.
#define ALT_HOLD_PITCH_MIN -15.0
#define ALT_HOLD_PITCH_MAX 15.0
#define ALT_HOLD_PITCH_HIGH -15.0
My plane is a Twinstar 2, and it needs the -15 pitch in order to descend correctly when it is too high
The 10m HEIGHT_MARGIN is used as follows. Say the plane is commanded in waypoints.h to fly to 100m.
When it is below 90M the plane will use ALT_HOLD_PITCH_MAX and ALT_HOLD_THROTTLE_MAX to climb to 90m. Then between 90m and 100m (because it is within HEIGHT_MARGIN) it will proportionately decrease the pitch angles and decrease the throttle to _ALT_HOLD_PITCH_MIN
In this example ALT_HOLD_PITCH_HIGH is used when the plane is above 110m. (above height margin + commanded height of 100m from waypoints.h). Again at this height the _ALT_HOLD_THROTTLEMIN.
If the plane is between 110 and 100m then the pitch used will be a "proportional amount of " ALT_HOLD_PITCH_MIN. i.e. the pitch will vary proportionately between 110m, and 100m, so that as the plane reaches it's desired height it levels out onto the desired height (in this example 100m).
To compute the angle of attack pitch is not really needed unless use in conjuction with vertical velocity and airspeed. What is really important though is airspeed, mass and Acceleration. The formula that links the lift, threrefore Z acceleration component to angle of attack is : lift=0.5*Density*Surface*V²*Cl were Cl = K*AngleOfAttack. Knowing Acc Z you can deduce Lift. Knowing Lift you know Cl. Knowing Cl providing you know K you know the Angle of attack.
Now, this K coefficient depends greatly on the ascpect ratio of the wing (because of the way the air flows around the wing in 3D cf: lifting line theory). As an example, a funjet (low aspect ratio) will have a lower K than an easyglider.
Where your relative wind indicator could come handy is for working out this K coefficent for each airframe. Once the measurement is done, it would no longer be needed and we will have real time angle of attack estimation. This K being the same for each particular airframe is can shared with the community.
We found that, provinding we have measured K, a couple of multiplications and divisions later we can have the angle of attack the question is now : what would the benefits be ?
I totally agree with you Doug when you say that it could be used as "a reserve of lift indicator" therefore having a better awarness of the stall than with the simple use of the simple dynamic pressure (indicated airspeed). It could also be used as a drag estimator ( 3D drag = K2*Cl² ) and therefore we would be able to anticipate any airspeed loss due to a change is bank for example (applying throttle even before the airspeed has dropped). In addition ,we would be able to anticipate the right pitch in turn even before the intergral part of the pitch PID compensates for it this would greatly reduce any pitch oscillation.
Having an estimation of the angle of attack could also be used to have a better estimation of the V vector (yes V isn't exactly pointing where the nose of the aircraft is) therefore improving the centrigugal acceleration estimation as well as improving the DR algorythm.
Anyway these are just thoughts but I thought it was important to clarify before neglecting completly this relevant piece of information.
However when I start the UAVdevboard I don't seem to get any GPS lock (even after waiting for 15-20 minutes). The GREEN led is ON and RED led si OFF (after blinking couple of times).
I changed options.h file as follows:
// Set this value to your GPS type. (Set to GPS_STD, GPS_UBX_2HZ, or GPS_UBX_4HZ)
#define GPS_TYPE GPS_UBX_4HZ
Is there any programming I should do for the GPS module in order to have it working with the UAVdevboard?
I know that Arduino autopilot required the user to reprogram the UBLOX GPS module if the GPS module didn't come already programmed for Arduino use.
Is there a similar thing to be done for the UAVdevboard?