8.29.11

I defended today. It went well, no difficult questions, conversational, just like I wanted. I brought coffee and muffins which seemed to be adequate.

Hard to believe its almost over. I still have to file the damned thing, and there are major sections I want to add. Otherwise, the librarian is the only person left in my way.

I already received my first email with the salutation "Hello Dr. ___" Sure it was automated, but still. I paused.

Substantial amount of drinking has gone one now, but to be honest its sort of anticlimactic. I'm full of confusing emo thoughts, but I think they're only temporary. I want to celebrate, but common kid, don't get cocky.

8.26.11

So close now. The book has been written, and I'm building up defenses as we speak.

Last month or so has been spent living in latex and matlab generating plots. In a way its anticlimactic. After the last post the experiment worked. I generated some great data. I wrote about it. I went to a few conferences where people didn't violently object. San Diego was nice. Hawaii was nicer.

I didn't get to every topic I wanted to, but soon it'll be over and I'll move on to something else. Some day. Probably.

6.17.11

I've gone this far, so I guess the least I could do it make a concerted effort to keep this POS updated during the final stretch (I hope). This means I'm going to have to skip all the intriguing stuff I've been up to the last few weeks, so I'll just say its classified.

Amazingly, even at this stage I'm being pushed to increase the frame rate of the experiment. To that end I'm going to set things up to use pixel subsampling, which reduces the sensitivity of the WFS but results in about a 4x increase in the max WFS camera frame rate. I estimate that with this change I should be able to get shit done at around 70-80Hz instead of the 25 currently. At that rate I should be able to crap out volumes of data at an even higher speed. Hooray.

To that end I generated a new reference image/AOI grid today by blocking the DMs and using the reference mirrors. After establishing an oh-shit backup I'll make changes to the slope code tomorrow to get the new WFS image resolution working.

The good news is that at this point I can do stuff like this pretty quickly. Almost too quickly, since I tend to forget what I changed if I screw things up. Soon it'll be time to retire to a rocking chair by the fire, light up a pipe, and stroke by beard longingly while I tell the next generation of students tall tales about fast centroid code and spatial filter alignment.

6.2.11

Christ, will I ever update this thing? I guess that's the paradox of a blog, the more real shit gets, the less time there is to write about it.

Today was the first time I got results I'm really happy with, and which I think are really publishable. Basically, after countless diversions and problems, the experiment is essentially working as planned. Better yet, I was able to get my hands on some experimental aero-optics data, and after even more diversions and problems, was able to use some semblance of those as disturbances.

If I say a prayer and the stars align, I can get a 20-30% improvement in the average target intensity with these disturbances over the integrator. Astoundingly I've been able to use an "optimal" integrator gain found by toying with the sensitivity transfer function.

Anyway, the main point of this right now is that I'm drinking in celebration. And that's no time to waste writing on the googles.

4.28.11

Holy shit this thing is out of date now. That's what happens when you get busy [not]working.

Since February I've gotten things working relatively well, with one major realignment along the way to remove some barrel distortion that (I think) was caused by the beam getting too close to the edge of a lens. I've also placed L4 on a stage to mitigate the bias WF rather than manually moving L2. Relatively speaking, this lens only needs to be moved a few mm to correct for the DM bias, and using a stage keeps everything in alignment. True the imaging planes of all the following components changes, but so far that effect seems to be negligible. One boring day I'll write a long post about my thoughts on the alignment procedure.

I've also installed plane mirrors, which bypass the DMs, to create a absolute reference WF that I used to generate a SHWFS reference grid. With this latest setup I'm usually able to get the actual beam (w/ DMs) pretty close to this original position.

At the moment I've settled on using the number of modes to control the saturation problem, which seems to be less of an issue than before. Amazingly, the system seems robust enough that I can actually use the "optimal" integrator gain of 0.5 as determined from a sensitivity Bode plot, nearly an order of magnitude larger than the gain I was using before. As a result, the difference in performance between the integrator and LTI controller isn't nearly as wide as before, but now I at least have a reasonable "best case" classical controller to compare it to.

Much more has happened, but in a nutshell I spent today writing some code to compute the encircled energy. I'm still exploring just how much improvement I can eek out of the LTI controller, so tomorrow and next week I plan to experiment with progressively stronger disturbance scales and control modes to find what I can get away with.

Woops

