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. 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. 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. 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. -20.0 I usually go with 20 degrees 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 wrote:
 * 1) define HEIGHT_TARGET_MIN                                      25.0
 * 2) define HEIGHT_TARGET_MAX                                      100.0
 * 1) define HEIGHT_MARGIN                                          20
 * 1) define ALT_HOLD_THROTTLE_MIN                          0.35
 * 2) define ALT_HOLD_THROTTLE_MAX                          1.0
 * 1) define ALT_HOLD_PITCH_MIN                                     -15.0  //
 * 1) define ALT_HOLD_PITCH_MAX                                      15.0 // 20.
 * 1) define ALT_HOLD_PITCH_HIGH                                    -15.0 // -