Can I graduate now?

Finally finally have the adaptive loop working in the experiment, at least with a single mode. Turns out that the effect on the overall wavefront norm is difficult to see for this disturbance model unless you know its there. Its more clear if you just look the coefficient of the mode being controlled.

But the best way to observe the effectiveness is by comparing the PSDs of the modal coefficient. In the uncontrolled case (classical PI controller only), you can clearly see some color resulting from the disturbance input. In simulation the adaptive loop flattens this out somewhat:



To my surprise, the adaptive loop does an even better job whitening the PSD in the experiment:



Another thing to notice is that I compared the performance using the ideal and identified plants. The adaptive loop uses a model of the closed (classical) loop to estimate the disturbance input. In general we assume that the ideal plant is just an integral controller and a unit delay, since the phase reconstructor is chosen to be the pseudo-inverese of the modal poke matrix. To verify this I also identified a plant using n4sid and a few thousand samples of input/output data, and found the resulting transfer functions very identical. This is nice to know since the plant actually contains some dirty nonlinearities like saturation and rounding, so it looks like those aren't significant for now.

This is all for a single mode. The requirements on the plant in the multiply mode case are more stringent (i.e. a diagonal transfer matrix). Something is also causing this to run quite a bit slower than from an m-file, so that will take some coffee consumption to figure out as well.

7.12.10 [2]

Wow, 2 posts within 24 hours. This is what happens when you can't nail down consistent sleep patterns.

Advisor was intrigued by the comparison of the velocity estimates (see plot in previous post). Particularly, both lines have almost the same shape, and appear to only differ by the average slope, ie the velocity. I proposed that this is because the poke matrix doesn't account for the change in the beam size that's roughly proportional to the norm of the command vector. Relatively small perturbations are used to estimate the poke matrix, so the beam diameter is actually smaller for general random commands. A particular phase profile enters and exits the DM surface in the same time for either case, so if the actual beam diameter is smaller it means that the phase traverses fewer pixels for a given time period, ergo resulting in a lower velocity estimate.

I have no idea if that makes any sense since its around 2AM. In any case, its not clear there's anything I can really do about it other than estimate some correcting scale factor and apply that to every command sequence. Its also not clear if any of this velocity estimation stuff will make it in a paper or my dissertation, so I'm not sure its worth devoting my entire life to something that's basically a sideshow to the main event.

Anyway, tomorrow (today), I'd like to ignore this discrepancy for now and look at applying phases at twice to rate to see if I can measure twice the velocity. I plan on doing this by using the same sequence of phases from the SS model, but just applying every other command.

I'm also making some (theoretical) progress on implementing an optimal FIR filter in the actual AO experiment. I still have to think about what it means to do the calculation in the multi-channel case.

7.12.10

More stuff on the velocity estimation. I managed to run some disturbances on the experiments that originated from a state space model. Surprisingly, you can actually distinguish something that looks like "flow" in the resulting reconstructed phase measurements. As a bonus, the velocity seems to be relatively constant.

The velocity estimate from these measurements are less than what's predicted by putting the estimated phases (using the commands and the phase poke matrix) through the estimator, but just the fact that there's anything recognizable is a plus. I did, however, have to mask out only the center of the WFS image corresponding to the active region of the DM, everything outside of this is just distortion. Maybe something like this should be done in the AO loop as well.



Speaking of which, I really want to focus on getting the AO loop working in the experiment this week. So far I everything runs, but I haven't seen any improvement in the Strehl in either the Simulink experiment or simulation. A few things to try:

1. Compare predicted and actual disturbance measurements (w/ and w/o bias). This should pin down if the internal plant model is accurate. It should be after running n4sid on sample data. Theoretically, I think the MSE between these should converge at something like an exponential rate after the adaptive loop is closed.

2. Try different disturbance sources. Maybe the current SS system is just too close to white to be useful. Maybe try a simple FIR filter or different amplitudes.

3. Compute the optimal IIR and FIR filter using the known disturbance model and see if that makes any difference.

Getting this working, especially #3, is important. The stuff with the velocity and new SLM is just icing at the moment.

