4.23.09

The parts that I need to install the SLM haven't arrived yet, but I've started reconfiguring my setup to accommodate it anyway. In the mean time, I'm using the new WFS to make some basic measurements of the laser source by removing as many elements as possible. I have no idea how the lens on the end of the diode affects the wavefront, so I'm trying to collimate the beam as much as possible adjusting it and passing the beam through a relay telescope (to expand the beam) only.

Assuming I get my order, I think a reasonable timeline for all this is to have the SLM/software installed by the end of next week and putting out some basic commands. Hopefully another week will be enough to get some reasonably realistic dynamic disturbances going, but its condition is unknown, so this might be wishful thinking.

In addition:

1. The full rank phase reconstructor I wrote appears to work reasonably well for spot measurements of the phase. Even though I know the pixel size (in m) and the focal length of each lenselet, I haven't entered it all in to get actual units yet, but that's a minor problem.

2. Using this phase reconstructor, I've pretty much confirmed (finally) that the mirror surface displacement (and hence wavefront phase) is linearly proportional to the square of the voltage commands. I did this by comparing the maximum phase value to a constant voltage command. Although not perfect, the curve is more linear than anything else. I'd like to try this again using just the center actuator when the system is reconfigured.

3. The new WFS is much faster, which means less bullshitting on the internet and more experiments. There is much less noise (since there's no crack running through the lens), so single frame measurements seem to be good enough. Combined with the increased frame rate, the control loop runs at 2-3 Hz. Playing around with the MATLAB frames per trigger setting, I might even be able to characterize the full response of the mirror (rise time, etc), since some transient response is definitely visible on the target camera. The input/output values in that case would be in terms of modal commands/projections I guess.

As the system moves to its final form, I'm beginning to shift away from the optics nonsense and get more into the adaptive control, which is really what all this is about anyway. Unfortunately, with that comes the absolute shit storm of material I have to review. Several of the books I'd like to review have Bible-like density, so there's a lot of reading to be done over the next few weeks.

4.17.09

Ran some preliminary control experiments using the new sensor and got some pretty good results. Here's the wavefront slope norm and associated control values using 5 modes and essentially the same gains as with the old sensor.

Not only is the control metric reduced substantially, but none of the actuators saturate. This is muy bueno since it means we can worry about reducing dynamic disturbances without automatically hitting saturation. I haven't aligned the optics yet to reduce the static bias like I was doing before, so I suspect that further messing with the alignment/relay lenses should be even more beneficial.

I ordered some lenses and other crap that I'll need to install the spare SLM we have as a disturbance generator. By next week I hope to have the thing installed and the experiment in its final configuration, even if we decide to use another DM instead. My goal is still to have the SLM working to actively screw up the beam by the end of the month. Then the real fun begins.

Even better, I got my tax refund today. lol tea parties...

4.16.09

I finally got the wavefront reconstructor working by using a different geometry from the Southwell paper. This particular model averages the slope vector, rather than the phase, so there is only one zero singular value corresponding to a constant phase. Essentially, this method involves solving an equation Hp=Ds for the phase vector p. D is a matrix that averages the slopes in s, thus the least-norm solution in MATLAB is given by p = pinv(H)*D*s. However, calculating this pseudo inverse is still glacially slow, so we can make H full rank by requiring the phase to have zero mean, and then solve using QR factorization: p = H\(D*s). (Recall that if H is full rank there is a unique solution).

Because H and D can be constructed ahead of time, reconstruction is pretty quick: around 1 sec. for most slope vectors. Fast enough to be useful for visualization, but probably not for realistic control. There are a few test cases I came up with where solving the equations takes several minutes, but so far actual measurements seem to be ok.

Because everyone likes pretty pictures, here are the reconstructed residual phases (total minus the bias) when the first 15 DM modes are applied:


Pretty nice having a sensor with such high resolution. Remember that these are the actual measured phases, not merely the predicted DM shapes from the modal commands. These modes are actually the columns of the modal poke matrix, so its nice to know that the DM and sensor are actually capable of resolving such high frequency phase profiles.

Ahh what the hell here are the next 15 modes:

4.14.09

This new WFS has an order of magnitude more sub-apertures than the webcam when the entire frame is used, so almost all of my files dealing with sensing has/d to be changed. Not only do they have to deal with the extra slope measurements, but just processing such large images quickly is turning out to be a challenge.

The new code for calculating the intensity centroids runs fairly quickly, around 8Hz, but I think looping over each sub-aperture in the image is unavoidable. Originally, I thought there might be some way to write the entire calculation as a single linear transformation, since loops in MATLAB run like frozen molasses in comparison. However because each centroid calculation requires a division by the total intensity across the sub-aperture, its clearly a nonlinear operation. As an obvious counterexample, if the image intensity was doubled while the phase was held constant, the calculated centroids should (theoretically) remain the same since each centroid calculation is normalized by the net intensity. Therefore, there is no matrix that maps the (vectorized) image to the slope vector. Even if there was, it'd be huge anyway.

Reconstructing the phase from the slope vector is turning out to be more of a challenge. Following the Southwell paper, there is definitely a linear model in this case, Hp=s, where p is a vector of phase points and s is the slope vector. H is is a matrix that averages the phases in some way to produce the slopes based on some geometry. The problem is that in my case H is a very large sparse matrix, around 4000x2000. Calculating the pseudo inverse takes several minutes, thus p=pinv(H)*s is not useful for real-time calculations. Using p=H\s works fairly quickly since it uses QR factorization, but it doesn't yield the minimum norm solution (pinv does).

It turns out that there are 2 phase patterns that yield zero slope, i.e. H is rank deficient by 2. Looking at the SVD of H, these 2 patterns correspond to a constant phase, and a checkerboard patten. The constant phase problem can be eliminated by requiring the phase to be zero mean (by adding a row of ones to H and a corresponding zero entry in s), but I'm not sure how to get around the checkerboard as its basically just a fact of the equations for averaging the phase points. Because of this, when p is not the minimum norm solution to Hp=s, some component in the null space of H is present, meaning that some of the checkerboard pattern shows up. This is annoying because its high frequency, and makes the reconstructed phase look quite jagged. Fortunately reconstructing the phase in real time isn't really required for control, so fixing this is a low priority for now.

I also wrote a simple little script to plot the x and y tilt components of the slope as a bar graph in real time. This is useful for aligning the tilt of the DM, especially since the AOS software that came bundled with the camera runs around 1hz if the entire frame is used (probably because of this phase reconstruction problem). I'm thinking of adding the projection of the slope onto the focus mode as well so I can correct that similarly.

New Sensor

The new wavefront sensor finally arrived today. I spent the day reorganizing my setup to acommodate it, but since it has many more lenselets than the previous sensor, there's quite a load of code that needs to be rewritten to use it. That'll be the task the next week or so (hopefully).

This came just in time as I was wrapping up my SPGD stuff. The conclusion there is that the algorithm works well when the wavefront norm was is as the objective function. Not a surprise since, according to the model I'm using, its a convex function of the actuator commands. It also works decently when the variance of the beam profile image is used. I altered the algorithm as it appears in Voronstov's papers to produce a least-squares estimate of the gradient, rather than rely on the specifics of the perturbation statistics. Further, orthogonal modes can be used to parametrize the actuator space, thus limiting the number of random perturbations that must be used to provide a gradient estimate.

There are, however, several disadvantages:

1. Gradient algorithms like this will only perform consistently well on convex objective functions. When the maximum intensity is used as an objective, the most obvious cost function for example, the lack of convexity causes performance to vary greatly on the initial starting command.

2. Even when a small number of modes is used, each iteration requires numerous evaluations of the objective functions to estimate the gradient. At least in my experiment, accessing the camera was by far the most time-consuming operation as the sampling rate is effectively limited by the frame rate of the camera/WFS. Worse, using something like the image variance required a composite intensity map composed of several images at different exposures. This problem could be solved by using something analog like a photodiode, but then the convexity problem arises.

3. Using the gradient in this way is essentially a method to solve an unconstrained optimization problem, and its not clear what the best way to handle actuator constraints is in this situation. This is critical in my case; since the static disturbance lies outside the range space of the DM, many of the actuators frequently saturate in steady-state.

4. Its not clear how the algorithm would handle dyanamic disturbances, but I get the feeling that performance would suck unless they were extremely slow. Maybe a stochastic term could be added to the objective function to help this.

4.2.09

Here's a comparison of the different objective functions I've been playing around with. Clearly the maximum intensity sucks, flat at both the minimum and maximum. The moment of inertia (J) works well, but requires quite a shitload of filtering and thresholding to purge all the noise. The std2() function also works well, and even has a nice distinct peak value. Ultimately, although I've spend a lot of time on the moment of inertia, the std2() objective is hard to ignore for its simplicity.

To my amazement, it wasn't hard to get the SPGD controller working with this objective function, even with multiple modes. For the first time I was able to maximize an objective function using only the image of the beam profile. Exciting I know. Convergence is pretty shitty in this case, but I think it can do better with a larger control gain. In response to the questions posed yesterday:

1. Multiple modes works!

2. Still unknown, but its close.

3. Slight improvement when log(std2()) is used, but it isn't necessary or dramatic.

4. Should be possible.

Progress

This plot here is finally a sign of progress. I had the idea of using the variance of the image as an objective function before, but for some reason the standard var() command on the vectorized image I(:) didn't work well. I stumbled on the std2() function while looking for ways to filter the image to use the moment of inertia idea (which I still think has some promise).

With a single mode (constant command across all actuators), the standard dev. of the image peaks nicely around a maximum, and unlike the max intensity the curve has nonzero slope for all command values (see 3.23.09). I'm not sure yet if the maximum corresponds to the maximum intensity, but even if it doesn't then some linear combo of the 2 should work well as an objective.

Some things to look into tomorrow:

1. Multiple modes: this is the big question. Just because the std2() function is smooth for a single mode, there's no guarantee it behaves nicely when multiple modes are used.

2. Max intensity vs. max std2(): do they correspond to the same value? I know they're close right now, so some linear combo of the 2 should work nicely.

3. Log-concavity?: the plot of std2 vs. u (the command constant) looked almost Gaussian, which is log-concave. Maybe this is too? If so that might dramatically improve convergence.

4. Speed up convergence: right now it sucks.

Also, there's no possible way to make canned tuna into a satisfying meal. That is all.

3.31.09

Made some incremental progress on the interior point optimization idea but still can't get it to work completely. However, I was able to set the problem up and solve it using CVX, a matlab convex optimization toolbox we used in EE236. Its too black-box to really use for research, but it does spit out a command vector that satisfies the constraints. When the optimal command is applied however, it doesn't really minimize the wavefront variance a tremendous amount, definitely not as much as the PI controller in steady state.

This is probably due to the crappy poke matrix, which has an estimation error around 20%. I get the feeling that the new WFS we have on the way will solve this problem, so I'm putting the interior point idea on the backburner until it arrives. If that doesn't help, another option is to solve the optimization problem for a family of posssible poke matrices. This would still be convex since we're talking about the pointwise maximum of a convex function that is parameterized over a set.

Until then I'm going to continue messing around with the SPGD stuff. I'm learning about some alternative first-order optimization algorithms now that might be interesting to try, since the current gradient descent algorithm appears to be one of the slowest first-order methods out there. It might also be possible to estimate the Hessian of the objective function, allowing the use of a second-order method like Newton's.