Demo

In anticipation of my Qualifying Exam in 2 days, I've created a working demo of my experiment

All work and no play makes jack a dull boy

Spend too much time doing technical writing, and pretty soon you start thinking in proposal-eese.

The girl over there is pretty hot [5]. However, two prominent features preclude her from attaining optimal attractiveness: her diminutive height, and her apparent predilection for undesirable Australian footwear. The former of these is alleviated by her sitting position. The latter, however, is a consequence of cultural differences and cannot be mitigated directly [14].

A Question

Q: So what do you plan on doing after you graduate?

A: Enjoy not answering stupid questions about what I plan to do.

...can't wait for all the family gatherings coming up.

An Update

I finally charmed enough professors into being on my Ph.D committee. The motley crew consists of 3 controls people from MAE and one optimization prof from EE. I deliberately avoided having anyone with too much background in optics to avoid any potentially embarrassing questions, and I really want to emphasize that this is more a controls project than an optics one.

Since it looks like I'll actually be able to do my Quals this quarter, experiments have basically been nonexistent while I work on my prospectus. I'm trying go heavy on the detail to make things easier when its time to write the big boy, and right now I anticipate it'll clock in around 40-5o pages. Bigger than the average prospectus maybe, but I have been plugging away at this for some time after all. Its actually nice to review over everything at one time and see how much I've done...and how much I still have to do.

Graduation in 2010? Maybe not so far fetched after all.

Dear Diary,

I spent most of today talking with my advisor about the ability of the DM to reproduce the actuator modes. He seems suddenly interested in this even though identifying a modal poke matrix is something I've been doing for months. At least he admits his obsession with modes is "a sickness."

Yesterday there was some concern that, even though there are only 31 actuators and hence 31 degrees of freedom, somehow more than 31 modes were being produced through some nonlinearity. We looked at this problem by applying a few hundred random commands and computing Karhunen-Loeve modes for the resulting phases and/or slope data. It was hard to tell from the eigenvalues of those modes what exactly was going on, but it looked like there were far fewer than 31 principle components that had a significant contribution to the phases. Even though there were nonzero values past the 31st largest eigenvalue, there is definitely some funny business going on with the rounding, pixel error, and other nonlinear noise affects that could be contributing.

On the control front I'm trying to learn as much as I can about Youla parameterization. Of course, my idea of combining this with adaptive filtering algorithms is about 10 years too late. Still, its a relatively unused technique and there's still some potential for exploration there. Even if I don't end up rewriting the adaptive controller code our lab is currently using, I think its important to know what's going on under the hood.

We've been experiencing all four season in one week here. I need cold weather.

10.28.09

Here's a crappy video of the total, tilt removed phase as its corrected by the PI controller.


Quite amazing considering the crap I was getting before. Most of the bias error is concentrated in the focus mode, and its important that note only is the phase largely corrected, but the actuators don't saturate at all.

Of course adding tilt screws things up. Even though the DM clearly attempts to correct those errors, some of the actuators quickly saturate. Manually removing it is difficult since the large distances in my setup make it extremely sensitive to even someone touching a mirror. There are three options for dealing with this:

1. Ignore tilt completely. My preference, and not entirely unrealistic since it is often handled by a separate tracking loop anyway.

2. Add a steering mirror. Probably tougher than it sounds, would require another beamsplitter and probably a month of playing around.

3. Use the disturbance DM. The disturbances are largely free of tilt and probably don't saturate the mirror on their own, thus the tilt modes on the disturbance mirror could be used to correct for some of the overall tracking error of the system.

For now #1 is the only option. Word on the grapevine is that another package is on its way, so hopefully it contains my second mirror. In the mean time, here's what I want done tomorrow:

- Finish implementing an RLS adaptive equalizer example in Simulink
- Test out/modify the existing Simulink files to run the PI loop
- Work on my prospectus
- Look into committee possibilities.

Harder, Better, Faster, Stronger

Finally got the faster DM control code working, only 3 months late! It does make quite a difference, as you can see comparing the response to the original function:

Here's the norm of the wavefront error averaged over 100 different random commands applied with both versions. Its startling how slow the old script was; a pause of 0.5 seconds wouldn't be too conservative. Even with a new script though it looks like some pause is necessary since, although commands can be sent around 100 Hz, actuation doesn't happen until at least 0.1 sec.

You can also see this when looking for actuator decay. Here's the max displacement of each actuator. Note the ~0.1 sec rise time is the same regardless of the actuator unlike before:

Compare this with the similar plot from 10/22. Ultimately I might be able to get away with a pause less than 0.1 sec depending on the application, since it does put a limit on the speed of the overall system. I'm still amazed just how accurately the DM is able to reproduce the modes, here's mode 30 for instance, lookin snazzy:
Mmmm, deformable mirror pr0n...I bet no one's ever said that before.

Ludicrously Good

The refurbished DM came in late Monday, and I finally got all the glass aligned and working today. I've switched to using Galilean telescopes to resize the beam to keep the overall path length small, and the results so far seem to be pretty good. I tested the DM itself for the first time today and the results seem to be almost absurdly good compared to the crap I was getting before.