7.8.10

Things to do today and tomorrow:

- Rewrite correlation code to handle phase data on rectangular grids

- Map commands from a SS model to DM commands, and compare velocity estimates for SS model, output from SS model, projected DM surface profile w/ and w/o bias. Is there any correspondence at all between the DM surface velocity and the SS estimate?

- Moar subspace ID stuff. Calculating oblique projections using LQ factorization.

- Screw around with SLM more.

Fun.

7.7.10

Still progressing on this correlation/velocity estimate stuff. Clearly from the previous post, estimating the velocity at each stop is produces inconsistent results. I think the problem is that when the speed is relatively slow (<1 px/frame), consecutive frames look very similar, with only a few edge pixels changing. Thus there just isn't enough movement in the first few delays to show clear movement of the peak of the correlation image, maybe explaining why it takes a few delays for the estimated velocity to settle down to a reasonable number.

But based on how consistently the peak moves in that video I decided to just track its position as a function of the delay, instead of producing an estimate each time. Luckily, the peak position is very linear. Because the peak should move with the same velocity as the phase profile, I can do a linear regression and take the resulting slope as the velocity. The resulting estimate is close to the average of estimating a velocity each delay, but its more justified looking at a plot of the peak position vs delay.

This works equally well using the covariance matrix of a state space model to calculate the correlation image for each time lag. To make it even better I managed to vectorize the calculation so that Matlab doesn't yack all over the nested loops. It runs around 10x faster than before.

I'm not sure where all this is going. It seems to be working pretty well, but I'm not sure we'll be able to squeeze a paper out of it. Maybe if I manage to get results of flow using the WFS and the actual experiment that would be more interesting.

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.

5.30.10

I've been sidetracked the last couple weeks working on this idea of quantifying frozen flow layers. The problem is to identify how many layers are moving in a phase profile, and estimate their velocities. A common idea among some "predictive" AO controllers is to then use this information to generate control commands some number of steps in the future.

Of course, this only works when the velocities are constant and pretty well known, but it seems to be a common approach among certain fields. Based on some comments I've heard, they like it because it incorporates some knowledge about the physics behind the problem. I think deep down some of them just don't trust the completely black box methods that's common in hard core controls applications.

We typically use one of these feared methods to identify a state space model for the turbulence. One question that's bothered us though, is how can we extract the velocity and layer information? Since the controller developed from the state space is optimal, the velocity info has to be embedded in there, but since the states are a product of the ID it isn't clear how.

One approach people in the AO community have tried is to generate a bunch of image correlations from the data, and look for peaks. If the phase is composed of a finite number of layers moving with distinct velocities, the correlations between images separated by enough delay should develop peaks corresponding to each layer. In our case, we have a state space model. And while we could just generate a sequence of data and use these methods, I'd be cooler if we could identify the velocity straight from the system matrices directly.

Coincidentally, I've been reading this book on subspace identification, and it has a good review about calculating the state and output covariance matrices for a state space system. Its very easy to compute the covariance matrices for any number of time steps, so I started to wonder if you could compute the covariance function directly from these matrices. After much, much head banging, it turns out you can.

I don't want to reveal the exact details, but I'll just say even though its not theoretically complicated, its pretty cumbersome in the 2D case, and required many many cups of coffee and a nontrivial amount of cursing to figure out. I still haven't tried it out on real data, but in all the simple 2 layer, integer velocity cases I've developed it works swimmingly, and seems relatively robust to random similarity transformations to the state space.

5.17.10

Now that I can identify simple disturbance models from open-loop data, I'd like to try designing an optimal controller using the identified system. I think it should work out in simulation, but ideally I'll be able to implement it in the experiment and see some results. This is actually much more simple than using actual wavefronts and doing a multichannel problem; since the plant is particularly simple (with a slow enough sampling time), the optimal controller should do a pretty good job.

1. Make sure models can be id'ed using the disturbance model, probably using the 61 actuator modes constructed using the poke matrix.

2. Ignore the PI controller for now? Try to apply disturbances while the integrator is running and see what the results look like.

