I need the source of that diagram so that I can edit it and send it back to you.
I plan to use diagrams.net to recreate it in editable .png file format so that anyone can edit it.
Can you take a look at the table above? It tries to explain why the axis are there and what they are used for.
I plan to make that table part of the matlab script documentation, together with the annotated diagram where one can see where the signals get injected and which signals get logged together with their name.
The matlab script posted above is a good starting script for anyone, just feed one or more .bin log files to it and it generates fully annotated matlab iddata objects. And it is documented
So your question marks are actually:
Angle and rate controller and system yaw response without the command model (input shaping)
And the points with:
(no controllers) still have the controllers active so they will fight against your excitation still.
Any of these can be used to create various models the difference is the frequency response due to the filters the excitation pass through and how the controllers fight against them.
I will send the diagram by email as I can’t attach them here. I used Dia.
@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.
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.
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.
@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.
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.
@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.