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.