Control gain units

https://groups.google.com/group/uavdevboard/browse_frm/thread/df8be690c9a3d93f
Paul, 
I computed the net effect of the rudder gains in terms of the option 
parameters. 
The gains are expressed as transfer gains from either an angle in radians, 
or a rate in radians per second, to a command to the servos, measured in 
units of milliseconds. (You will have to figure out how much the rudder 
will deflect per millisecond of pulse width change.) 
rudder_servo_pulsewidth_yawkp = 2.05 * YAWKP_RUDDER * sin ( yaw_angle) 
rudder_servo_pulsewidth_rollkp = 2.05 * ROLLKP_RUDDER * sin (roll_angle) 
rudder_servo_pulsewidth_yawkd = 0.7 * YAWKD_RUDDER * yaw_rate 
rudder_servo_pulsewidth_rollkd = 0.7 * ROLLKD_RUDDER * roll_rate 
yaw_angle, roll_angle in radians 
yaw_rate, roll_rate in radians per second 
XX_RUDDER in same units as in the options.h file 
rudder_servo_pulsewidth_xx in milliseconds 
william premerlani
=== Controls common to all multirotors ===
https://groups.google.com/group/uavdevboard-dev/browse_frm/thread/4e49f4c573dd2ec0
Congratulations on the quick success with your tricopter. I just took a look at your version of motorCtrl.c and your changes look clean, and should be easy to support as a configuration option. For generality, we just need to recognize that the controls (roll, pitch, yaw, throttle) are common to all multirotors, and translate them to multirotor specific outputs. I suppose we should decide between a switch statement in motorCtrl.c and a more object-oriented approach with the translation code encapsulated in a function.
=== Servo rates ===
I forgot to respond to your question about PWM rates for servos yesterday. 
Right now, servoOut.c uses Timer3 to set the PWM rate for all OC channels 
to (ESC_HZ = 400) Hz. 
Your change only reduces the frequency at which the duty cycle is updated, 
so your servo is still receiving a 400Hz frame rate. 
I think Timer2 is currently unused, so you should be able to set it for a 
lower rate and change line 158 from: 
 OC4CONbits.OCTSEL = 1; // Select Timer 3 as output compare time base 
to 
 OC4CONbits.OCTSEL = 0; // Select Timer 2 as output compare time base
=== control gains ===
https://groups.google.com/group/uavdevboard/browse_frm/thread/c9a9011ebf816fff
Keith, 
I recently also wrote some additional notes for Mark Whitehorn which I 
enclose below .... 
Best wishes, Pete 
Mark, 
Getting up to speed on MatrixPilot. Please bear in mind I have no 
experience of delta wings. 
 - Citing of the board. Choose and orientation that works for you, and 
 for which there is a magnetometer option. For example, I have my board 
 mounted backwards. I mount my board in with an axis parallel to the line of 
 flight. We have discussed this a few times on uavdevboard with Bill, and 
 that seems to be a sensible consensus. When the plane boots, the board will 
 also need to be level. I have made a small stand for my planes so that they 
 are easy to get exactly level in the field, and also acts as a good safety 
 device to hold the plane should the engine / prop startup. 
 - As discussed before, don't use magnetometer at beginning. It 
 introduces to many unknowns and is actually less accurate for heading than 
 GPS only. It is only useful for the auto-takeoff, which we will do much 
 later. 
 - Tuning of the plane: This MatrixPilot thing has 3 simultaneous pilots 
 fighting for control ! The secret is to ensure that all 3 pilots have 
 effective control of the plane, at the same time ! 
 - Manual input from the transmitter 
 - Stabilisation of the plane to keep it flying straight and level 
 - Automatic Navigation. 