Here are the actual influence functions for actuators 1-31 (there are 31 total) taken from the columns of the poke matrix:



Each one is almost suspiciously clean. There was a significant pause between applying the command and capturing the wavefront, so it doesn't look like I'm having the problem with actuator decay like I was before. The columns of the modal poke matrix are even more impressive:



Even the high frequency modes are recognizable and look almost simulated. I haven't had the balls to look at the reconstruction error yet, maybe tomorrow. Even better, there doesn't seem to be any actuator decay, shown by looking at the plots of the peak displacement




Compared to the results from Sept. 9 with the old DM this is golden. Note how higher numbered actuators take longer to respond). Right now the WFS is using a lot of subapertures to capture the wavefront in relatively high resolution. After the DM is vetted I'll swap out the optics to go back to a reduced frame and higher frame rates. Hopefully the higher resolution DM for generating disturbances will show up soon as well.

Tomorrow more testing. I'd also like to get the new (faster) DM control code working, which was the original motivation for everything that's gone on the last 3 months.

10.15.09

I finally got the new laser late Monday, just as I was about to call and see what the dillio was. Tues. was mostly dedicated to getting the spatial filter aligned, usually quite the bitch apparently, but some online resources were really helpful and I can do it in a few minutes now. Since then I've been going slowly with the realignment, especially since a package (with mysterious contents) was dispatched from AOS today. If the new DM's arrive then I can finally assemble the (hopefully) complete system. How many times have I said that? So far this laser is much easier to work with. I think the asymmetric divergence of the diode laser was really screwing things up.

Other than that I spent most of last week learning LaTeX while working on my prospectus. Just like shaving and wearing matching socks, its something every graduate engineer has to learn to do at some point.

Beware the time vampire

If your boss bought some equipment from ebay with no obvious utility to "play around with," what's the worst thing you could imagine? How about an impenetrable metal box the size and weight of a small fridge?

Oh wait, it's not impenetrable, there's a 1 inch slot on the top.

10.1.09

Shit I can't believe its October already. I feel like I've basically been a waste of precious government resources the last year, but I guess that's just the pace research moves. This blog has helped though...helped me realize how much time I've wasted on certain ::cough::spgd::cough:: algorithms.

I finally ordered a new HeNe laser like I always wanted. Its going to require some substantial changes to the glass in my experiment so I've decided not to waste any time messing around with my current setup until I get it. The diode laser spot was just too messed up by the time it reached the WFS to provide useful data. The problem, I think, is that the spot divergence is inversely related to the spot magnification, and diode laser spots diverge asymmetrically. The result was far from circular after passing through so many optical elements, and as a result the accuracy of a measured wavefront was seriously suspect.

I hoping it arrives next week. I'm using the down time to get outside of the lab and reacquaint myself with some long rusty controls material. I'm really interested in eventually trying some adaptive Q parameterization, but that means I have to know such riveting concepts as coprime factorization and Bezout identities.

Plus, the ratio sucks in the engineering buildings. Outside classes are in session, the sun is shining, people are out and about...its no time to be stuck indoors with a bunch of lasers and postdocs.

Times they are a changin'

Here's a dandy chart showing the decrease in frame rate as the WFS image size is increased. Each sub-aperture is around 22 px across, and each pixel is around 6 um, so that gives you an idea of the beam size necessary. I also varied the shutter speed, but this should obviously be set to the minimum value necessary to see the centroids.



Aligning the beam is turning out to be problematic because the divergence is significant as the beam size shrinks. The good news is that a windfall in our equipment budget means I'm finally getting a HeNe laser like I always wanted. expanding it is slightly more involved than with the diode laser I'm using now, but I should be able to clean it up using a spatial filter and get a pretty nice spot.

As a matter of fact, we also ordered a new DM to use in place of the retarded SLM I've struggled with. The new DM contains around 60 actuators compared to the 31 in the current model. It might seem odd to use the higher density DM as a disturbance generator, but in RL atmospheric turbulence is always going to generate higher (spatial) frequency distortion than can be corrected with a finite actuator DM.

This basically means that all the active components of my experiment are going to be repaired/replaced in the next few weeks. I really really hope that's it because frankly i'm tired of dealing with all this optics shit.

A word about speed

Even with the latest improvements its unlikely that I'll every be able to run my experiment fast enough for real real time (need 10's of kHz for that). Still, 50 Hz is better then 3. There are several factors that affect the temporal sampling rate of my experiment. Most of them are interrelated, so it helps to sort out just what impacts what.

Essentially, there are 3 time-comsuming operations that have to be completed each iteration. Ignoring the time to calculate control signals, these are: Commanding the DM, capturing the WFS image, and processing the image to generate the slope vector.

Sending DM Commands:
This is basically fixed around 100 Hz currently. I'm still not sure if the actuators actually reach their steady state positions at that speed, hopefully I'll have that sorted out next week. The unknown here is that the fwrite command used here can time out, basically crashing the whole enchilada.