3. Come up with a script that calculates the optimal controller structure using the controller SS model. First by solving a WH problem, then also by solving a finite time LQR problem. Results should be the same with each.

4. Apply the controller in simulation and in the experiment if all goes well.

5. ....?

6. Profit.

The one wrinkle in all this it that controller and disturbance DM are using different sets of modes, so I have to think about the best way to unify them. Ultimately, I suspect I'll end up using the DM61 modes for generating disturbances, but since that process is basically opaque from the controller's perspective, all the ID and control will be done on the basis of the DM31 modes.

5.12.10

I feel like my brain's overheating from all the wasted processing cycles I'm asking it to do this week, mainly due to my shallow grasp of concepts I should know by now. The problem with doing several complicated dance moves simultaneously is that they all overlap into something that resembles a seizure more than a coherent motion.

1. Making headway in my subspace ID book. I found the presentation of prediction theory from a Hilbert Space perspective to be particularly illuminating once I finally got wtf was going on. Now embarking on several chapters on stochastic realization.

2. Now that I can roughly identify a noise model from input/output data, the question is how to construct the optimal controller. This is covered in a past grad's thesis that I'm dissecting; like all dissertations its terse, and lets the references do most of the talking.

3. We've struggled for some time for a way to evaluate layer velocities for a turbulence model given a state space realization if you assume "frozen flow" holds. In the past people have estimated the velocity by looking at the spatial autocorrelation of the WFS measurements and tracking the peak. I brought up the point that perhaps the steady-state autocorrelations could be derived analytically from the state space realization, specifically the state covariance matrix. Its not clear if this is feasible or if I was just high on lens cleaning fumes.

4. I'm also working on a midterm for the class I'm taking, doing some analysis of neuronal pattern generators using quasi-linear multivariable harmonic balance. Yeah.

Shits gettin real.

Backpacking: After Action

Some lessons learned:

1. Respect the toilet paper. Waste not the toilet paper. Cherish its many uses.

2. Snowshoes? That's for teh gayz!

3. On second thought, frozen boots are bad, dripping socks are worse.

4. Filtering is a PITA. Socks are not adequate water filtration devices despite their affinity for water.

5. No amount of caffeine withdrawal makes Starbucks a decent choice.

6. Sleeping on a slope sucks.

Inb4SID

I'm trying to gradually ween myself (and my advisor) off tinkering with my experiment and start working on actual controls. Before I can get to controller design I have to do some work on system ID; stuff more complicated than simple ARX models of the DM. Its been so long since I've actually taken any classes in this stuff that this means a lot of reading in the weeks ahead.

The reason for focusing on system ID is that one way to reject disturbances is to characterize the disturbance input as the output of an LTI filter with white noise input. Once you have that you can internalize the model in the controller and use it to reject disturbances "optimally." This is explicitly what an adaptive controller does, but doing the ID in a separate step has its advantages.

The immediate question was did the experiment have enough accuracy in reading and applying wavefronts to do this? To do this I cooked up a little Simulink file that runs white noise through a FIR filter and applies the resulting modal commands. The game is to read the wavefronts from this and reconstruct these filtered commands. With those and knowledge of the inputs, it should be possible to identify the FIR coefficients if the reconstruction is accurate enough.

To my amazement this actually worked out well; the reconstruction of the filtered commands was accurate enough to do a good job of estimating the filter with batch least-squares. The modes also seemed orthogonal enough that I could determine identify separate filters if a different one was applied to different modal channels.

For shits and giggles I stuck the RLS block in the Simulink model and was able to get it to converge to the SS error pretty quickly. You can see this in action by changing the filter coefficient half way through the experiment and watching it re-converge.

This is good news. Eventually I'm going to unleash a subspace ID algorithm on this biotch to identify even more complicated state space, MIMO models, but since I know nothing about that stuff its going to be a while before I catch up on all the reading. In the mean time there's plenty to play around with here. I'd like to see how well I can identify a multichannel FIR filter, particularly if only a limited number of modes are used in the ID. Also, I think I'd be good for the soul to try to code an RLS filter myself.

ARMAing

