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…
We have some preliminary results on the links bellow:
Very useful, thanks. How did you inject the doublet maneuver (double step) used for model validation into the flight controller?
We programmed it on the remote controller. But it can probably be done better in lua.
I’ve been having stability issues with my drone and am considering using this technique to tune it. It seems far safer than Autotune. However, when I tried it out my drone climbed to an altitude of 25-30 m before beginning the chirp. Is there a way to reduce that to some 3-5 m or so?
You have manual throttle control. You need to maintain your height like you would in stabilize.
What about in the other axes? Won’t pilot input affect the chirp response? The example chirp is 130 s long.
If the pilot makes small and slow adjustments the aircraft can be kept in a reasonable space without degrading the chirp response.
The pilot is able to control all axis during the chirp, including the axis where the chirp is being applied.
The example chirp is 130 s long.
This is just the default value, the chirp could be 10 minutes long if the engineer doing the characterisation thought it necessary.
We have made some more progress on this, we now also modelled the attitude controller in simulink. We plan to provide 4.1 and 4.2 versions of the simulink model in the next weeks
4.2 attitude controller would be very helpful! I’ve been having trouble with stabilizing alt