Capturing WFS image:
As I found out last week, the frame rate of the WFS is a function of the frame size and the shutter speed. The frame size dictates the number of sub-apertures used, and hence determines the spatial sampling frequency. Intuitively, reconstructing (and hence controlling) higher spatial frequencies means a slower frame rate.

Short shutter times also increase the frame rate, but only up to a certain point. Beyond that, the frame size basically determines how fast the thing can go. Generally, the idea is to select the minimum shutter speed necessary to accurately image the sub-apertures.

Computing Slope Vector:
Again, this is a function of how many sub-aperatures are being used. I'm not exactly sure how this varies though since its cumbersome to alter the code every time for a new image size.

Clearly a lot of these parameters are fixed by the experiment. The DM only has 31 actuators, so there's a limit to the required spatial sampling frequency. Whats more, for a given laser the shutter speed can just be set to the smallest value that still allows the centroid algorithm to work. That basically leaves the WFS frame size as the only parameter that can effectively be varied. I'm hoping to write up a little script this weekend to see how the overall frame rate is affected by this.

Rewriting the slope estimation code turned into quite a shit storm of coordinates and indices, so it took me most of Wed. and Thurs. to write it and test everything. To answer the questions from before:

(1) The slope algorithm runs at 100 Hz as written for an array of 10x10 sub-apertures and an image around 220x220px. The image actually needs to be slightly larger since each sub-aperature isn't exactly 22 pixels wide (something I need to fix later). Suspiciously all three control processes: sending commands, reading a WFS image and processing the slope, top out around the same speed. The slope script can be sped up to around 300 Hz if I pass in the file containing the lenselet coordinates rather than load them each iteration (TURBO MODE!).

(2) Currently with a 10x10 sub-aperature WFS image, the whole process runs around 50 Hz. The strange thing is that the speeds aren't consistent with simply adding the speeds for individual processes. For example sending a DM command and just reading an image occurs at around 100 Hz, even though that is approximately the individual speed for each of those. Adding the slope finding script knocks this down to 50 Hz. Using turbo mode on the slopes causes the DM command script to hang (at fwrite).

(3) 50 Hz is probably sufficient for now, and reducing the shutter further doesn't result in much faster frame rates. The issue now is going to be alignment since a 220x220 px square is less than 2mm^2. Pushing to faster frame rates would mean even smaller beam sizes.

(4) Its probably possible to work with the current laser, but we have some equipment money to use so a new laser is probably in the cards.

I'll be out Mon and Tues taking advantage of my strict grad student schedule. The goal for next week is to have the beam resized with the current laser (probably minus the target splitter), and run the classical controller at 50 Hz. If possible I'd also like to look at the actuator dynamics with this faster WFS frame rate.

Word.

I'm an Idiot

Today I finally relented and had a telecon with some of the guys who manufacture our DM and WFS. They basically took over my PC and were able to get high frame rates right away by reducing the shutter speed to small values. I don't know why I didn't do this or do it successfully before now. Let this be a lesson to you kids: even if you're a moron don't give up hope on that phd.

I'm able to get rates >1000 fps if the shutter is small enough and the image size is 10's of px. The problem now is that, for a given image size, the exposure of the WFS image is entirely determined by the required frame rate. Obviously Nyquist's sampling theorem applies to spatial sampling, and increasing the number of lenselets used to measure the beam increases the image size. This means that there's a trade off between the spatial and temporal sampling resolution that I can get for a fixed laser intensity.



Right now it doesn't make much sense to sample much faster than the rate at which I can spit out DM commands (since I'm ignoring actuator dynamics atm), so a frame rate around 120 fps should be good for now. Screwing with the number of lenselets is a hassle since it requires changing the beam size and computing a new reconstruction matrix, but it appears I can get around 120 fps and still have an exposure sufficient to image the spots if I use a grid of around 10x10 sub-apertures (a WFS image of around 220x220 px).

Tomorrow I want to get an idea of what kind of rates I can expect in the finished product to determine what the bottleneck is now. Hopefully it'll be software this time. This will involve:

(1) Adjusting the slope-finding code to work with a 10x10 lenselet array. How fast will it run with this smaller size?

(2) Test out how fast the system can apply a command and return a slope vector -- no need to resize the beam quite yet. Does it matter what part of the frame is used? Prob not with a CMOS cam would be my guess.

(3) If thumbs up on the overall frame rate, figure out what the new beam size needs to be and start on the hardware changes.

(4) Once the beam size is good, determine if the shutter can be sped up at all. Today I had to remove the splitter to the target cam since these new exposures were too short to capture all the centroids. If adding that splitter requires too high a shutter it might be time to think about a class IIIa laser.

Once this is all hunky dory I'll need to know if the actuator dynamics are important at these higher frame rates. Shouldn't be a problem figuring this out using the code I wrote to test the messed up DM.

Finally, time to step off on this shite.

One word: plastics

Its nice to find out, after almost a year of running experiments, that my DM is f0xred and probably has been for quite some time. I was always suspicious since my reconstruction errors were sometimes astronomical, but control always seemed possible nonetheless. I found out the thing was screwed by accident.

