ArduCopter 4.1 Attitude PIDs - 20210602.dia.txt (19.3 KB)
@Leonardthall here is my latest diagram, just rename from .dia.txt to .dia.
I added notch filters, point where signals get written to the .bin log files, and the injection point for the system identification.
Can you add the remaining missing information?
They aren’t in the stabilize controller. They are an outer loop (wrapped around the stabilize controller for position control) and do not affect the response that you are measuring with the system ID mode
It is important to know how the data is filtered before it is stored. This will impact bare airframe identification if it is not fully understood and properly accounted for in the model identification.
ArduCopter 4.1 Attitude PIDs - 20210603.dia.txt (21.7 KB)
I worked a bit more on it and did some corrections.
@bnsgeyer thanks for the input, I now understand why PSC_VELZ_FF, PSC_ACCZ_FF, PSC_VELXY_FF are not depicted in the figure. The figure describes the stabilize flight more, and there is no position controller on that one.
Yes, it is very important to know the source of the logged signals. That is not documented, this is my attempt at documenting it. I hope this helps other people struggling with the SID mode.
So now it is clear where the SID_AXIS 7…12 are injected and where the RATE* and PID* signals get logged.
Can I get some help in determining where SID_AXIS 1 …6 and 13 get injected? And where ATT* signals get logged?
@Leonardthall In the diagram, shouldn’t you show that the stick position is converted to a pilot attitude request before it goes into the Input Translation block?
@amilcarlucas SID_AXIS 1, 2 and 3 would be the pilot inputs (stick position) as an angle request which would be before the input shaping (which I believe is occurring in the Input Translation block).
SID_AXIS 4, 5, and 6 would be in the same place as the first 3 however the feedforward is off. So in the Angle Controller, the block that says “target to body frame conversion” would be removed from the diagram.
I am pretty confident that what I said is correct but I would like @Leonardthall to verify that.
Yes it should.
Correct.
Bill is correct here.
We made some progress on this. Now we have two diagrams:
We improved the variable names, and added many details. I will post updated matlab scripts soon.
great job @amilcarlucas I am looking into this more and more,
unfortunately I am unable to open the flight log files, could you upload it to another cloud service such as DropBox.
The log files are not important. The PR is, I plan to work more on the PR once I get some time. but feel free to post pull-requests against my branch.
so good,that is a great job
We are still working and improving this. and now have a simulink model of the rate controller, including all it’s inputs and dependencies. We validated it against real flights with ArduCopter 4.1.1.
Our plan is to construct .json model files that one can use in ArduCopter’s SITL to have a realistic simulation without the need for gazebo. Just like Leonard’s freespace callisto.json file. Many thanks for @Leonardthall, @priseborough and @tridge for making this possible. We will post the results here once we have them. We are very close now.
Great work mate. Those diagrams are spot I think!!
@amilcarlucas i just found another discrepancy in your diagrams. The filter FLTT actually only filters the feedforward signal after it breaks from the desired signal. It does not affect the PID branches.
One other clarification on how the sysid mode axis works. Values of axis of 1,2,3 only apply to the FF_ENAB=true case. Values of axis of 4,5,6 only apply to the FF_ENAB=false case. I would say that the rest apply only to the FF_ENAB=true case but I think it is possible to turn that off and still run the sysid. I would have to look at whether it specifically sets FF_ENAB=true in those cases.
I am 99% sure this isn’t true @bnsgeyer. We filter the target and immediately after we calculate the error:
Oops. I overlooked that.
Well I really think that the FF should have its own. Cascading These filters is not really that great in my opinion.
The main purpose of the Target filter is to provide additional filtering only to the output of the EKF that has no other filtering. The EKF comes directly from the IMU and does not use the IMU filter or notch and harmonic notch filters so it is effectively only integrated. The in addition to being unfiltered the EKF output also has steps as the bias are adjusted.
I am not sure what the ideal feedforward filter vs a separate target filter setting would be so I can’t say we should or should not have a separate FF filter. However we definatly do need the target filter for the input of the PID loop.
@amilcarlucas per @Leonardthall correction to my comment, disregard my requested change to the location of the FLTT filter in the control law diagrams.
@Leonardthall what you have done makes sense but it definitely can impact the signal phase with all of the filters being used at once. So our users will need to understand how they interplay. I think having the control law diagrams will help with that.
On the heli side I have been experimenting with managing the lightly damped flapping modes through the use of the filters. Having a separate FF filter may be helpful as I can use the static notch to remove this from the feedback signals. The notch does a better job of managing the phase loss than a low pass filter because I can adjust the depth of the notch. A separate FF filter could be used to keep the pilot and control coupling from exciting these modes in the feedforward path. The thing that makes this difficult is that the modes sit at 3 Hz and using filters that low can impact the handling characteristics. So I am trying to limit that impact by my choice of type and placement in the control loops
Thanks for keeping me honest 
Yes, I definatly agree. I am also not sure if we have given the best advice for people to set it to the same value as IMU_GYRO_FILT for multirotors. This rule of thumb has worked well for me, and makes reasonable sense, but that is not an engineering study of the application. Heli tuning is a whole level again over multirotor tuning. I figured that the T filter may be useful for the FF too and it can always be turned off if it isn’t appropriate.
Thinking about the T filter for a second. I wonder if it should have been added to the output of the angle P loop instead. That way the filter would not have been delaying and filtering the command model, just the correction…
For everybody else reading this:
“turned off if it isn’t appropriate” - I guess that is something we need to make sure people understand. It would not be unusual or unreasonable to have most of these filters turned off by setting them to zero along with other parts of the PID. We support a whole range of aircraft types, configurations and mechanical challenges. Each aircraft and each axis needs different PID loop design and filter configuration to appropriately handle the dynamics. Making the PID object is flexible enough to handle this variety also means many of these tools need to be disabled.
On using all the filters at once. I rarely do this, generally it is the T and D (roll and pitch) or T and E (yaw) filters. But on very noisy aircraft I have found it useful to add the E filter to roll and pitch to get faster roll off.
Yes, I have wondered if the value is high enough to add a fixed notch to each PID loop. I am interested to see how your work progresses in this area. With the new heli autotune going out I suspect heli tunes will step up and this filter design becomes the limiting factor and the new development frontier.
It goes both ways mate. Good engineering requires it. Although needed, the current implementation of the T filter may not be the optimal choice…
