Hello All,

I am newer in coding stuffs and find hard to read the source codes.

Instead, I just watching the Data Objects in system and finally found the caculation of Rate mode and Attitude mode as below, is it right?

Take roll for example,

 Rate mode:
                 ActuatorCommand.Channel[0] =  1500 +/- 400 *(Rade Mode Response (deg/s).Roll * Inner Loop.Roll.P)

 Attitude Mode:
                 ActuatorCommand.Channel[0] = 1500 +/- 400 * ((StabilizationDesired.Roll-AttitudeState.Roll)/(500/Outer Loop.Roll.P))

Any corrections are highly appreciated.

Hugo

P.S.  Why focus on this? Because when adjusting the PID,  sometimes, there is only part of the travel of my Tx may had reaction, the rest feel "dead". I guess the P value may effect the final PWM outputs. This is very strange.

(Cliff fixed typo in title in case someone searches)
« Last Edit: December 06, 2019, 07:18:41 pm by TheOtherCliff »

f5soh

  • *****
  • 4572
    • LibrePilot
Re: AcuatorCommand.Channel calculated in Rate mode and Attitude mode
« Reply #1 on: December 05, 2019, 12:09:54 pm »
Hi,

You should take a look here

Re: ActuatorCommand.Channel calculated in Rate mode and Attitude mode
« Reply #2 on: December 06, 2019, 03:19:29 am »
From memory the actual LibrePilot object names ...

The stick signals that come from the transmitter go through several stages:
- ManualControlCommand is the raw stick positions from the transmitter.  This is often the pulse widths of the channels.  E.g. for PWM or PPM, the roll stick may have a value of 1000 for full left roll and 2000 for full right roll with 1500 for neutral.
- These are converted for instance into bank angle degrees if you are in Attitude mode or degrees per second roll rates if you are in Rate mode.  Those values are put in StabilizationDesired.  If your max Attitude mode bank angle is 55 degrees (the default) and you give full left roll, your 1000 ManualControlCommand may get converted into a floating point -55.0.  (Forgive me if the signs are wrong, but you get the idea.)
- The difference between what the user is asking for in StabilizationDesired, and what the aircraft is actually doing as measured by the sensors is calculated.  This is called the error.  The user may be asking for a 15 degree left Attitude mode bank angle, but the aircraft is currently only banked 12 degrees left.  So it needs to change Attitude by rotating 3 degrees more to the left.
- How fast (the roll rate) it should move is calculated from the bank angle error and the outer loop PIDs.  The result is put in RateDesired.  The value is degrees per second; the rate of the roll desired.
- The difference between this desired roll rate and the actual roll rate as measured by the sensors is the roll rate error.
- The inner loop PIDs convert the roll rate error into ActuatorDesired, a number from -1.0 to +1.0
- Finally, the settings on the Output page convert the ActuatorDesired into ActuatorCommand which is typically a PWM pulse width from 1000 to 2000, but that 1000 and 2000 come from settings on the Output page.

Quote
Why focus on this? Because when adjusting the PID,  sometimes, there is only part of the travel of my Tx may had reaction, the rest feel "dead". I guess the P value may effect the final PWM outputs. This is very strange.

There are several things that can cause the most extreme part of the stick to feel "dead".  Some that come to mind:
- Input page min and max for the channel:  If the stick is moved farther than min or max, it is limited to min or max.
- Output page min and max for the actuator:  If you tell the servo to move farther than the end, the signal is generally limited at a value that doesn't cause the servo to jam.  It doesn't matter how much past the end you ask for, it is limited to min or max.
- Mixing channels together without reducing them properly.  Assuming that channel values are from -100% to +100%, and that the output can only go from -100% to +100%, if you hold +100% roll, then any + pitch you add is completely ignored since it can't go past 100%.  A typical way to handle this is to cut each input in half, so at the worst you are adding +50% roll to +50% pitch.
- ESC can only go to 100%.  Servo or control surface can only go so far before it jams.  It is not unlimited.  If setting P to .005 makes the servo go to 45 degrees, you can't expect that setting P to .05 will do anything useful.  Making a servo go to 450 degrees doesn't make sense.
- PID D term keeps P and I from moving very fast.  PID I is very slow by design, so there isn't much speed limiting there, but P is large and nearly instant.  If D (the slew rate) is the limiting factor, it doesn't matter how high you set P.  It will only slew as fast as D allows.
- Reverse expo setup.

A really important piece for multicopters is that you need to use at least PWW@490 or PwmSync for the signal you give the ESCs.  Slower protocols control the ESC slowly, don't respond quickly enough, require lower PIDs, feel very mushy, loose, and barely in control.  The faster protocols listed earlier will give you a very locked in feeling multicopter that feels like it does what you ask it to do without arguing.
« Last Edit: December 08, 2019, 12:39:41 am by TheOtherCliff »

Re: AcuatorCommand.Channel calculated in Rate mode and Attitude mode
« Reply #3 on: December 20, 2019, 03:49:11 am »
Hi,

You should take a look here

Thank you so much! This help me so much!!

Re: ActuatorCommand.Channel calculated in Rate mode and Attitude mode
« Reply #4 on: December 20, 2019, 04:03:53 am »
Dear Cliff,

Thank you so much for your detailed share!

Reading your reply and I get a very logical image in my mind.

Thank you for giving me the opportunity to access the underlying logic of CC3D through your detailed share!

HugoLuo