Basically, running the DM faster involved using a new command that allowed multiple actuators to be commanded simultaneously, rather than one at a time as before. The command rate of the DM should therefore be ~30x faster, easily into the hundreds of hertz. However for whatever reason using this command on my DM caused havoc, essentially freezing it in the zero position until I manually unplugged it. Days went by as I tried various explanations, before I eventually wrote a script that seemed to work on the other AO experiment we have using the same DM and driver box (I had to make some creative guesses on how to format the parameters used in the command). The code was indeed around 30x faster, but my DM was still crapped out.

Coincidentally, I ran some test using the old command to look at the linearity of the DM surface to voltage commands. As expected, some of the them responded quadratically, but the large majority didn't respond at all. After some back and forth with the manufacturers, I was able to trigger the WFS asynchronously as a command was sent, and was able to actually catch the actuators moving. Sure enough, some seemed fine, but in many cases the influence functions decayed significantly (sometimes to zero) within milliseconds of the command.

[insert pic]

Clearly something was fucked. After another week of test to convince everyone I wasn't hallucinating, we finally got a new DM yesterday. This mirror has some odd annular actuator arrangement, so I doubt we'll end up using it permanently, but so far it seems to be taking the new commands without complaint. I haven't checked for actuator decay yet, but so far there's no evidence of funny business. I also have a voltage sampler to check the response of the drive box, but I doubt that's malfunctioning.

Its irritating though that even after demonstrating what I consider to be a significant amount of code (instead of just using "their software"), the guys who make the mirror still seem to think I'm something of an optical retard. I guess its always better to overachieve.

Tomorrow:
- test the DM for actuator decay
- use the voltage sampler to test the drive box
- examine the runtime errors I get with the manufacturer's software

My advisor's made it clear that speeding up the SLM is a low priority at the moment, and I'm to focus on getting the DM and WFS working faster.

I suppose this makes sense, but accomplishing those things means a lot of waiting around to hear back from the manufacturer. In the mean time I"m going to try my hand at writing some basic adaptive controllers using the same architecture as in the beam pointing experiments. I already have a Simulink model that actually runs the experiment, so instead of screwing around with the SLM, for the mean time I can just add desired disturbance wavefronts to the measurement. From a control perspective this shouldn't make any difference, and it'll let me get my feet wet with some adaptive methods. I can get an identified disturbance model that can spit out disturbances with realistic statistics, so doing this should be "trivial."

Didn't Ben Franklin have syphilis?

As if I didn't have enough going on right now, I'd like to eventually write a complete set of HDR functions that I can actually use with a DSLR. I already have part of this done already for use with AO, but there are still a few features that are left:

1. Image alignment: since I don't really carry a tripod around everywhere, it'd be nice to have an image alignment function that can automatically align several images taken by hand. If you consider the problem as sliding one image around on top of another, this is really an (convex?) optimization problem: find the optimal (x,y) displacement to minimize some alignment metric, like the mean pixel difference or something. I think there are a couple algorithms out there that do this by gradient descent, so I'll have to look those up but the general idea is simple. The problem with HDR is that each image has a different exposure, so somehow that has to be corrected. Maybe weighting each pixel by its intensity of something to ignore saturated areas...

2. Creating a HDR image map: basically already done following the method by Debevec.

3. Tone mapping: there are a boatload of algorithms for this, and I'm still not sure which one's the simplest to implement and yields decent results. Right now the leading candidate is Gradient Domain HDR Compression (Fattal 2002) since the results look pretty good and I understand most of the paper.

Who knows if I'll ever get around to this. I recently read a nice how-to on doing time-lapse videos using a Canon point and shoot, so if I could somehow combine that to make HDR time-lapses it could be epic.

Nope

Last week I finished writing a new slope calculation script based on idea of using 2 linear operators and dividing the result. IS this faster than looping through each sub-aperture in Matlab? Nope.

The problem is that the matrix to calculate the unnormalized slopes is 2N*M, where N is the number of sub-apertures and M is the total number of pixels in the image. Since the WFS has around 1600 sub-apertures, and the image is more than 1000x1000, this matrix is gigantic. Even though its sparse, it takes up more than 1.5 MB of space. The matrix to calculate the total intensity of each sub-aperture is around the same order of magnitude, so combined the script has to load over 2MB of data each time a WFS image is captured. This takes more than a second in Matlab, so that option is off the table for now. Simply loading them into the workspace beforehand and passing them to the script is much faster, but still around the same speed as using loops.

Ultimately, when I get the DM working faster (still waiting for word on that from the manufacturer), I'll have to write the slope algorithm as a mex file and run it in C. What's another wasted week?

Faster

I've heard from the company that manufactures our DM and WFS that they can achieve frame rates an order of magnitude higher than what I'm capable of doing, around 800 Hz. This blows my mind since I have no idea how I make any more than incremental improvements with the Matlab commands I'm using now. In a sense this pisses me off since I'm not sure how we would have found this out if my advisor hadn't brought it up. It seems common in this industry for companies to ignore what most people are doing and write their own, barely adequate, proprietary software, and then go into stealth mode with the support.