The general idea behind an ARMA model is to express the current output as a linear combination of past outputs (the autoregressive part), and current and past inputs (the moving average part). This essentially identifies a transfer function of some order for the system, and since the coefficients appear linearly, the "optimal" values can be found by constructing an appropriate least-squares problem.

I wasn't really interested in coming up with a complete model for the DM dynamics since its time constant is small compared to the sampling time I can get with the WFS. But is it small enough to be negligible when the experiment is running at full speed? The majority of AO papers consider a DM with insignificant dynamics, modeling it instead with a static poke matrix. This was muy bueno with me, except that when trying to identify a poke matrix I basically get garbage unless I insert a pause between applying a DM command and reading the wavefront.

Anyway after much reading, checking, rechecking and cursing I finally wrote a basic ARMA estimation script that organizes all the data into the right places and does the least-squares problem. Basically I gathered some number of DM commands and the resulting WFS measurement, and looked into the coefficients when a pause was included between sending the commands or not. To make things simpler I projected the slope vectors onto the space of actuators. In the ideal case, when the WFS measurements depend only on the current command, the first coefficient should be the identity matrix.

Amazingly, the data was clean enough so that this is actually what happens when I put in a pause before reading the WFS. What's interesting is that without a pause, when the WFS is read immediately after applying the commands, its the second coefficient that's identity, indicating that it takes essentially 1 sample time for the DM to achieve the desired shape. With no pause the sampling frequency was around 20 Hz.

Here's a comparison of the first 5 MA coefficients with a pause (top) and without (bottom. The AR coefficients turned out to be pretty negligible (as you'd expect). Also shown are the norms of the coefficients in each case.



This result seems to verify that the DM does indeed have some time constant, contradicting what everyone says about infinitely fast dynamics. In particular, the 0.05 time constant roughly matches what I found earlier when actuating the DM and capturing WFS frames at a high frame rate.



Incidentally the prediction error on new data is around 15% in either case, and not projecting the slopes into actuator coordinates results in the poke matrix instead of the identity.

The question now is whether or not its worth it to incorporate these dynamics into the controller, or just stick a pause in there and ignore it. Even with the dynamics the model is very simple, just a 1 sample delay with no other significant coefficients, so it shouldn't be hard to do. Of course, I say that now...

4.13.10

On Friday I got back from my first academic "workshop" up in Monterey. To my surprise it was actually informative, both in terms of AO and in witnessing the unique social interactions that take place at these things. My advisor's assertion that some of the people there were "world class pricks" turned out to be a good assessment of character in some cases.

But that's for another day. For all the interesting stuff I heard there, there were only a few thoughts that materially affect my work at the moment. Even though its April, there's more snow in the forecast for the mountains, so this week is bound to be a short one. Here's what I've been focusing on:

Fourier transforms. One presenter at the workshop extolled the benefit of using Fourier modes to do predictive wavefront control. A common theme among the talks was this idea of frozen flow; basically modeling turbulence as a superposition of a finite number of static layers, each moving with an independent velocity. Under this model, decomposing the wavefront using the DFT is beneficial since shifting a Fourier mode with a certain velocity simply involves rotating the (complex valued) modal coefficient some number of degrees. For a given coefficient, each moving layer would impart a certain periodicity related to the layer's velocity. Thus one could identify the layers by looking at the PSD of each mode and looking for spikes corresponding to this periodic behavior....I think.

DM ARX model. I've been meaning to do this for a while, but its only now that I think I know how to compute MIMO ARX models using least-squares. Of course its close to the scalar version, but I wanted to work everything out to make sure. Because I'm anal about verifying every segment of code, its taken some time to get the actual m-file written up. I finished the MA part on Sunday, and just finished the full ARX code a few hours ago. I'll test it all tomorrow.

Return of the SLM. One of the other grad students at this workshop had a working experiment very similar to mine, but using SLM's as disturbance generators. My advisor was intrigued, especially since there seemed to be an easy way to use it in Matlab, and it now looks like we'll be ordering one of these puppies soon. What exactly I'll use it for I don't know, but maybe I can put it to work mitigating the static bias.

Moar Modes

