Showing posts with label SPGD. Show all posts
Showing posts with label SPGD. Show all posts

Sunday, July 19, 2009

5.19.09

Last weekend I ran a couple long SPGD experiments with and without the SLM to see if it had any noticeable effect on the performance. I ran each lasted for around 10,000 iterations, and since I can only update the SLM every 3 seconds they each took over 8 frickin hours to run. I feel like a biologist.



For the "w/ SLM" case the image was set to a focus with a sinusoidally varying intensity such that the maximum phase distortion occurs at the center of the focus at the peak sinusoidal amplitue. Maybe I'm just cynical, but its not really clear to me that the SLM has any effect. Its nice the the algorithm can sort of maximize the image cost function (J), ignoring those unexplained spikes, but its hard to distinguish any difference between the 2 cases. Control starts at k=1000.

Here's a close up of a section of the uncontrolled iterations.



The SLM obviously has an effect on the objective function, but its not much, and it doesn't look like that effect more than the noise from calculating the image objective function. What is clear though is that unless I can speed things up, using the SLM at all is totally impractical. This 3 second bullshit can't go on if I'm going to really be using it.

Wednesday, May 27, 2009

1. Cut a Hole in a Box

Finally received all the cables to install the SLM. In one final kick to the balls the connector for this new cable was too wide for the back of my PC case, so I had to pry this pointless plastic cover off the back. Why Dell shields their cases with useless crap like that I don't know.

I did some basic realignment and it looks like everything is attached correctly. Tomorrow I'll do some testing to see if the SLM's producing the phase changes its supposed to. After that, I need to figure out a way to get it working from Matlab.

In other news I've been working on the SPGD simulation with dynamic colored noise and multiple channels. To my surprise it actually works pretty well if the noise is kept to around 1% of the Nyquist frequency, but my adviser tells me this is pretty good. The idea is that by using the Strehl as the cost criteria potentially allows for the use of a photodiode instead of a full wavefront sensor. Thus, performance would probably only limited by the bandwidth of the DM controller, rather than the WFS framerate. Ideally, this would mean that sampling rates in the KHz range would be possible (and cheap).

Here are some typical results using 3 channels. More channels seem to work, but tuning the parameters is a bitch. In particular, the spikes in the cost function can be reduced by increasing the size of the perturbations, which (I think) get swamped by the disturbance sequence with higher noise variances.



Control begins at iteration 5000. This plot doesn't show the change in the cost function due to the dithering at each step to estimate the gradient. Its hard to tell from the plot, but the controlled cost function has an average value that is around 40% of the uncontrolled average. Note that these results don't look as good as those a couple days ago. In those results I forgot that I had a sinusoidal disturbance in addition to the colored noise sequence.

Thursday, April 02, 2009

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.

Wednesday, April 01, 2009

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.

Thursday, March 26, 2009

3.25.09

Still playing around with this moment of inertia idea. There've been some hiccups with the details along the way, but I think I can get it to work somewhat with more tinkering. Whether or not its better than just the max intensity or something like that remains to be seen.

I also started thinking seriously about coming up with a barrier method optimization based on the poke matrix. This should be fairly straightforward to implement one I get all the math bs worked out. The algorithm could be run without any output to the DM, or each command encountered on the central path could be tested experimentally and the resulting wavefront used as a stopping criteria.

Yesterday, because my parking pass for the quarter expired, I had to park literally in another zip code and walk. And this is during spring break too. Why does renewing a permit require 40,000 signatures and forms?

Tuesday, March 17, 2009

3.16.09

So far, feeding back the max intensity in the SPGD algorithm has resulted in crap. Basically the intensity just fluctuates randomly around the initial value no matter how many iterations or perturbations. Either the gradient isn't being identified correctly or the measure of the max intensity doesn't provide sufficient information for controlling it.

Irritatingly, even though the intensity isn't maximized the wavefront variance (which is just measured, not used for control), is reduced as if it were the objective. This suggests that the algorithm might be, in both cases, just pushing all the actuators to their maximum value, which happens to result in a relatively low WFS variance.

Tomorrow I'll test both cases using the first mode only. Doing the same with the PI controller should indicate what the optimal value is, and it definitely shouldn't be at the maximum value. If the SPGD algorithm surpasses that value in steady state I'll know that something's wrong.

I spotted some lady with a book on "Medieval Drama" today in Taco Bell. It was thicker than my adaptive filtering book.

Wednesday, March 11, 2009

3.10.09


It turns out that using the full wavefront norm as the cost function works pretty well with a limited number of control modes. Previously, if only the first m modes were used, I was projecting the slope vector S onto the modes giving the cost function J=U(:,1:m)\S, where U is the modal poke matrix. Apparently this representation fails to capture enough detail in the cost function perturbations to really achieve good convergence.