I was wrong. The file problem wasn't the only cause of the saturation although it definitely contributed. After some heavy drinking, I realized that the saturation issue is just something I'm going to have to deal with. Luckily its much more predictable now, which is almost as good as not having it at all.

At the moment its manageable unless the number of modes gets in the neighborhood of 20. Another trick that helped is eliminating the influence of the edge subapertures while identifying the poke matrix. Because these lenslets are on the edge, their centroids can experience sudden jumps if an adjacent spot edges into the wrong measurement error. This is a serious nonlinear source of noise that can create large spikes at the edges of the identified influence functions/mode. As a result, if a large disturbance shows up at an edge and is subsequently projected onto one of these erroneous spikes, the actuators pertaining to that mode can saturate almost immediately. I surmise this is why the edge actuators are the first to go.

I've been looking at ways to just reduce the influence of the edge subapertures instead of eliminating them completely. If I identify the reconstructor directly instead of the poke matrix this could be done by adding a regularization term to the least-squares problem. That route has run into some trouble with the rank of the matrix containing the slope vectors though, so I haven't gone back to it.

Another option is to identify the poke matrix, but regularize the actuator influence functions themselves. This is basically the method in [Hin07a], but obviously choosing the regularization matrix is more art than science...i.e. a pain in the ass.

Lets see, what else. We also finally got some real life, flesh and blood wavefront data. The problem (isn't there always one?) is that there's a large occlusion in the middle of the wavefront sensor image. This is a common geometry in a lot of AO telescopes. I've spent quite a bit of effort on interesting ways to fill in the hole so I can apply the wavefronts on the DM, but eventually settled on plain old least-squares. Because there's significant flow in the data, I can basically identify a "predictor" (smoother?) that fills in the hole based on the future and past sequence of wavefronts in the region around it.

Although its a Matlab indexing nightmare, the results look relatively convincing. The edge pixels aren't quite continuous all the time, but I think that can be fixed by (again) using regularization to enforce boundary conditions. If I can prove that the filled images have the same second order statistics (esp. structure function) as the original data I might be able to squeeze a short paper on it. Bonus.

In other news, I finally got my shit together wrt the target camera. Basically what I learned from that has led to even more modifications to the hardware. That deserves another post.

Somewhere in all this the driver boxes for DM31 crapped out...both of them. In the mean time its just me and my old friend Simulink working simulations.

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.

12.26.

A few days ago I got some new modes that are zero mean. Since the first most is a column of 1's, this means that the other modes are orthogonal to mode 1 in the normal Euclidean sense, and also on the DM surface (theoretically). There's one less degree of freedom, so there are a total of 30 of these.

Its not clear yet if this is going to make a difference since they look pretty similar to the modes I was using before, but you never know. The most significant difference so far seems to be the norm of the phase shapes they reproduce. Maybe there's something that could be done with this parameter to scale them relative to the power in each mode of the disturbance.

Saturation is still a problem I'll have to live with, even though I tried scaling down the amplitude of the disturbance WF. In the mean time I'd like to compare the performance of the two sets of modes, obviously using a set of disturbances that don't cause saturation.

12.21.10

Been plagued this week getting the LTI controller to work without saturation. I'm not sure why I'm suddenly having this problem when it was running smoothly before. Right now I'm frequently getting saturation in the DM voltage after a few hundred samples with the LTI loop closed.



The annoying thing is that it occurs very suddenly, and as a result the modal sequences shoot up, almost like step response. Actually, I'm not sure which one is driving the other, but since no one's touching the experiment, I assume its the control saturation.

Some things to investigate:

1. A bad plant model. It could be that the poke matrix just isn't accurate enough for some modes, and as a result the modal commands from the LTI controller are too coupled or otherwise garbage.

2. Bad sensor data. I doubt this is the case since I've gotten the WFS image very clean, with small realignments and re-referencing every day to keep things tidy.

3. Shitty predictor. Relative prediction error's are sometimes north of 50%

4. Bad internal model. None of the nonlinear effects (rounding or saturation) are included in the controller's internal model. So when saturation does happen the predictor doesn't get an accurate estimate of the current disturbance. Obv. this would only make things worse when saturation was already happening.

5. Bad PI Gain/pole. Possible, but since the integrator is included in the ID I'm not sure the LTI controller would jsut send out higher values if I reduced the PI gain.

6. Unexplainable. The most likely.

I'm gong to see if I can reproduce the problem in simulation if playing around with the integrator gain doesn't solve things. Otherwise, I might also look at writing the code to actually calculate the optimal LTI filter instead of pulling it from the Kalman filter. Basically this involves an LQR problem, with the advantage that you can directly penalize the "size" of the predictor to try to prevent large control values.

Also, it's pretty funny looking at the keywords that send people to this blog, I guess people looking for implementations of different AO algorithms. So if you're out there: no I don't have a simulink SPGD implementation, sorry. Maybe one day.

12.16.10

More playing around with the target camera today. For some reason I haven't been able to reproduce the nice spot from the previous post, instead getting a large blob ~ 100px dia. Prob a result of the mysterious bias problem I've been having.

Luckily most of the performances measures so far show pretty good correlation to the norm of the WF error. Here's an example of the norm of the recon phase compared to the negative log of "sr2," which is the sharpness measure equal to the max intensity divided by the total image sum. Input was a spatially uniform sinusoidal disturbance command around the bias with an amplitude of 20V.

[Chr06a] suggests that the image sharpness is proportional to the Strehl, so its natural log should be approx. inversely proportional to the spatial RMS of the wavefront error (by the Marechall approximation). Seems to be about right if you squint.

The imaging sensor of the target camera isn't placed with the same accuracy as the other components, so its possible that minimized wavefront doesn't minimize the measured Strehl. I don't expect this to be a problem though since ultimately I'm going to be looking at the noise power, and I think unless the placement is way off with LTI controller should show an obvious improvement.

Here's a video of a random disturbance with the corresponding target image and reconstructed WF.



Well, obviously, we have a spot which isn't stationary, making power in the bucket measures somewhat useless. My advisor seems to favor these since they're nice to use in simulation when everything is perfectly on axis, so there's going to have to be some convincing before I can really use a different method.

Tomorrow I'd like to get the some sharpness measurements going w/ and w/o the LTI controller, assuming I can ever get it working without it shitting the bed.

12.15.10

The first 3 of yesterday's stuff went fine. Amazingly I was able to get a license for the driver quickly, so accessing both cameras simultaneously through the same interface is no problem. Current target position seems fine for now, here's an example image with both DMs at the bias voltage.



I'll start looking at performance measures today. Incidentally, here's an illustration of the strange bias WF problem I've been having.



This is a composite of the reference SHWFS image from last night and from this morning. Clearly there's been a change in the focus, which is a mystery since no one's been the lab afaik. This is fixed by adjusting L2 (after the spatial filter), and doing some basic realignment, but its bitch to do correctly.

12.14.10

FIR code still isn't working right. Diagonal terms always seem to be wrong in both the LS and normal-equation versions. I think I'm going to table this for now since I really only need it to compare the performance of the adaptive controller.

I really want to focus on getting the target cam working this week so I can start generating some complete data for possible paper submissions. In the process of getting the driver license right now, but its taking a while due to some admin delays. Luckily I can still access the image (although sometimes with a watermark). Stuff that needs to be done:

- Code to generate camera object in Matlab. Can the target and WFS be active simultaneously?

- Determine some nominal positioning where the spot size is reasonably small.

- Find decent camera settings for said position.

- Reconfig HDR code to use if necessary.

- Look at possible performance metrics. See how they respond to basic WF disturbances (step input to DM61, sinusoidal disturbances in a single mode, etc).

- Look at results using different non-PI controllers.

Ideally I'll have all this done by Friday.

12.6.10

Finally managed to get all 3 control situations running on the same disturbance data. For some reason, the bias WF changes significantly from time to time, forcing me to do a realignment each time. The usual symptom of this is a crappy poke matrix, or highly saturated commands when identifying the CL dist. model.

Anyway, something's screwed up with the adaptive loop (AO) as shown below. In the past (and I think in theory), it has outperformed the LTI loop since it can better compensate for plant modeling error. One possibility is that the adaptive filter order is insufficient (right now, the adaptive filter is FIR with order 4). I think I'm going to update the code I have to compute the optimal FIR filter so I can look at how the theoretical FIR impulse looks.




For tomorrow:
- Update FIR code
- Figure out what the deal is with the target camera so I can get some Strehl ratio measurements.

12.2.10: Plotfest 2010

I put in another beam splitter to send the beam to the target camera, so I wanted to run the LTI loop again to make sure everything was still ok. Luckily things still seem to be working, and I ended up spending most of the day thinking about what plots might be useful in analyzing what's spit out.

The controller only projects the wavefront onto the modes that are controlled, but since the modes aren't totally uncoupled irl, looking at these sequences don't tell the whole story. Instead, I projected the wavefront sequence onto ALL the modes and only looked at the the ones that are controlled. The difference is that there is some cross talk from the higher order modes that you don't see if you neglect them from the projection. For the plots here, the experiment used 25 control modes. The LTI predictor was estimated using 10000 frames with a prediction error around 0.38.

Anyway, one of the more useful plots is obviously the PSD's for each modal sequence. Clearly the classical controller is killing the low frequency/static disturbances but does shit for anything else as expected. The LTI controller does a decent job flattening the spectrum, with surprisingly little high frequency amplification like I was seeing before. My experience has been that this amplification shows up when the predictor model is crap, so I guess it was good enough this time. Plant modeling error should also contribute to that, so if the AO loop does even better I'll have an idea that the closed-loop plant isn't matching the theoretical version in the controller.



Next up is the modal sequence itself for a few of the modes. You can clearly see how the completely open-loop disturbances have zero mean (i.e. in Mode 1), a static error that's knocked out by the integrator. The LTI controller makes quick work of the remaining high-amplitude spikes. One thing I really have to do is estimate a noise floor that shows in the stead-state (with no disturbances) due to the WFS.



The temporal RMS for each mode is also instructive. This is key since sometimes the RMS improvement may not be so impressive even if the PSD's are white. Luckily the LTI improves the RMS for every mode, so I guess they're all fairly well formed on the DM. Note the the integrator sometimes does worse in certain modes, I guess those are being sacrificed for the sake of modes that contribute more to the noise power. i.e., modes with the largest RMS improvement should be the ones that have the highest open-loop value (ex. 6 and 9 compared to 8). Notice that after mode 25 there's almost no improvement as expected. But, there is some difference, indicating the influence of the controlled modes creeping in.



Finally, the time series of the spatial RMS. The top plot shows the spatial RMS from the modal sequence, i.e. the part of the wavefront in the range space of the DM. This is fine, but ultimately the Strehl ratio of the beam depends on the entire wavefront RMS, shown in the bottom plot. This was generated by reconstructing the phase directly from the slope vector instead of just projecting it onto the range of the poke matrix. Before, when few modes were used, I think there wasn't much improvement between the controllers in this plot, and subsequently that's why there was little improvement in the Strehl as measured by the target. Based on this guy, if the Marechall approximation is true I should see some significant improvement in the measured Strehl when I finally get the target camera set up again (hopefully tomorrow.



That's all for now. gjdm.

11.30.10

With everything (basically) working, and a reasonable way to generate disturbances, I was able to run the full-blown IIR controller yesterday without any problems. I'd like to be a little more rigorous though and so some id on the closed-loop plant, and play around more with the number of modes to get a sense of how the handling is going to be. Luckily, running 5000 samples takes a few minutes now instead of an hour.

- Verify closed-loop (classical) plant matches model
- Close classical loop with different number of modes. Any instability or saturation?
- Set up target camera with CMU driver

The objective is to have the target camera working, and a good idea of the max number of modes I can use by the end of the week.

11.23.10

Many re-installations, a new software version, much cursing, and a birthday later, I finally have everything (relatively) working with the WFS. Frame rates at the ~260x260px resolution I'm using now are around 250-300 fps, but for some reason in Matlab I'm limited to a mere 30-40. The external trigger guarantees that each frame is fresh though, so this is still an order of magnitude faster than before with that ridiculous artificial pause. I suspect the frame rate problem has to do with the bytes per packet, which I can't seem to change from Matlab directly.

Anyway, at the moment that's a minor problem. This new speed means that generating a poke matrix only takes around 10 seconds. Here's an example after a few realignments:

Recall that I'm now doing differential measurements . I've tried to correct for the bias WF as much as possible, but its no a pure focus so moving lenses around won't completely obliterate it. Surprisingly, most of the modes are recognizable on the 9x9 measurement grid. For comparison, here are the ideal mode shapes resized to that grid from an original 128x128 image:


Most of them look pretty good, and the higher frequency ones might still be usable. The next step is mapping disturbances on the DM. Right now I'm trying to work out a more systematic way of doing that instead of just blindly using the reconstructor matrix. I'm thinking that projecting the desired WF onto a set of modes, other than the DM modes for the 61 actuator mirror, might be useful for this purpose. Maybe PCA modes from the original data or SVD modes of the DM.