1.14.11

Don't know what's worse, having a problem or knowing that it was something incredibly stupid all along.

Changing the disturbances didn't directly change the saturation issue, although it did help lower the prediction error greatly, probably since there was actually something to predict. But I noticed that there was this persistent static wavefront that even the classical loop had no effect on. Right now I'm storing the reference centroid info in a particular file that I occasionally refresh, and it turns out that there was a duplicate in a different directory...generated about the same time I started having these problems. The result was that this file would occasionally be used in stead of the correct reference, causing a "fake" bias that the actuator's couldn't reduce. Genius.

This explains a lot. The bias was usually tilt-like, explaining why the edge actuators were the first to saturate. I suspect that the main issue was that with this shit stuck in the system the disturbance sequences weren't anywhere near zero mean, and that this possibly screwed up the predictor.

Its still early, so I guess its possible this isn't the actual problem. But things got better immediately after removing the ghost file. Here are some sweet results using (fairly strong) disturbances and 25 modes

Obviously the LTI controller is obliterating much of the disturbance. There's still some high frequency amplification, but I think that can be knocked out with some frequency weighting. Looking at the rms values basically tells the whole story

Note that now I'm multiplying each mode by the norm of the phase profiles they produce, so you can compare their rms values relative to each other.

Even with stuff "fixed" though, saturation can still happen. Here's what the commands look like when the LTI controller is switched on suddently

As you might expect there's a jump when the loop is closed. But even this brief foray into shit-town doesn't destabilize the system. At some point it might be interesting to embed the saturation in the internal plant model.

Next week its back to target measurements. There has to be something that works with this kind of reduction in the RMS wavefront. Also, some new disturbance models might be interesting, since this current one is basically the easiest case.

1.11.10

Ever since the big realignment I've never been happy with the way the disturbance commands were generated. Basically they were always "random,' but it was hard to recognize any flow going on. With this saturation problem I took another look and found that its usually the actuators around the edge that hit the wall first. It turned out that sometimes the disturbance actuators around the edge sometimes also had much larger amplitudes. Coincidence?

Part of the problem is that disturbance wavefronts are mapped to commands using the DM61 poke matrix, which is prone to shittyness and can have noise around the edges. I think maybe this means that the inverse of this is causing problems with certain actuators.

It'd be nice to generate disturbances independently of the WFS, so I cooked up some code today that uses the ideal influence functions instead and an arbitrary scaling to get the command voltages. The results look much much better, and you can even see some resemblance between the SS model output and the actual phases measured on the WFS.



The turbulence now looks more like a flapping sheet, like it should if there's flow going on. I hope this means better predictor performance compared to the old commands.

1.7.11

1.5.11

Fuck. Saturation again. This is slowly driving my insane.

Happened today after powering up the DMs from being off all night, so that pretty much eliminates the charge build-up explanation. Nothing changed in the code from yesterday's working version, and I even used the same disturbance sequences, so the problem isn't there.

I'm really out of ideas on what could be causing this other than some plant modeling error, or some problem with the WFS image that happens during the experiment. Tomorrow I'm going to display the WFS image while the test is running to see if anything shitty happens around the saturation point. I might also do a system ID on the closed loop plant to see how closely it matches the internal model.

I feel like my whole life is treading water right now because of this.

1.5.11

Just got back from a week in the mountains to find the saturation problem apparently decided to solve itself. I had the DM's unpowered the whole time, so I'm wondering if its possible that the actuators are somehow accumulating a charge when I leave them on for extended periods. Obviously my code didn't change while I was gone, so that's that only thing I can think of that might change on its own.

Anyway, since things seem to be working again, I'm looking at target camera performance metrics. I have plots for a bunch of them and compared them to the approx. Strehl ratio using the Marechal approximation and the RMS wavefront error. Amazingly there's quite a nice correlation, and the PSF maximum is stationary enough to use a power in the bucket measure with reasonable bucket sizes.

In fact, the smaller the bucket the larger the increase in the average SR when the LTI loop is closed. Using 25 modes I'm seeing around a 20% increase in the average Strehl with a 3px square bucket centered on the unaberrated max PSF. I have no idea if this is satisfactory or not, but at least there's some improvement. My advisor favors this measure, so some things to look at:

- Variation of average improvement vs. bucket size
- Improvement vs. number of modes used
- Improvement with stronger/weaker disturbance amplitudes

This is assuming the sat. problem doesn't reappear. A big if.