Moar Modes

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

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






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

The Happening

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

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





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



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

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

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

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

Over and out.

2.22.10

After several realignments and swapping out the mirror, I finally have the larger DM in place. I've been able to generate some pretty hot poke matrices from it; now that I know its working fo sho I've spent the last week or so updating my code and testing it out. Overall it behaves much like the smaller DM, albeit with a greater effect on the beam. I'm not sure exactly why this is, but I suppose it might be due to the larger number of actuators. Because of this I've limited it to voltages in the range [0,180] with a bias at 90V instead of the full 255.

The reconstructed actuator influence functions looked pretty solid, so I constructed a set of modes using those instead of the idealized influence functions we used for the smaller DM. The resulting modal poke matrix looks pretty good for the first 15 or so modes, but basically random after that. I'm not sure if this is due to the commands themselves being strange, or because the mirror can't reproduce high frequency shapes.

Looking at modes again has also dragged up the idea of reducing the beam size to fit in the measurement area. The current number of lenslets, around 1500, is basically an order of magnitude greater than what's found in most AO systems I've heard of, including the high fidelity HEL simulation we use to generate disturbances. The idea is that this is just causing unnecessary computational overhead since the DM's only have 31 or 61 actuators; by reducing the beam size we can utilize the WFS's partial frame mode and achieve higher frame rates (since its a CMOS sensor). This sounds dandy in theory, but in practice I've had a tough time getting a good looking, curricular beam less than around 10mm in diameter, but for the beam to fit in a 5x5 lenslet array would require the diameter to be around 2mm. The trouble is that at that size the beam isn't really circular any more, and the large intensity variations across the cross section make computing centroids from a single WFS image problematic. I don't really know what's causing this, it could be that the relay's I'm using to resize the beam may be crap for that application.

The idea of running the experiment faster is pointless anyway for a couple reasons. First, even with a 5x5 lenslet array, the WFS frame rate would still be much less than the kHz required for real real time experiments, so control would still have to be run on an event driven basis. Second, despite what's been claimed, the DM's need a finite pause between commands for them to reach steady-state. Experience generating poke matrices has shown that a pause of less than 0.08s or so between random commands results in garbage, so this is essentially the upper limit of the experiment unless there are some hardware changes...and I've had enough of those.

I'll continue looking into this a little more, but actually modeling the actuator dynamics is probably beyond what I want to do, since it would require obtaining a frequency response for each DM mode.

With the disturbance DM working, its time to move on and consider what my next move is. This week I'd like to finish modifying my simulink files to apply disturbance commands to DM61. Also, I'd like to review some of my basic adaptive filter/predictor stuff, and maybe have a nice simulink example I can "easily" port over to the experiment to play around with.

For tomorrow:
- Compare mirror step responses for DM61 and DM31 using random and single actuator commands
- Try to figure out what the extra B' is for in the eigenvalue problem for generating modes.
- Review linear predictor stuff. Start building a simple Matlab/Simulink example

2.11.10

I was able to construct some modes for DM31 (the 31 actuator DM) using influence functions reconstructed from the poke matrix instead of the theoretical, simulated versions. When applied, both sets actually look pretty similar until the 10th mode or so, after which the experimental modes start to look like crap. I think part of the problem is that the WFS only samples the interior 80% or so of the beam, so several actuators peak on the edge or just outside of the frame. Since the experimental influence functions are actually pretty similar to the simulated versions (amazingly, even the amplitudes are within an order of magnitude!), I suspect that resizing the beam such that all the actuators are fully measured would help this out a little. Something to play with next week.

In the mean time, it'd still be interesting to construct modes for DM61 using its poke matrix. I found out yesterday that most of the actuators respond linearly to the square of the voltage command just like with D31, but there are 3 that don't seem to be moving at all, or or moving strangely. Tomorrow the plan is to swap out the mirror that's installed now with the spare to see if that solves the problem, and then take a look at the modes using that mirror's poke matrix.

I'm pretty clear on how to construct the modes now given a set of influence functions. Basically it just involves some clunky linear algebra. Maybe I'll write up a little short story about them one day.

Back in Business

Apparently the D/A buffers in the driver box get corrupted every time I restart, but they can be cleared by a special command. Of course, why didn't I think of that?

Premature

This all was only wishful thinkin,
this all was only wishful thinkin


Unbelievably, the DM that was working a few hours ago is broken again after restarting my computer. Maybe something happened to the hardware overnight. Maybe our lab was subverted by Chinese hackers. Maybe it was all a dream and I was just hallucinating about it working from the pain meds I took for my knee.

Maybe my experiment's become self-aware and is trying to prevent me from making a discovery that will eventually lead to the extinction of the human race. It is, after all, almost as if the piece of crap was consciously trying to screw me up at every turn. Here's a rough timeline of the last few weeks:

- DM arrives. The cables for connecting the driver to PC are 1 ft long. Order longer cables.

- Longer cables arrive. Install DAC card drivers and search fruitlessly for further instructions. Email for help.