Sure enough, the problem with the poke matrix in this new configuration was caused by the beam size. With the bias voltage the beam was much more compressed than with a general random command. So when the bias wavefront was subtracted from the residual wavefront to get a measurement of the DM phase, it was only modifying the center of the residual.

I fixed this by adjusting the optics to make the beam larger when the bias is applied, something I probably should have done right away. The results look almost perfect, though slightly larger than before






Its possible I could make the modes even smaller by moving stuff around, but at this point I don't want to mess with it any more. I'll settle for Amish perfect.

The Happening

Back from the North, I've spent the last couple days using some new lenses to reduce the beam size. So far so good, and I've been able to reduce the un-molested beam to around 5mm in diameter, half what it was before. With this change almost the entire beam fits into the WFS measurement area I'm using (around 1000x800 px, usually sub-sampled).

Its taken some tinkering, but I've been able to get a recognizable poke matrix out of this configuration.





Notice how nearly the full extent of the modes are in the frame, much closer to the theoretical version. Its not all rainbows and puppies though, as you can see in this comparison between actuator influence functions (for the same actuator) using the small and large beams



Notice the depression surrounding the peak when the smaller beam is used. I would expect the peak to be narrower since the beam is condensed, but this is unexplained. Maybe related to that is the ring that often appears around the modes in the modal poke matrix.

I think this crap shows up because the beam diameter really changes when commands are applied, and the effect is more noticeable when the whole beam is in the WFS frame. Essentially, the problem is the assumption that each WFS sub-aperture measures the same area of the beam, independent of the command. In reality, the beam changes shape with a changed wavefront, so sub-apertures are actually measuring different parts of the beam each time a new command is generated. For small commands, or when the beam is much larger than the measurement area this isn't really a problem, but I think its what's causing the distortions here.

Surely someone must have noticed this before, but as far as I can tell from a 30 second Google scholar search ignorance is bliss, and no one's has the stones to address it. Its a tough problem since I have a suspicion the distortion isn't easy to predict analytically. I'm looking up a few papers on beam shaping based on deformable mirrors, so maybe there's a way to do some kind of pre-warping to the beam as a function of the command, sort of like pre-warping in the bilinear transform. Maybe then the sub-aperture measurements could be linked to a specific part of the beam and used to interpolate a wavefront profile. Maybe its possible to linearize this and make it just a series of simple transformations. Maybe I've had a few too many rusty nails while writing this.

Either way, el hefe thinks this might be a reason we couldn't generate a decent poke matrix from the HEL simulation we have and instead had to rely on a theoretical version. I shall vocalize my pre-warping idea to him tomorrow and report back.

Over and out.

3.11.10

Here's an interesting look at the different sub-aperture sampling resolutions compared to the ideal case using theoretical actuator influence functions



The clear take away from this is that the 9x11 array is essentially crap, and doesn't really provide much performance enhancement over the 18x22 case at the current camera frame rates. Also, it'd be nice to get more of the beam measured since there's clearly some peripheral detail that's missing. I've ordered some new lenses that should help do that...which means more alignment.

In the mean time, I'm still trying to do some kind of system ID using the experiment as a channel, but I'm running into some mysterious Simulink problems that haven't been sorted out yet. I think the idea is solid though; the basic idea is to generate a random command sequence by passing white noise through an FIR filter. The game is to identify the filter coefficients using only the data from the WFS and the original white noise sequence. This is essentially just a basic channel identification process, except the experiment is shoe horned in between. In a perfect world the WFS would be able to perfectly reconstruct the modal commands exiting from the FIR filter, thus identifying the filter coefficients is just a least-squares problem. However in this case the original modal commands are estimated from the WFS data (the estimate is itself a least-squares approximation based on the identified poke matrix). The question is how close will the FIR estimate be given the finite resolution of the WFS? How would changing the WFS resolution affect convergence if a LMS or RLS algorithm is used instead of just a batch process? Does this even make sense?