Anyway, we're focusing on the DM first since that's most likely the harder problem. I'm actually skeptical they can get the frame rates they claim, but who knows. I've sent them the code I'm current using-code that was adapted from stuff they sent us-so I should hear something soon. I fully expect to hear complaints about a variety of minor coding transgressions and other shit that doesn't matter.

Nonetheless, I'm assuming that I can eventually speed things up significantly on the hardware side, which means that my software will have to change as well. Right now the most significant software bottleneck is the script for calculating the slope vector from the WFS image. For a full frame 1280x1024 Hartmann image, calculating the slopes in Matlab takes around 0.08 seconds for a grid of around 40x40 lenselets. The problem, as I mentioned before, is that finding the centroids is not a linear operation since you have to divide by the sub-aperature intensity, thus you can't just multiply the image by some matrix. Loops in Matlab are shit, so looping over all the sub-aperatures is what causes most of the delay.

Right now I'd like to try to reduce the computation time in Matlab by reducing the centroid calculation to 2 linear operations on the image. if I is the vectorized image, then there is a (sparse, large) matrix A such that S1 = A*I, where S1 is a vector of unnormalized slopes. There is also another matrix Q such that L = Q*I where L contains the total intensity in each sub-aperature. The slope vector is then (in Matlab speak) S = S1./[L;L] (since S1 contains x and y slopes).

I have no idea if this is really faster, but there's enough evidence to give it a try. Coming up with A efficiently though isn't easy, but hopetully I'll finish that tomorrow.

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.

I'm not totally convinced the SLM is doing much to the phase. I'm pretty sure its working, but since I'm not measuring the phase directly I don't know if a single wavelength of change is much.

It's clear that something is happening. Here's a plot of the target image variance (J) and slope vector norm with the SLM active. At 300 iterations it displays a focus shape (not that easy to calculate efficiently!) where the amplitude varies sinusoidally from the max displacement to min.



The good news is that the sinusoidal pattern is reflected in both objective functions. But although the change is visible, its miniscule percentage compared to what's available with the DM. As a comparison, the maximum stroke of the DM is in the range of 10 microns. The SLM is limited to 2pi rad, about 650 nm. This wouldn't matter much if I were mapping the phase measurement back to the range of [0,2pi], such as with a SRI. But since I'm not measuring the phase directly, I'm not sure how variations like that are mapped in a Hartmann sensor.

The other problem is the ludicrously slow response time of the SLR, which I still have to limit to 1/3 Hz. Given the shit this thing has given me over the last few months, I think the best plan of action is to convince my advisor to ditch the SLM and get another DM. That will require me to exhaust all obvious ways to speed things up, but at this rate that shouldn't be hard.

Damn the torpedoes

I'm finally back in the swing of things after my little excursion to the Old World. Its amazing how difficult it is to get used to "work" again.

The SLM is still heinously slow, still limited to around 1/3 Hz....yes 1 frame every 3 seconds. Personally, I think its unlikely I'll ever find a solution to this, but right now the best hope for a fix is to try using with with the other SLM's hardware (which is working fine). I'm also going to email BNL, but since I didn't write the modified code to control it using Matlab, doubt that'll result in anything useful.

Nevertheless, I'm going on as if everything was operating normally. I've devoted this week to determining if the SLM is doing anything at all. Here's a plot showing a few relevant objective functions as a focus bias was applied to the SLM with sinusoidally varying intensity. Since the bitch has been fighting me every step of the way, I was surprised to see actual sinusoidal responses here, even though their amplitude might be too small to be useful. The DM was stationary in the bias position for these experiments, and the SLM is set to zero until iteration 300:



Of course, at 1/3 Hz, these experiments take half an hour to perform. Nonetheless, there's at least an indication that the SLM may be useful to generate disturbances if I can get it moving faster. For tomorrow, I'd like begin adding such SLM disturbances into the SPGD algorithm, even though a full experiment might take a day to run (I can do it over night if necessary).

As another side project, my advisor wants me to characterize the response times of each component in my system. Unfortunately he's starting to think about real-time experiments, which seems infeasible now considering the problems I'm already having.

Europe

I'm glad that the mohawk survives in Europe. Denim capris pants? Not so much.

6.18.09

I've been fiddling more with my setup this week to get the classical and SPGD algorithms working like I expect them to, and think I about have it. Most of the hassle involved positioning the target camera. Interestingly, the SPGD algorithm was able to successfully maximize Strehl ratio from the image, but the PI controller with the WFS failed to achieve the same steady state performance. Ultimately, I think the reason for this was that the target camera was positioned slightly off plane, so an unaberrated phase didn't result in a focused spot.



Tomorrow I want to try running these algorithms with some significant, static SLM disturbance. I still can't send commands to the frickin thing faster than 1/3 Hz, so dynamic disturbance simulations are going to be sloooow until I can get that resolved.

Distracted

