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.