As a result convergence is pretty good when using a limited number of modes for control, especially when enough perturbations are generated per iteration to allow a least-squares approximation of the gradient.



Once I get a faster WFS this algorithm should be golden. First though I have a host of tests to run to characterize the DM in more detail. Is the response really linear wrt the square of the voltage commands? Does superposition really hold? Should I use the given influence functions in estimating the poke matrix? We shall see.

Next I'm going to try constructing a cost function using image data instead. Again, this is something that's been done in papers so it should be possible here. The first step is to find a function (eg peak intensity, intensity variance, etc) that has a positive correlation with the WF norm that I'm using now.

Only one more 236 lecture left in the semester. How will I get by without my biweekly dose of olfactory stimulus? I might have to start huffing some mouldering cheese as a replacement.

Tuesday, March 10, 2009

3.9.09

Was able to get the modal SPGD working using a least-squares estimate of the gradient, instead of the stochastic nonsense in the original algorithm. Its not clear yet if this is a superior method or not, but as far as I know it doesn't depend as explicitly on the statistics of the perturbations (the original algorithm required delta correlated perturbations).

Convergence seems to be very dependent on the number of modes used. Even lowering it from 31 to 25 results in crap steady-state performance. I might try feeding back the non-modal wavefront norm as the cost function, rather than the wavefront projection onto a number of modes, since its possible the problem is there, rather than the gradient estimation. This might make more sense since there's no advantage to approximating the cost with a limited number of modes when you can get the complete value for free.

In general though steady-state performance isn't as good as with the integral controller, and seems to depend heavily on the gain. This seems to indicate that either (a) the cost function truly isn't truly convex or (b) the estimate of the gradient is too shitty to converge to the theoretical minimum. The real advantage, if there is one, will be in optimizing from a cost function that can be measured from a regular camera, and not a WFS. There are some papers where this is done, so I should be able to do it eventually.

Ideally, when I have the better sensor, an accurate poke matrix will let me calculate the optimal actuator command without any iterating at all.

Thursday, March 05, 2009

3.5.09

More 236 lecturing today...more holding my breath and breathing through my mouth. We're finally going over inequality constrained optimization, which is exactly the problem I'm facing now for correcting static disturbances. I still think it would be bad ass if I could one day implement some kind of interior point algorithm in real time, even if the performance would be crap with dynamic noise. Some other stuff:

- Finished writing modal spgd script. Performs similarly to the non-modal case; not surprising since using all the modes reconstructs the commands exactly. The main difference is that the cost function being fed back is now the norm of the modal vector, not simply the wavefront error itself.

- Normalizing the estimated gradient helps performance greatly, although so far its still not as good as when using only positive perturbations. Naturally the gain has to be changed appropriately, but with these descent algorithms, the direction is really what matters. Here's a comparison between the unnormalized (v=0.011) and normalized (v=100) cases:



- I'm now looking into estimating the gradient using least-squares, but I'm not sure if this is equivalent, worse, or better than the current method. Comparing methods by estimating a known gradient (of a random quadratic function) wasn't conclusive. Theoretically, 31 perturbations would be needed to really identify the 31 entries of the gradient, thus requiring lots of time to capture each image. However if m modes are used instead, the gradient would only have m terms that need to be identified, so there might be some benefit to using the modes there. All this will hopefully be faster when I have the new SH sensor.

- If I can find a good way to estimate the Hessian at each iteration, I could use the full Newton's method with all the corresponding bells and whistles. I should probably look up some more recent papers.

Friday, February 27, 2009

2.27.09

Thursday's always a scramble to wrap up the 236 assignment into something resembling a coherent set of solutions. Usually if I haven't solved a problem by now, this means rewriting the question to look like an answer. This comes on the heels of an already lengthy 2hr 236 lecture, so there normally isn't much time left for poor 'ol research. Yesterday was typical; I probably got in a solid 30 minutes actual work on the project.

I'm starting to think that my problems with SPGD have to do with coupling between the control commands. I'm going to try using modal commands next but that will require a decent "modal" poke matrix. Today I fashioned a basic system ID script to do that, and I'm now investigating if I can use the norm of the projection of the wavefront as an objective function, instead of the norm of the wavefront itself. This should be fine since its what I'm using in the PI controller. Next week I'll try actually implementing SPGD with this poke matrix.

Also, to the person behind me in 236: honestly is it that hard to slap on some deodorant in the morning? Seriously, if you can afford those fancy Jesus sandals to go with your black dress socks, surely you can spare some change for a speed stick or something. The room is small and cramped, and we're in there for 2 hours. Think of the children man!