I got a new laptop this week, so progress was...muted. I was able to write some code to generate superpixels for the SLM, and I used it to get some preliminary poke matrix data. Basically the phase response is pretty strange as the individual pixel values change and I haven't quite figured it out yet. I did learn though that the WFS isn't capable of really detecting unit changes in pixel values, however. Luckily this doesn't really matter much since I intend to use the SLM primarily to product noise of a particular bandwidth.

I have a large trip planned at the end of next week, so I'm not sure how preoccupied I'll be over the next few days preparing. Ideally, I'd like to take another look at the experimental implementation of the gradient descent and look at how it responds to (slowly) changing disturbances. Maybe like step changes every 100 iterations or something like that.

Case of the Mondays

My adviser and one of the post-docs are out at a conference this weeks, so I'm practically alone in lab this week. Its hard to find motivation.

Today I aligned the target camera, so for the first time I have all my devices together in a single experiment: laser, DM, SLM, target camera, and WFS. Hey it only took a year!

I also finished the Simulink model that I can use to close the AO loop with any desired controller (although right now its using Simulink's integral controller block). To finish it off I added a block that reads images from the target camera and computes the image variance, although its easy to change that to any other desired performance metric.

Currently, the controller doesn't provide much improvement in the wavefront variance. I suspect this is probably because the phase is fairly flat to to begin with, and any aberration is relatively of high frequency and can't be corrected with the DM. Now that I have control of the SLM, the goal this week is to introduce (static) artificial disturbances and see how well the classical controller compensates. Next week I'd like to try some basic dynamic disturbances.

So the plan for this week:

1. Finish alignment, check tilt modes

2. Write a script to generate SLM poke matrix, begin applying static disturbances that result in a know slope disturbance.

3. Investigate performance of gradient descent algorithm using identified turbulence models.

4. Create Simulink model that implements gradient descent controller with an arbitrary performance metric.

6.4.09

I've spent most of this week porting my control algorithms to Simulink and the "suggestion" of my adviser. Conceptually this shouldn't be that hard since I already have a simulation using the experimental poke matrices. Reading the WFS image is trivial with the image acquisition toolbox. However implementing my custom code for calculating slopes and sending commands to the mirror requires me to use these Embedded Matlab blocks that translate m-files into C code for execution in Simulink, and that process involves a whole shit storm of issues. I found a pretty simple, slightly cheating, way of doing it that basically just involves calling my existing code as "extrinsic" functions that don't compile into C, but instead run in the Matlab workspace. This seems to work pretty well and right now I have my PI controller running beautifully (albeit slowly) in Simulink.

I've gotten the code necessary to control the SLM from Matlab as well, and its pretty clunky and generally crap, although I guess its functional enough to use. Getting it to work in Simulink as above though is, not surprisingly, a pain in the ass.

Tomorrow we meet with some Ophthalmologists to see if we can use any AO techniques on their retinal imaging machines. This has been done before by some people at Berkeley, so what they ask for might not be particularly novel, probably difficult (getting the optics setup), and from a control perspective not very interesting (the phase distortion of the eye is basically constant). Still, it doesn't hurt to talk.

At long last the SLM is installed and appears to be working. Here's the reconstructed phase with a test image:



See the face smiling at its own existence? Happily, this also indicates my phase reconstructor is working

Next comes controlling it from Matlab.

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.

5.26.09

My gradient descent simulation is showing some progress in rejecting dynamic disturbances. Here's a plot showing the cost function (log of the Strehl ratio using the Marichal approx), noise term, and control sequence using a noise bandwidth that's 1% of the Nyquist frequency. Control starts at 5000 iterations.




My view at the moment is that the command sequence essentially acts as a first order system, exponentially changing in response to a step disturbance. The transient response of this system is governed by the size of the optimization step. So as long as the period of the dynamic disturbances are sufficiently larger than the rise time, the algorithm shouldn't have a problem rejecting it.

This analogy isn't exactly correct since the gradient must be estimated at each step, and the step size is only constant if the normalize gradient and constant gain are used, which isn't always the case. Still, the problem basically boils down to finding a control gain large enough to provide convergence, but small enough to be stable. Even more, since the objective function is basically quadratic, there's probably some way to quantify the optimal step size, but I'm too lazy at the moment to spend much time on that street.

The current simulation is very simple, using a single channel with no poke matrices or actuator nonlinearities. The next step still be to gradually introduce these features until I have a realistic model. If this works at all, it might be worth looking into other first-order algorithms that have even faster convergence properties. i.e. pseudo-Newton and Nesterov's.

5.20.09

I gave up waiting for a reply about the SLM cables, so I went ahead and ordered what I think are the right ones. Hopefully they'll be here next week.

Until then I've gone back to testing out gradient descent methods on a more complicated model, and using the "Marishal approximation" of the strehl ratio. Because this equation is a log-concave function of the wavefront (spatial) variance, I should be able to apply any number of nonlinear, first-order optimization techniques as long as I can get an accurate estimate of the gradient. In contrast to my previous experiments with this, I've added a colored noise term that corrupts the wavefront with some bandwidth. The question is how can I obtain an accurate gradient estimate in the presence of such garbage? And how are those estimates corroded by increasing the bandwidth (and hence correlation) of the noisy input?

Another person in my lab is trying to work the same problem with an extended Kalman filter, which know nothing about. This perspective views the Strehl ratio approximation as a nonlinear observer of the system's state. There are some notes online from some Stanford course (EE236) that has a good explanation of the EKF, so I might have to read that over at some point.

5.18.09

The last couple days have been a frustrating string of delays in gathering the components I need to install the SLM. At the moment, I'm trying to get longer cables to connect the DAC board to my PC, since the supplied cables are retardedly short. The exact type of cable isn't specified in the thin manual that I have for it, and it doesn't help that there are a million nearly identical types of scsi connectors. So after scouring the net for images of obscure 20 year old cables, I finally emailed the manufacturer. Hopefully they'll get back to me tomorrow and will be willing to spill the info. Ahh the joys of experimental research.

In the mean time I'm continuing to review some controls material, particularly adaptive filtering and digital control. I was happy to find out that my adviser is pretty interested in trying these Laguerre lattice filters, but I have a ways to go in my review before I get to that level.

FIR, LMS, RLS, WTF?

Now that my hardware setup is approaching something near its final form, I think its time to start thinking about what I'd like to accomplish here come check out time. Thus, I present...

A 7 point plan for dissertation ass kicking:

1. Finish configuring the SLM to generate disturbances. If that fails, use a DM or other active optical element. These disturbances should originate, using various simulation parameters, from the HEL simulation.

2. Try basic classical AO controllers with said disturbances. Characterize bandwidth properties and relationship to number of modes used.

3. Try "blind" optimization algorithms using target camera information only. Ideally, the cost function used would be somehow related to the Strehl ratio, and could be measured using a photodiode if desired (e.g. intensity). Some interesting first-order algorithms to try include: simple gradient descent, quasi-newton, gradient mapping, and (not first-order) interior point methods.

4. With dynamic disturbances, try to identify a FIR controller using LMS offline. In real time, use a basic RLS fixed-order controllers.

5. Lattice based, order-recursive FIR controllers

6. RLS Laguerre, order-recursive IIR controllers

7. Try RLS adaptation using some other set of orthogonal transfer functions. Maybe something could be done here using Q-parametrization.

That last one might be off in la-la land, but if there's time it could be interesting. S. Boyd's book on Linear Controller Design might have some interesting material related to that.

5.11.09

Truncating the sensor image turned out not to be the nightmare I thought it would be, so removing shadowed spots from the slope calculation seems to work pretty well. The classical controller seems to do a pretty good job flattening the phase, here's a before and after comparison of the reconstructed phase:



The norm of the wavefront slope error isn't really reduced much, <10 percent usually, but I think this is because the reference wavefront is already pretty flat. Right now I'm playing around with deliberately adding a strong focus bias by moving a lens to see if the controller can still compensate.

5.8.09

More classical control stuff today. It seems like there's a problem with the WFS measurements. Although the controller successfully reduces the measured slope norm, reconstructing the actual wavefront reveals a deeper story:



The top plot is the reconstructed phase with zero command (dac=180), while the bottom is with the steady-state control value. Clearly the end result has more phase variation in the center, even though the slope norm is minimized. I think the problem is at the corners. Physically, the WFS has a long barrel opening before the image plane, and this is causing some corner sub-apertures to be shadowed. Currently, my code just sets the slopes at these these locations to zero, and I think that's causing the reconstructed phase surface to dive at the corners like that.

The result is this artificial bowl shape, and this causes a large projection into the focus DM mode even though most of the reference wavefront is pretty flat. It looks like the controller is attempting to compensate for this by depressing the center. Touching, but ultimately wrong. Note that this wasn't a problem in generating the poke matrix, since in that case I was subtracting out the reference wavefront from each measurement. Here I'm attempting to reduce the total wavefront.

To solve this I'll have to change my code to exclude those slope measurements from the corners, rather than just set them to zero. This isn't as easy as it sounds, since the indexing there and in the phase reconstructor is gnarly. If it doesn't drive me insane I'll hopefully have that done Monday.

5.7.09

After a few setbacks, I finally have the experiment hardware set up with the SLM in place, although its not attached to my PC yet. Basically, I had to add another beam splitter and 2 new lenses to accommodate another actuator, and for some reason this really magnified intensity distortion in the laser spot. The result was that the classical AO controller wasn't able to handle more than 2 or 3 modes before the sensor started returning bad data. To fix this I changed laser (which meant changing the focusing optics), and after days and days of tinkering, I finally have it working pretty well.

Another note is that almost all of the beam reflected off of the DM must hit the sensor. Anything else and things go to hell for some reason.

Right now the SLM is just there passively as I run through all my control code to test for goodness, but over the next few days I'd like to get it attached to my computer and taking commands from matlab. This requires a PCI card that I have to find, so it could take some time. There's some question about whether this SLM works, but I'm open to using another DM if I have to, although that would take months to order.

5.2.09

A thing a beauty:



compared to the crap I usually get.

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.

3.30.09

Today's the first day of the spring quarter, which means I had to spend most of the day fussing with bullshit errands like getting my parking permit and paying rent. Other than that, I spent some time taking a break from SPGD and working on my interior point idea.

Basically, the general plan is to find the command vector c that minimizes the 2-norm of the total wavefront. This requires the linear model of the DM using the poke matrix, G, and can be generalized using modes if desired. Without saturation the optimal DM surface would be the projection of the static wavefront onto the range space of G. But, limits on the actuator commands add inequality constraints. This means that the true optimal command vector must lie in the union of the feasible set AND the orthogonal compliment to the null space of G. Note that if modes are used, the inequality constraints involve the modal poke matrix, since you can't place explicit constraints on each modal command.

This kind of optimization problem can be solved by replacing the inequality constraints with logorithmic barrier functions that are tacked onto the objective. These beasts are designed to go to infinity as the limits are approached. By eliminating the inequality constraints, we're left with (in this case with no equality constraints) an unconstrained problem. The new objective function to be minimized now consists of a weighted sum of the wavefront norm, and the barrier function terms. This unconstrained problem can then be solved using Newton's method iteratively for more and more accuracy.

Wow, that's possibly the worst explanation of the barrier method ever committed to words. See the notes on Nonlinear Optimization for the real deal.

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?

3.23.09

Haven't had much luck getting the spgd controller to work with just the maximum image intensity. The problem is that it simply searches around without actually maximizing anything. In desperation I went back and tried running it with a constant command across all actuators, essentially optimizing over a scalar value.

Since the optimization variable is a scalar in this case we can look at the objective function graphically. Here's a plot of the maximum intensity vs. the constant command. Clearly its not concave, although it would be quasi if it wern't for that little bit beyond the max. There's an obvious maximum, but the problem lies in the flat area from 0 to ~180. When the gradient descent algorithm is in this region there is no obvious direction of steepest descent with small perturbations, so the algorithm gets stuck at the intial value.

Its clear from the images themselves that the beam tightens as the maximum command is approached, but the peak intensity doesn't necessarily increase measurably. I'm trying now to come up with another objecive function that measures the spread of the beam based on a "moment of inertia" calculated from the image.

The results today weren't great, but I was using the center of the frame as the origin for the inertia calculation rather than the "center of mass." I'll try changing this tomorrow, maybe by using the parallel axis theorem to save computational time.

I got around 50% on my final. About average. Along with Adaptive Filtering and Linear Programming, that class should establish my minor field in EE, so I'm technically finished with classes forever.

Capitulation II

I've probably taken around 50 final exams over the years, so you'd think by now a career student like myself would have a solid method to study for one. But you'd be wrong. Every time is a masochistic adventure, a battle of attrition against your own ability to concentrate and ingest caffeine. For most people there's no finite amount of studying that will guarantee a decent grade; going over every page, every example, and every hour of lecture notes is not practical. The result is a balance between competitiveness and sanity. Unfortunately engineering students are famously competitive.

Its even worse in grad school. The exam I'm facing tomorrow is worth more than 80% of my final grade. Does that mean I should spend 4x the time studying for this beast as I spend on everything else? The only comfort I have is knowing that if I've gotten this far, tomorrow should be no problem.

Update: 26/50...good enough for an A- hah.

Close

After a lot of trial and error, I discovered another problem with the way I was applying random perturbations. To avoid saturating the actuators, I was first generating random DAC commands in the range [0,255], and then calculating the corresponding perturbation from that. The problem with this is that the resulting perturbations aren't zero mean, so if the current command is, say, 200, then its unlikely a positive perturbation will be generated. Thus, the gradient was effectively being estimated with information in only one direction.

I fixed this by randomly generating the perturbations themselves, rather than absolute commands and back calculating the perturbation values. I'll have to play around with the parameters to make sure they're actually zero mean. Saturation might just be something I'll have to live with, especially when generating random modal commands. The ideal method for generating these things actually might require some thinking. If the current command is close to 255, for example, then having too many perturbations that are saturated is a waste.

With this change I tried running the SPGD controller with a single mode (the focus mode), commanding all actuators with the same value. Luckily it converges in steady state to approximately the same control command as the PI controller, around 199. However the command seems to jump around to a much lower command every other iteration, so I think I'll need to play around with the gain to tamp that down.

I witnessed similar behavior when feeding back the intensity instead of the WFS data. I'm hopeful that I can get it working by just picking the right gain.

I'm close...I can smell it.

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.

3.12.09

The maximum intensity is the simplest objective function I can think of from images of the beam profile. Comparing it to the wavefront norm using the PI controller (still the best algorithm right now) shows pretty decent correlation between the two.



As expected, the maximum intensity doesn't correspond to the minimum wavefront error. This is because the code I wrote to read the WFS images doesn't use the exact lenselet locations, so the measured wavefront isn't exactly accurate. Also, the camera isn't placed exactly in the focal plane. These are problems that'll have to be fixed once I get the new sensor.

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.

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.

Reason #2

Reason #2 I'm in grad school: never underestimate the allure of free pizza in today's harsh economic environment.

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.