When in waypoint mode, all three are working / fighting at the same time. 
The secret to good tuning, is not to make the stabilisation to strong, but 
to make fast enough to react quickly and determinedly to disturbances. 
Get the plane first tuned up in manual only. It's vital to adjust trims and 
get the plane stable in manual, first. MatrixPilot has not integrals in the 
PID loops for control, to eliminate trim errors. 
Then move to stabilized mode with AH_NONE. Experiment initially with flying 
straight and level, and try to get the pitch response to be just enough 
from stabilised mode. With my planes, if I'm flying down with a pitch of 
say 45 degrees, and I let go of the elevator control, it should stabilised 
smoothly and immediately in less than 1/4 of a second to the horizontal. 
While at the same time, there is lot's of control authority from the 
elevator control on the transmitter. PITCHGAIN, PITCHKD. A lot of planes 
(my plane) don't need PITCHKD for damping, they are already damped in their 
design. So I think my PITCHKD is zero. 
Same idea for Roll. Bank at 45 degrees, and let go of the stick. How 
quickly does it fly level again ? Quickly ? And yet is there still lots of 
control authority from the stick. (ROLLKP, ROLLKD). (ROLLKD could be zero 
?). 
On my plane, which is a conventional plane like a bixler or easystar, it is 
naturally stable in the yaw axis (big tail plane). So I switch off 
YAW_STABILIZATION_RUDDER , YAW_STABILIZATION_AILERON. Having that stuff 
fighting everything else on a turn adds to much complexity for me. 
So once basic stabilization is operational, you can move onto Height 
Control. Switch on 
ALTITUDEHOLD_STABILIZED AH_FULL 
This will convert your throttle control on the transmitter into a 
height control, when in stabilized mode. So now 
you can test out the height control mechanisms that will be used later 
in Auto mode (same as waypoint mode). 
And setup your HEIGHT_MARGIN, and other settings:- 
/ 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 
The above would have your bottom height as 25 meters on your throttle 
control, and max throttle will give you 100m of height. 
// 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 20 
Bill recommends 20 as a good place to start. The default of 10 is too small. 
// 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 
Bear in mind, that when the plane is exactly at the right height, it will 
be running at halfway between the above two values. e.g. in this case ((1.0- 
0.35) / 2) + 0.35 which is 0.675 Sometimes that is not fast enough. Depends 
on circumstances, wind, and whether you are racing. There is a special 
racing mode in options.h for fixing the throttle in autonomouse at a fast 
setting. 
// 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 // 
-20.0 I usually go with 20 degrees 
#define ALT_HOLD_PITCH_MAX 15.0 // 20. 
0 
#define ALT_HOLD_PITCH_HIGH -15.0 // - 
20.0 
So once you have that all setup, you may want to try it out in stabilized 
mode. 
You can see that if you have MAVLINK running, then with a friend on a 
computer you can save days. I mean days. You fly, and ask your friend on 
the computer to call out PID values on MAVPROXY or QGroundControl, and then 
suggest changes for them to send up to the plane. Have them confirm changes 
by reading them back from the plane. I did this with Ric in Switzerland 
over a year ago, and it was a great technique for acclerating the tuning 
process. 
QGroundControl can save the PID values to a file on the PC, so you can 
recover them, and hardcode them in optoins.h later. 
 - So I suppose now you are ready to try waypoint mode !. Now you will 
 want to tune up YAWKP and YAWKD which control the rate of turn for 
 navigation purposes. You may need to tune up some of the other parameters 
 to add in elevator on roll in a turn etc. Initially start with a simple 
 waypoint.h file. A single waypoint over the origin is fine to begin with. 
 You can fly away from the origin, engage waypoint mode, and see how it 
 flies back, and whether it moves to the correct height over time. The next 
 route really to try, is usually the buttefly route from the original T3 
 Sparkfun course. (A figure of 8). And only after that, is it time, with 
 your plane well tuned up to consider moving onto the new skill of writing 
 Logo programs (auto takeoff and landing). 
Well, that is enough for now. I hope that the above is complimentary to 
what is in the WIKI.(which you will need to read). 
Best wishes, Pete 
On Sat, May 11, 2013 at 3:18 PM, William Premerlani 
<wpremerl...@gmail.com>wrote:
Category:Gentlenav