6.25.10

As I mentioned, one problem with the velocity estimation method I'be been playing around with is that the estimates aren't constant for autocorrelations over a different number of delays, even when only one phase screen is used to generate the data. The question is, is this a result of the method, or is something phucked up in the simulation data itself?

We needed a second set of data to test things out on, and I remembered that we got this CD with "challenge" data from a conference we attended a few months ago. Basically, the data are frames from OPD data of turbulence over some flat plate, so its not exactly the same as general AO turbulence, but close enough to validate the velocity estimation algorithm. The data's pretty dense: each frame has phases on a 41x41 grid, and there are around 15000 frames in each file. Unbelievably though, its all stored uncompressed in a fucking 1GB text file.

It took me 2 days to figure out how to load just enough data in from this shit pipe to be useful. Right now I'm taking every third frame or so, and only using every other grid point. Making Matlab do this without reading every line in the text file took more than a few hits of caffeine.

Just looking at the autocorrelations of the frames (instead of calculating a SS model first), I still see the problem if varying velocity estimates as a function of the delay. Calculating the velocity from the data itself is something other people have done successfully, so either they're all full of shit or I'm just missing some detail. I suspect there's some pre-processing of the data I have to do to get more consistent estimates.



Here's a cool video of the spatial autocorrelation over 7500 frames for a varying number of delays. The peak should move with the same velocity as as they layer, at least until enough delays are used so the frames are essentially uncorrelated.



From the vid it looks like its moving with a constant velocity, but its hard to know exactly.

I need a drink.

6.18.10

This is "inter-session" week, the time of bliss on campus between finals and the start of the summer quarter when undergrads have gone on internships and professors have gone on vacation, and only pale grad students and vagrants are out and about. Its basically the only time its possible to find an empty seat in the campus coffee shop, which staffed by dour students clearly disappointed they couldn't find something better to do for the summer.

You'd think with finals over that this would be a great time to for me to actually get some work done, but no, I had to move to another apartment just as it was starting. After a few days unpacking and waiting for utility people I'm finally starting to get back into the swing of things.

The velocity/correlation analysis I've been working on still shows some promise. I've tried it on "real" simulated data and it is still able to produce discernible peaks from the state-space model of the disturbance. The problem is that the resulting velocity estimate varies depending on the number of delays in the correlation, essentially implying that the velocity isn't constant across the frame. These simulation are supposedly using a single phase screen, but since they're essentially black boxes for us who really knows what's happening. Its hard to know then if my method is return accurate velocity estimates.

Right now the idea is simmering on the back burner until I can get more state-space models. Another option is to use this "challenge data" from a conference we went to that is apparently the turbulence from flow over some kind of plate, but with a known, fixed velocity. The data is all stored in a gigantic text file though, so just extracting it is another project.

In the mean time I'm working on getting the adaptive controller working in simulink with the actual experiment. The last week or so I've spend looking at different ways to put disturbances generated from a SS model on the DM. The most obvious way is to project the desired phase onto some kind of phase poke matrix (maps the actuator inputs to phase, not slopes). In one approach I used the theoretical poke matrix from the manufacturer that is basically a model of the DM surface on a high-resolution grid of points. I don't actually have this for DM61, so in that case I used my estimated poke matrix multiplied by the phase reconstructor. Either one produces phases that seem to flow somewhat like the original model, although I haven't done any kind of analysis to verity that.

As an example of my precise control of Matlab's video functionality, here's the desired phase profile generated from the state space model, positioned on the same size grid as the WFS measurements



And here's the resulting measurements after doing a least-squares fit and applying the corresponding DM commands



They're indistinguishable I know. The fact that the actual measurements show anything that could be believably described as a "flow" is a major success in my book.

Moving blows.