I was attempting to explain this to my advisor this afternoon but he instead thought I was trying to identify a FIR model for the DM itself, since it looks like there are some dynamics to it after all. This actually might not be a bad experiment to try either. The simplest case would involve identifying a moving average model for the DM, i.e. the current wavefront sequence would be some linear combination of current and past inputs (with a poke matrix stuck in between). If its true that the DM dynamics are negligible, then the MA model should only have order 1. On the other hand it probably doesn't make sense to try to identify a full ARMA model.

Experimentally, the problem with this is the frame rate of the camera. In the past catching the mirror dynamics required frame rates higher than what I'm using right now to read from the WFS, so I might have to use a pretty reduced measurement area to see anything interesting. This might not be a problem though, if I'm apply random commands to the entire mirror surface. I wouldn't even have to use the modes necessarily since I could do a multichannel identification based just on the number of lenslets used.

Anyway, tomorrow I leave for Wyoming on a family vacay, so I'll have 32 hours of driving over the next week to iron these issues out en cerebrum before getting to work in front of the keyboard.

3.9.10

Downsampling the sub-aperture array worked pretty well in reducing the computation time for constructing the slope vector. The image itself is still pretty large, around 900x900 px, but this saves me from having to screw with the beam diameter further. An image of that size allows for roughly a 36x44 lenslet array. Sampling every other sub-aperture essentially doubles the speed; enough such that capturing an image and computing a down sampled, 18x22 dimension slope vector can happen at around 30 Hz, near the 40 fps frame rate of the camera at that resolution/shutter speed. I can get even closer by going to a 9x11 array, but the savings aren't great, and the resulting phase profiles start to look pretty crappy at higher spatial frequencies.

I think this is about as fast as I can expect to go without any (drastic?) changes to the beam size or any additional info on the DM dynamics. The DM presents an interesting problem. I can really only see the dynamics with a very high WFS frame rate (100 fps+), which means a small image with just a few sub-apertures. The trouble is that getting meaningful modal information is hard with so few sub-apertures, so computing an actual frequency response using the modes as control channels would be tough.

I want to move on to some controls applications. One thing I want to try first is to generate random disturbance commands, pass them through a low order FIR filter and apply them to DM61, first with a single modal channel, and the more. Eventually, I'd like to read the resulting open loop WFS data and try to identify the FIR coefficients in some way, either adaptively or using a subspace ID algorithm. This is basically the first step in designing a time-invariant LQG controller, the topic of the first paper I can probably get out. One interesting question in an adaptive situation would be to investigate how the convergence rate is affected by the density of the sub-aperture array. How badly does down sampling screw up the ID? I suspect its significant at higher resolutions.

3.4.10

I talked to my advisor about my concern that I don't have any papers on deck now that my experiment is essentially in place. He didn't seem that worried, so I guess that's all that matters, and assured me that we'd get things going soon enough. He mentioned that the easiest, publishable experiment to work towards would be designing an LQR controller using an identified noise model. However, he's still stressing the idea of running the experiment in real time, so I'm going to have to either make some real advances there, or exhaust all the practical possibilities.

I've managed to get the Simulink version of the PI controller working about as fast as the M-file version. Nominally, sending commands to both actuators each iteration, I can run the thing around 4 Hz. Pretty pathetic, but there are a few things I can work on to speed things up.

WFS: the current sub aperture array size, around 30x45, encapsulates most of the actuator influence functions for the beam size I'm using right now. With partial frame mode, I can capture images of that size at around 45 fps. Since I'm no where near that, and reducing the beam size further would be a pain in the ass, this serves as an upper bound on performance for now. Still, with that many lenslets, computing the slope vector can only be done around 10 Hz. This number of sub apertures is much much higher than what others use, so one idea is to down sample the image and compute centroids for a set of lenslets, like every third or something. I think this would be a linear improvement in the performance of the slope vector calculation.

DMs: the mirrors clearly have some dynamics, so there has to be some pause between sending a command and reading the WFS. When computing a poke matrix, a pause of less than 0.08s yields crappy results, but the PI controller works pretty well when there is no pause at all.

Tomorrow I'd like to look at the down sampling idea since that shows the most promise. There's also the idea of doing the slope calculation in an M-file S-function instead of an EML block. I doubt that'd really improve things much, so its on the back burner for now.