I lost this post so I have attempted to reconstruct what I can of everybody’s replies. I think I did ok in the end. I continued my discussion of the topic here:
http://diydrones.com/profiles/blogs/stability-patch-for-motor-max-and-min-and-yaw-curve
Hi all,
I wanted to do a post on this for a while now but it is hard to separate the Yaw issues I want to talk about from a number of other issues regarding the interaction between Roll, Pitch, Yaw, and Throttle.
I will attempt to focus on a couple of issues I would like to point out:
- Default Yaw PID’s parameters and/or Yaw PID loop design could be improved.
- ESC linearization can only be partially implemented and doesn’t necessarily fix the altitude variation problem. This is because we always have the non-linearity below 0% and above 100%. And Yaw is very capable of pushing the outputs into these areas.
- Maximum motor limits in the MotorMatrix library are only effective for the HEX configuration. Quad’s and Octo’s experience a Yaw when the maximum outputs are limited because “opposite” motors are spinning in the same direction.
- Maybe we can improve the way we handle Maximum and Minimum motor outputs. This is a complex problem and I am only starting to get it clear in my head.
In this Blog Post I will focus on point 1 because I have run out of time.
A quick summary of what everybody knows
Roll and Pitch are controlled by using the lifting force generated by each propeller to create a toque on the airframe and rotate the airframe in a given direction. Yaw on the other hand uses the drag of each propeller to rotate the airframe about its vertical axis. To rotate clockwise, the counter clockwise propellers are speed up, increasing the drag, while the clockwise propellers are slowed, decreasing the drag. The difference between the clockwise and counter clockwise drag, and therefore toques, on the propellers causes the rotation of the airframe. So basically, Roll and Pitch are controlled using the force that propellers are designed to do well while Yaw is controlled by the toque that the propellers are designed to minimise. This is why multi-rotors have poor yaw authority.
Sudden Full Yaw Input
If a sudden yaw input is applied to the PID’s using the default PID parameters results in 4500 x 7 x 0.25 = 7875. This is 1.75 times the maximum Yaw Rate Output. This is particularly significant because an output of 4500 is enough change the ESC output by 100%. (Correct me if I am wrong there). So basically Yaw input has much stronger control over the propeller RPM than any other control with the exception of manual Throttle… Maybe (There is a Max Throttle variable).
My impression is that the default YAW PID parameters and PID loops have been chosen to compensate for the lack of yaw authority at the expense of Roll, Pitch, and Throttle/Altitude control. I believe that this is a problem since Yaw is the least important control. In fact we have modes setup to control the copter while it is spinning in the Yaw axes.
My Suggestions
This is difficult because there is a real compromise between Yaw control and control in Pitch, Roll, and Altitude/Throttle. How we juggle these issues depends on our priorities. If our priority is an easy to fly and tune system then I would suggest a number of things we could do to potentially improve things:
- Reduce default STB_YAW_P parameter.
- Multiply the Stick input by ACRO_P instead of STB_YAW_P to calculate the desired rate. Keep STB_YAW_P for its named purpose, stabilising the yaw heading.
- Reduce the Rate output limit to something like 2250.
- If the user wishes to increase Yaw authority they could be encouraged to increase the angle of the propellers up to 10 degrees. It is suggested that up to 3 degrees should be included in large Octo’s.
Here the link to the starship enterprise copter with the angled props.
http://www.rcgroups.com/forums/showthread.php?t=1692582
https://www.youtube.com/watch?v=pVZpGO3Ft-E&feature=player_embedded
Thanks for taking the time to read this.
Replies:
Nick Mann:
Thanks for that. Interesting thoughts.
=========================================================================================
Randy:
Leonard,
Great post and very timely as I'm looking at a couple of these area. Suggestions #1 and #2 look fairly straight forward to implement so no problems there.
I'm very interested in your thoughts on a better "stability patch". Jason and I were discussing this a few weeks ago about how to improve it. As you say, simply reducing the opposite motor is probably not the optimal soluiton. I was thinking that in the AP_MotorsMatrix library when we're doing the mixing we should remember the roll, pitch yaw and throttle contribution for each motor..then when it comes to doing the stability patch we review those motors that have gone over 100% (or under 0%) and then look at the make-up of what caused them to go over. So say it's got a big +ve yaw component to the number..well, we can remove that surplus and then go around to the other motors and take away an equivalent -ve yaw. That might all come from one motor or it might be from a few different motors.
Generally I think we all agree that we should prioritise control so that #1 maintain altitude, #2 roll+pitch, #3 yaw. So yaw is the first to be sacrificed if necessary. That's perhaps not quite true though if you're talking about maintaining a roll/pitch of 45deg at the expense of yaw..in those cases you'd probably prefer to give up some roll/pitch. So maybe there's some minimum stability which must be maintained and then beyond that it's a luxury and is open to be sacrificed.
=========================================================================================
leonardthall:
Hi Randy,
I agree, 1 and 2 are the easiest and most sensible way to address most of this problem.I should have put them in the opposite order though. I think we should multiply the stick input by ACRO_P because that is what ACRO_P was intended to be used for (Ok, I am guessing here). This would then leave STB_YAW_P to be tuned for best PID performance (We don't even have to change that then).
In the current setup, full stick movement, from a stationary level copter, requests 315 degrees per second from the Yaw rate PID. Using ACRO_P will reduce that to 202.5 degrees per second. To put this in perspective, the maximum rate that the stabilised Rate PID's request from a level position is is 202.5 degrees per second, (default acro mode is 180 or 202.5 degrees per second depending if AXIS_ENABLE is set or not).
Now to translate these figures to the peek commanded to the motors in a + configuration. Max Yaw will command plus or minus 100% (limited from 175% out of the Rate PID) from the motors. Considering that many copters will hover between 30% and 50% throttle, this is massive.
In comparison the roll or pitch will request a maximum of 78% is Stabilise and 70% in Acro mode with AXIS_ENABLE set. These numbers drop to 55% and 50% for a copter in the x configuration because of the 1/root(2) factor. On top of this, because roll and pitch are so directly effected by the lifting force of the propellers, the rate will increase very quickly reducing these numbers substantially.
So while it will be very difficult to make roll and pitch reach the output rate limit (and if it does it will be very brief), Yaw can increase to almost double the output limit quiet easily (and because the input into this limiter can easily reach double, it can last for a relatively long time).
=========================================================================================
Randy:
Ok, a lot to digest here and I haven't done that completely but a few bits from me in any case..
Propeller lifting force is approximately proportional to the RPM squared. So if a copter will hover at 50% throttle then it will have approximately 4 times it's lifting capacity in reserve, so lets say that in the real world we have 2 times in reserve.
I didn't know this so thanks for the info. Although we don't get to control the RPM of the motors but rather just provide a PWM...I've plotted the pwm vs thrust curves for a number of motor + esc combinations and although the curve does get steeper as the throttle goes up I'm not seeing quite as much variation as I'd expect from the above...maybe there's some scaling going on inside the ESC, or maybe the rpm between min throttle and max throttle is actually not that different and so I'm only seeing a small part of the curve so the thrust = rpm^2 bit is not obvious. I'll get a tachometer.
Ok, fair enough on prioritising the axis as: #1/#2 roll+pitch, #3 throttle, #4 yaw.
What Leonard wrote below is similar to the solution I like best but I don't think that roll/pitch should always overwhelm yaw control in all situations. For example, I think it's much better to abandon a request from an autopilot for a 45 degree pitch forward in favour of maintaining yaw.
Other solutions do away with opposite motors all together and instead reduce multiple motors that combine to create an opposite. The idea is to minimise the amount that any motor has to be reduced and therefore keep a motors in a similar part of their throttle curve. (minimise the impact of throttle curve on PID gain being different from motor to motor). However this approach will still reduce all motors equally on a quad since this is the only solution to the problem without inducing a yaw, pitch or roll.
Anyway, sounds like we're at the point where we need to try out some of these ideas...
=========================================================================================
R_Lefebvre:
Leonard, good analysis. As Randy said, we were talking about this recently.
An overpowered quad is the worst case scenario. This is because they hover at 20-30% throttle which means they have less control room before one of the motors hits 0%. The more overpowered you are, the worse it is. This was demonstrated by the disagreement between Jason and I about my yaw control changes that were in 2.7.1-ish. My quad flew well with them, but he found it was causing pitch/roll problems. This is because if he input a yaw command, even a gentle one, it was shutting down one of the motors causing loss of attitude control.
However on my quad which is moderately powered, hovers around 50-60%, I had no problem, because I had much more room to move before hitting a limit.
Quads without tilted motors makes the situation that much worse, and of course the 3DR Quad kit has no tilt because it's a flat boom design.
You say that Octos have a problem as well, but I think less so. Reason is, an octo should be able to shut down all the CW or CCW rotating motors and still have attitude control because the remaining CCW or CW rotating motors are still layed out in an X configuration.
But your point about the hexas being the best case is probably true. It's also a better arrangement for motor redundancy because the opposite motor turns in the reverse direction, simply shutting down two opposite motors causes no loss of control. (This is why I've also thought about building a decacopter).
Now, did you notice in the motors library, some part of code called "Tridge's Stability Patch"? This does look at which motors are "clipping" on the high side, and reducing negative control on the opposite motor to match. The problem is it does not work on the low side clipping.
Anyway, I'm going to cut and paste in here something I wrote on the devlist about this issue.
So what we discussed is the possibility of
Sorry I don't have any more.
=========================================================================================
R_Lefebvre:
Coming out of the discussion about the yaw contribution patch, and how it affected the performance of "overpowered" quads, I'd like to put some collaborative effort into rethinking how this is done. Currently, this is done in the function AP_MotorsMatrix::output_armed() in AP_MotorsMatrix.cpe. It's a large function, and is pretty much the last step in calculating the actual motor output. I'll step through it piece by piece:
This part here constrains the throttle controller output obviously, keeping it between 0 and whatever the _max_throttle parameter is. This is to avoid having the throttle controller overpower the yaw, pitch and roll controllers, allowing them some headroom to work. This is based on the fact that _max_throttle is typically 80 or 90%, leaving 10-20% headroom where the attitude controllers can do their job.
// Throttle is 0 to 1000 only
_rc_throttle->servo_out = constrain(_rc_throttle->servo_out, 0, _max_throttle);
This part set the minimum throttle output to _min_throttle whenever the throttle is above the bottom.
if(_rc_throttle->servo_out > 0)
out_min = _rc_throttle->radio_min + _min_throttle;
I haven't back-checked this part, but I assume it is causing all of the controller objects to calculate PWM ranges between 1000-2000. I think the comment should read: "capture desired roll, pitch, yaw and throttle from attitude controllers" since these values obviously don't come from the Rx directly, but from the attitude controller.
// capture desired roll, pitch, yaw and throttle from receiver
_rc_roll->calc_pwm();
_rc_pitch->calc_pwm();
_rc_throttle->calc_pwm();
_rc_yaw->calc_pwm();
This part here has the remnants of the yaw_contribution patch. The idea was that in order to stop copter rising during yaw, we should slow down some motors more than we speed up the others. The problem in case you missed the other email about this, is that the effect of this can cause the output of this bit to hit min_throttle, which "clips" the output of the controller. Basically the yaw_contribution can clobber the ability of the pitch and roll controllers to do anything. This isn't much of a problem on "underpowered" quads (50-60% throttle to hover) since they operate well above throttle_min. But overpowered quads which only require 20-30% throttle to hover, it doesn't take much yaw_contribution before you start hitting throttle_min. Once one or more of the motors are on throttle_min, you start to lose stability.
// mix roll, pitch, yaw, throttle into output for each motor
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
/*yaw_contribution = _rc_yaw->pwm_out*_yaw_factor[i];
if (yaw_contribution > 0 ){
yaw_contribution *= 0.7;
}else{
yaw_contribution *= 1.42;
}*/
motor_out[i] = _rc_throttle->radio_out +
_rc_roll->pwm_out * _roll_factor[i] +
_rc_pitch->pwm_out * _pitch_factor[i] +
_rc_yaw->pwm_out*_yaw_factor[i];
}
}
The stability patch is doing something similar to what I want to do, but it operates on the high side rather than the low throttle settings. If any given motor has an output greater than out_max, it sets that output to out_max, and then subtracts the amount that it is "clipping" from the opposite motor.
// stability patch
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] && motor_out[i] > out_max ) {
if( opposite_motor[i] != AP_MOTORS_MATRIX_MOTOR_UNDEFINED ) {
motor_out[opposite_motor[i]] -= motor_out[i] - out_max;
}
motor_out[i] = out_max;
}
}
Then we have this part, which simply makes sure all the motors are above min. This is where the trouble occurs with the yaw_contribution, or really any yaw control. If any given motor is below out_min (aka: min_throttle) then set it to out_min. So the problem is, if you have a strong yaw control, it can reduce one motor of a quad below out_min, which is then clipped and set to out_min. But the opposite motor does not suffer this. The result is the quad will have a pitch/roll movement about the axis perpendicular to the affected axis. ie: if the yawcontroller output causes motor 1 to go below out_min, then the quad will wobble about the 2-4 axis.
// ensure motors are not below the minimum
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
motor_out[i] = max(motor_out[i], out_min);
}
}
This is the part that needs to be fixed.
=========================================================================================
R_Lefebvre:
So now to discuss what to do about this.
The first thing that must be decided is: Do we want to completely throw out Yaw stabilization if that yaw stabilization causes an instability in pitch/roll? I think the answer is yes. But I'm afraid if we do that, we'll have more complaints about lack of yaw authority. The problem is, I think, simply a case that people with powerful motors are operating too close to the out_min. One solution to that is to lower out_min, and give more room for the stability controllers to work. I think throttle_min might be something like 10-20% by default? Is there a reason we don't recommend going lower, like 5%, or maybe even less? I would think we could go almost as low as possible without having the ESC's actually shut-down?
I bet all of this also has a lot to do with the instability in the quads during descent.
Anyway, so what I'm thinking is something like this. Basically, I'm moving all the yaw controller stuff below the pitch/roll stuff. And I'm constraining the yaw controller PWM to a range which is constrained by how far above the min_throttle we are. If the throttle is low, we cut the yaw controller output to preserve the pitch/roll stability.
// output_armed - sends commands to the motors
void AP_MotorsMatrix::output_armed()
{
int8_t i;
int16_t out_min = _rc_throttle->radio_min;
int16_t out_max = _rc_throttle->radio_max;
int16_t yaw_contribution = 0;
int16_t lowest_output = 2000;
// Throttle is 0 to 1000 only
_rc_throttle->servo_out = constrain(_rc_throttle->servo_out, 0, _max_throttle);
if(_rc_throttle->servo_out > 0)
out_min = _rc_throttle->radio_min + _min_throttle;
// capture desired roll, pitch, yaw and throttle from receiver
_rc_roll->calc_pwm();
_rc_pitch->calc_pwm();
_rc_throttle->calc_pwm();
_rc_yaw->calc_pwm();
// mix roll, pitch, yaw, throttle into output for each motor
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
motor_out[i] = _rc_throttle->radio_out +
_rc_roll->pwm_out * _roll_factor[i] +
_rc_pitch->pwm_out * _pitch_factor[i];
}
}
// stability patch
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] && motor_out[i] > out_max ) {
if( opposite_motor[i] != AP_MOTORS_MATRIX_MOTOR_UNDEFINED ) {
motor_out[opposite_motor[i]] -= motor_out[i] - out_max;
}
motor_out[i] = out_max;
}
}
// ensure motors are not below the minimum
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
motor_out[i] = max(motor_out[i], out_min);
}
if( motor_out[i] < lowest_motor ){
lowest_motor = motor_out[i];
}
}
// constrain yaw controller output to priorities roll/pitch control
_rc_yaw->pwm_out = constrain(_rc_yaw->pwm_out, 1500 - lowest_motor, 1500 + lowest_motor);
// add yaw controller contribution
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
yaw_contribution = _rc_yaw->pwm_out*_yaw_factor[i];
if (yaw_contribution > 0 ){
yaw_contribution *= 0.7;
}else{
yaw_contribution *= 1.42;
}
motor_out[i] += _rc_yaw->pwm_out * _yaw_factor[i];
}
}
#if CUT_MOTORS == ENABLED
// if we are not sending a throttle output, we cut the motors
if(_rc_throttle->servo_out == 0){
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
motor_out[i] = _rc_throttle->radio_min;
}
}
}
#endif
// send output to each motor
for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {
if( motor_enabled[i] ) {
_rc->OutputCh(_motor_to_channel_map[i], motor_out[i]);
}
}
// InstantPWM
if( _speed_hz == AP_MOTORS_SPEED_INSTANT_PWM ) {
if( instant_pwm_force01 )
_rc->Force_Out0_Out1();
if( instant_pwm_force23 )
_rc->Force_Out2_Out3();
if( instant_pwm_force67 )
_rc->Force_Out6_Out7();
}
}
R_Lefebvre:
Sorry the formatting didn't come through, hopefully you can understand what I'm saying.
Also note this isn't finished working code, just kind of a back-of-the-envelope sketch.
=========================================================================================
R_Lefebvre:
I haven't read through everything thoroughly, but I think you're right Randy. I would be better to sacrifice a high attitude request (45° pitch) if you have to to keep the copter yawed properly. But if the request is to hold the quad level, then that should get priority over yaw.
=========================================================================================
Marooned:
Huge amount of knowledge here. Still analyzing in my head what I've just read.
This all match to my observations with my quad of having "random" yaws when playing with pitch/roll or trying to avoid the ground with max throttle stick for a while. And because of having GoPro attached to my quad and that unpredictable yaw heading it's almost impossible to know where camera is looking at the moment and record what I want. Also, when flying away when I'm unable to recognize white vs red arms to determine front of the quad, only "simple" mode is usable.
I was watching great movies of copters flights and always was curious "what did I wrong" to not be able to fly various paths and head properly.
I'm still learning about all those PIDs in ArduCopter and not ready to add my 3 cents on that subject.
Fingers crossed for some great conclusions.
=========================================================================================
leonardthall:
Hi all, Thanks for taking the time to read all this.
When I look at throttle curves what I see is a general RPM^2 characteristic with a fall off or saturation at the high end. I think that this is probably a combination of efficiency going down and the ESC running out of legs at the top end. It may also have something to do with the drag characteristics of the antenna as well.
But basically my understanding is that ESC's basically control the average voltage being applied to the motor (for the purposes of RPM calculation), using pulse width modulation of the driving fets. RPM is approximately proportional to voltage input. Then we should get an approximate propeller force = (ESC input pwm)^2. At least below the peak efficiency of the motor (assuming the ESC is up to the task).
But then all the real life effects start messing with us........
But lets just assume that the pwm to force is X^2 relationship around hover at least.
We get a curve like this:
This graph is computer by comparing the upper and lower Yaw commands we need to give to maintain hover. The Blue line is the ratio that you are suggesting, 0.7/1.42, while the purple is the ratio required to maintain hover or constant vertical force. So based on this idealised model, the ratio you have currently is about right when we are reducing half the motors to near zero.
Sorry, I have to go to a doctors appointment but I will be back to give the equations for the above curves and add the excel sheet.
=========================================================================================
leonardthall:
Ok, the maths.
x = throttle RPM at hover with no control input
y = the reduction in RPM in the slowing motors
z = the increase in RPM of the increasing motors.
Total Lift = 4*x^2 (for a quad without the lift multiplier)
When yawing Total lift is = 2*(x-y)^2 + 2*(x+z)^2
if we want to maintain the same total lift force during yaw
4*x^2 = 2*(x-y)^2 + 2*(x+z)^2
4*x^2 =2*x^2 + 2*y^2 - 4*x*y + 2*x^2 + 2*z^2 + 4*x*z
2*x^2 =x^2 + y^2 - 2*x*y + x^2 + z^2 + 2*x*z
2*x^2 =2*x^2 + y^2 - 2*x*y + z^2 + 2*x*z
0 = y^2 - 2*x*y + z^2 + 2*x*z
Ok, so we have this equation
z^2 + 2*x*z + y^2 - 2*x*y = 0
and we want to calculate what z needs to be.
z = (-2x + sqrt(4*x^2 - 4*(y^2 + 2*x*y)))/2 (we only need the positive root)
z = -x + sqrt(x^2 - y^2 +2*x*y)
So the long and the short of this is that when making small yaw inputs we need a 1 to 1 ratio of increasing and decreasing throttle. When we are applying the maximum possible yaw toque y = x (half the motors are stopped)
z = -x + sqrt(x^2 - x^2 +2*x*x)
z = -x + sqrt(2*x^2)
z = -x + x*sqrt(2)
z = x*(sqrt(2)-1)
z ~ x*0.414
=========================================================================================
leonardthall:
Ok,
Is it better (or even possible) to to sacrifice a high attitude request (45° pitch) if you have to to keep the copter yawed properly?
First up, I agree with the sentiment, I just aren't sure if this is what we want to try to do......
If we are ascending or descending (motors near a limit) with no requested attitude change then the PID loops are simply attempting to maintain the current attitude. Therefore Roll, Pitch, and Yaw inputs will be relatively small.
A number of things could disturb this state:
1. Roll, Pitch, or Yaw input. PID's translate this to the equivalent Rate request.
2. Turbulence or some other force cause a rotation in a number of axis. Attitude error feedback is translated again to the equivalent Rate request.
I think both are important but 1 will happen more often and with larger deviations.
My opinions follow, not facts:
1. If a yaw input is applied then I believe it shouldn't be allowed to impact the roll and pitch loops in any way. This is not too bad because the strong control of the copter in the roll and pitch axis means that the motor RPM deviations from average should be small. Ok, that is easy to say but what about the other way round.
2. If a roll or pitch input is applied I want to see that Yaw still has enough authority to maintain a heading but only just. This is because Yaw will very quickly increase the average lifting force of the motors if we want the same authority of a helicopter or tricopter. So this means we need to allow a certain throttle increase if Yaw needs it, but we want to keep it small because we want to come down.
3. What if we are manoeuvring in all axis. Ok, any strong input in Roll, Pitch or Yaw will reduce our rate of decent because of the RPM^2 tendency. However if we are using the above approach then we will get quick solid response from roll and pitch and a mushy yaw response. The important point is to make sure that we allow Yaw access enough pwm output to keep a heading and weakly adjust heading.
4. As soon as the throttle setting is increased to give a bit of room between the throttle setting and the minimum output then Yaw authority will return (at lease return as much as it can in a quad).
Ok so what happens if we are descending with near minimum throttle in Stabilise mode and we want to go from horizontal to a 45 degree pitch forward. Using the rational described above the pitch will change very quickly (less than a second in my quad), we will momentarily increase the total lifting force being applied to the copter de-accelerating the decent during the manurer. During this... lets say second, the output that yaw is allowed to exert is at it's minimum limit. This means that the copter will have very limited ability to accelerate in Yaw during this second but enough to maintain it's current state. Ok, I am happy with the performance the way I describe it so far. What happens after this maneuver though? The copter now has angle boost plus minimum throttle, increasing the headroom that Yaw can use (a 45 degree angle increased the throttle (g.throttle_cruise + 80) / 0.75).
Code Here:
http://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/Attitude.pde#501
So while a maneuver in roll or pitch away from flat hover, will reduce Yaw control to the minimum needed to maintain a heading for the short period of time, after the maneuver the Yaw authority will be increased (and I don't think people will even notice). However, if the roll or pitch maneuver is back to level there will be less Yaw authority afterwards but who cares, if I let go of the sticks in Stabilise mode I want my copter to go back to level, I don't care if I can't Yaw for a second.
Ok as for point 2.
We are descending and clip a branch. The copter tumbles, we crap ourselves, we don't increase throttle because we don't want to see it accelerate into the ground. Please PID's save me!!!!!
This is a simple one. Get me level then worry about Yaw. We probably have some angle boost helping us for most of the time as the copter attempts to right it's self so that will help but Yaw just isn't on the priority list in this situation at all.
Ok so to answer the question, No I don't think we should reduce roll or pitch authority to get better yaw when near throttle minimum (although I would allow more headroom for Yaw near Throttle maximum). In Stabilise the increased roll and pitch angle will actually increase Yaw authority due to angle boost.
=========================================================================================
leonardthall:
Just a quick note. I hope these replies don't come across as condescending or "know it all" in any way. I am simply trying to put as much detail into my replies as I can to ensure that my thoughts are coming across clearly.
I am also making a real effort to make the most out of the feedback of the DEV team because I realise that you all have been playing with this stuff for a long time now and have a wealth of practical experience with the APM2 on a variety of airframes that I don't have.
As for the post above, I didn't address the (or even possible) part of the question. I was wondering how we would do this quickly (processor clock cycles) without strongly disrupting the roll and pitch PID's. I don't really have an answer to that part of the question......
I will see if I can find some references for where I got the RPM^2 thing.
Comments