Now that I have system identification data, what do I do?

Thanks Leonard,

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 :slight_smile:

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.

Where in the diagram do PSC_VELZ_FF, PSC_ACCZ_FF, PSC_VELXY_FF fit?

Inside the “Target to measured error calculation” ?

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.

1 Like

Yes it should.

Correct.

Bill is correct here.

We made some progress on this. Now we have two diagrams:

  • one for RATE_FF_ENAB = true

  • and one for RATE_FF_ENAB = false.

We improved the variable names, and added many details. I will post updated matlab scripts soon.

4 Likes

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.

@bnsgeyer Thanks, I will ask @fbredeme to fix it.

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.