[Ian, Jeff]
Jeff and I used the models for the previous fitting of the laser lock in the piezo controllable cavity to create an H2 optimal controller. We used two FOMs that were flat giving us no relative scaling.
The models we used for the plant and for the noises are either out of date or wrong. Jeff is working on getting better models as well as automating the system to take the data.
The current configuration (provided in the PLC folder of buzz) solves for the H2 but does not solve for the H infinity bounded (Hib) controllers. For the Hib controllers it seems like the solver is solving, i.e. it does not return an error, but the list of results is empty. I am not sure why this is true. I have not investigated very thoroughly for this problem.
The H2 solver seems to work but returns a controller with a DC amplitude of 10^10. I attached a figure (H2_controllers.pdf) with the hand tuned controller and a scaled down version to fit the requirements of the Moku Pro. Note that this controller is made with the wrong noise and plant and would need to be updated. It is not to be used in the system. The controller's order 50 so would need reducing even if it were to be used. When I was scaling the controller down, I decided to scale it down before the compute.calcFullResults(). This means that all of the loops frequency responses and RMS values were updated for this new controller. With the scaled down controller, i.e. the H2_optimal_controller * 1e-5, the RMS value improved by two orders of magnitude. This should be impossible. The H2 optimal controller should have the lowest possible RMS. Nothing I could do to the H2 optimal controller should be able to decrease its RMS.
To trouble shoot this I started to look at the connections for the composite state space model I made. I noticed that in the connections when I used .siso() to pull out a component system from the larger system, it would not match the original, i.e. S would not equal sys.siso('S.out', 'S.in'). These two things should be equal or almost equal the very lest. I reduced this system to just the environmental noise, which I am calling S, and the plant, which I am calling P. When I connected them in series with the function ssutil.multiconnect() I got different results depending on which order I gave it S and P. Note: multi connect takes a list of systems as its first argument (whose order should not matter) and list of connections to make in the system. when I changed the order of the systems in the system list (giving it the lists [S, P] or [P,S]) I saw different results for the frequency response when I broke them apart. with both orders the connections were the same only the order of the provided systems was different. In the attached fig (Connection_order.pdf) it can be seen that the S from the [S, P] ordering does not agree with the S that was used to make it. Normally I would assume that this was some error in the type of the system, i.e. I used the wrong convention when making a ZPK, but these two systems were made from the same S and P model so they should only be different in the order they were given.
These should be the same and bug like this could affect other models. To debug I looked at the connection functions and played around with the order that I provided the systems in the makeSPOFF() function. I looked at how I was assembling. I just used controls append function to make a big system with all of the all of the sub systems that were not inter connected. Then used the interconnect function in control to connect them all. The most obvious error would be that the indices were messed up according to the order in which the systems were presented. But this would have probably shown up by now. In any case I checked this and it seems to be correct. I looked at the bode plots for all of th indices and they seem to be referring to the same thing. It is possibly some scaling issue. But I haven't figured it out yet.