- Help arrives in the form of a software update from DM manufacturer. Software update proceeds to not work and crash. Email again for code that will work in Matlab.

- Example Matlab code arrives. Cryptic and mysterious, it uses syntax and a programming interface I'm unfamiliar with. Running it invokes errors and crashes Matlab. Email for help with suspected code.

- Correct faulty Matlab code and run it to discover...more errors. By now I can fix the "example" code myself.

- Matlab code runs without error. It works successfully with old DM, but new DM refuses to move. Email for help.

- Update DAC card drivers to latest version. Unplug and replug cables.

- SUCCESS! Compose witty and congratulatory blog post. Drink heavily in celebration of completed experimental setup.

- Restart computer. DM again refuses to move despite no software or hardware changes. Email for help.

- Cry. Put on Taking Back Sunday and compose defeated and bitter blog post.

And that is where we stand to this day, only a mere half quarter after we started. Fuck it, I'm taking a vacation.

Now witness the power of this fully armed and operational battle station!

My experiment is complete. Today I finally, finally gotten my second DM working from Matlab after more than a few emails, wasted afternoons and computer restarts; thus all the major components are there and functioning. Here's a picture of an experiment in progress:



There are still a few idiosyncrasies to work out, but the basics of sending commands to both mirrors simultaneously seem to be working. Here's a comparison of the effect of random command vectors applied to either mirror or both simultaneousy



Clearly this new mirror doesn't quite have the range of the 31 actuator model for whatever reason, however for generating disturbances it should get the job done.

This week the focus will be on characterizing the new mirror and rewriting my code to interface with it. The first step is to generate a poke matrix; early attempts at calculating one from random commands today weren't that successful for some reason, although poking each actuator individually seemed ok. I think a good plan for tomorrow would be to

1. Try loading the straight 61 actuator configuration file. Does poking each channel give the appropriate response?

2. Realignment. Are all the actuators covered by the beam? Should the beam be resized or altered in some way? Try to eliminate tilt as much possible before proceeding.

3. Assuming all the channels are behaving as planned, try again to generate a poke matrix using random commands.

Once I can generate this mapping reliably, I can go ahead and look at things like linearity and actuator decay. Then, I can use the experimental actuator influence functions to generate DM modes.

I'm Doing Science!

Turns out expecting to produce a poke matrix by last Friday was a tad optimistic. After all, why should I expect my $15000 mirror to work out of the box or come with directions? What am I, some naive undergrad researcher?!

Most of of the problems stemmed from the example code I was sent, which contained several errors based on the "version" of the software I was using. Some of those I fixed myself, which I guess is good in retrospect since it forced me to get to know a few of the intimate joys of .NET. I'm sure this will be useful when some piece of code decides to shit the bed later.

In any case, I finally have some code written that I can use to command the USB, 31 actuator mirror using this new interface. Putting me functionally in the same place I was months ago. For some reason I still can't see the new DM from either the bundled software of Matlab, so that will take some further tinkering and emailing. It would be optimistic to plan on having this fixed by next week.

Nonetheless, tomorrow the plan is to get use to this new code and verify its producing the same results as before. Since we have 2 of the new 61 actuator DMs, I should be able to swap the hardware around to pinpoint the problem. I suspect its just some stupid software parameter somewhere that has to be checked, but its probably going to take an email to the manufacturer to figure out.

Vacay's Over

Its been a relaxing month of unmitigated laziness since I passed my Quals. In that time I've managed to do less than I ever thought possible, other than ski and eat.

The presentation itself, rushed into production like a Soviet washing machine, went over well. Taking a hint from all the seminars I've slept through, I tried to avoid putting in too much text that would be ignored and instead focused on graphics and charts that I could explain. In my experience, this approach is what usually separated a presentation given by a grizzled transparency veteran, new to powerpoint but not to verbose explanation, and a recently minted academic who still possessed the new PhD smell.

Scheduling it during finals week turned out to be a blessing. Since most of my committee had limited time to spare between giving exams and review sessions to the little ones, I only had an hour or so to talk. A mere 40 minutes remained by the time everyone arrived and I finally opened my mouth, but this limit meant that I could avoid any really technical questions.

Anyway, with a supposedly clear path ahead, the next step is to install and test out the new 61 actuator DM we received. I actually came in a few days over the break to do some alignment, despite the department's attempt to prevent this by turning off the lights and stopping garbage collection. This week the focus will be on commanding the mirror itself. This new mirror only has twice the actuators, but apparently sending it commands is ten times as difficult. Rather than a simple USB driver box, signals to this mirror travel through an NI DAQ card before hitting some other voltage amplifier that actually connects to the actuators. To use this system with Matlab I'll have to upgrade to 2009A, and use the .NET interface to access the DM driver's DLL library. Hooray.

A rough, optimistic schedule of events:

Tues: Finish installing cables, test mirror functionality using V. 1.8 software, begin dissecting AOS .NET example code

Wed: Upgrade Matlab if possible, continue code dissection

Thurs: Adapt code into Matlab DM control function

Fri: create 61 actuator poke matrix

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.

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.