10.23.10

So far so good with the beam alignment, but it turns out that fixing the beam resizing reveals another problem. After rewriting some of the slope calculation code to use the new beam size, I found that identifying a poke matrix like I had been doing was producing crap. The problem now is that while the beam diameter is relatively stable, the number of lenslet spots in the WFS image can change under certain DM commands. Basically, the wavefront can change enough so that the spots move in and out of the frame entirely. This could be another consequence of using a smaller beam - increased sensitivity of the WFS centroid locations.

The number of spots in the WFS image seems to be roughly proportional to the focus mode, or the average voltage command. Applying random commands (even with a pretty large range) around a particular voltage for example doesn't really present any problems; the lenslets spots just jiggle around as you'd expect (REF video in 10.21.10). But when the center voltage is changed the total number of spots can change drastically, even if the overall beam diameter doesn't change.

The main implication of this is how to set the reference wavefront. I'm pretty much resigned to doing differential wavefront measurements after learning from AOS that I was never really using some absolute reference file. But not its no longer sufficient to just subtract the reference wavefront and apply whatever commands I want. Instead, the average command voltage has to be close to the average used to determine the reference, i.e. if commands are zeroed at a voltage of 180, then in general commands should be close to zero mean.

I don't think this should be a problem for my experiments since everything from now on will be differential measurements from that reference, so there shouldn't be any large focus biases that the PI controller has to kill. Similarly, since the disturbances are nominally zero mean, I can set the average disturbance voltage to be the same value that I use to create the reference.

However, as I'm about 2 glasses of Sailor Jerry deep at the moment this could all be nonsense. I'll sort it out tomorrow.

10.21.10

Finally, I think I'm just about done with the realignment. More screw-ups along the way than I would have liked considering I've done this countless times by now, but overall I think this was worth it. One problem worth mentioning was that I had to add an additional relay tele with unit magnification at the end. It turned out that despite all my careful measuring and CADing, I didn't account for the actual length of the WFS, and I wasn't able to place the lenslet array on the focal plane of the resizing telescope at the end. I thought about ordering a couple new lenses with a larger lens at one end, but I ended up just using a pair of 50mm lenses (compared to the 25mm lens at the end of the resizing tele) to reimage the beam onto a more spacious focal distance.

And holy shit the thing actually works pretty well. The beam does actually stay pretty constant when I apply random commands to both DM's. Although things go to shit quickly if I move them at their maximums, that never really happens in actual experiments. Plus its nice to know your actuator's have more range than your sensor's can deal with.

The beam diameter right now is around 1.5mm, meaning that I can meet my objective of using a WFS resolution of 220x220. With this size I can get WFS frame rates > 100 fps. Hopefully I can stay around 80 Hz closed-loop when I finally get the camera trigger installed.

Here's a video running the disturbance and control commands for a closed-loop experiment with the old setup. Obviously its nonsense, but its clear how consistent the beam size is compared to before.



Its pretty cool (to me at least) to see the spots dancing around like that without the beam drastically changing around the margins. Some of the spots are smeared out, but I think thats a result of the beam size. With a smaller diameter, each lenslet captures more relative area. Thus if there are high spatial frequency aberrations the portion of the beam entering each lenslet will have more to it than just tilt, and thus won't form a tidy spot.

An open question is how much I can mitigate the bias. The only way I can see to easily do this without messing up all the focal planes is to move the 500mm lens. Also, I have to start changing the slope calculation code to use this reduced beam. An open question is whether I should create a new reference wavefront or use the existing AOS file.

Better Luck Next Time

Submission deadline has come and gone....and no submission.

The problem turned out to be with the target camera. Despite getting pretty bang up results with the PSD's and modal sequences, there was basically no difference between the average intensity profile with the classical or LTI controller. I spent several days trying to find some intensity-based performance metric-power in the box, image sharpness, intensity variance-that would show some difference to no avail. Eventually I just gave up and averaged a few thousand HDR frames and found both controllers yielded essentially identical results; no function of profiles was going to reveal any advantage.

Why this happened is still a mystery considering the improvement in the PSD's with the LTI controller. I suspect its because there's enough power in the uncontrolled 26 modes to swamp any gains. Looking at the modal distribution of the open-loop disturbance wavefronts confirms that there's significant power at the higher spatial frequencies, and indeed both the classical and LTI controllers knock down roughly similar amounts. Luckily both almost completely eliminate the steady-state (average) disturbance in the controlled modes, so at least something is working.





Note that since the modes are not unitary, you can't compare the norm of the time series of the individual modal sequences directly. Instead, you have to multiply each one by the spatial norm of the mode's phase shape (sort of like the spatial RMS), to really get a number that's proportional to the "power" produced by that mode.

10.5.10[2]

I managed to resurrect the code I had for evaluating intensity-based performance measures in Simulink. The problem now is that there doesn't seem to be much difference in the performance of the controllers from this perspective. There's definitely some variation in the actual number, but in terms of the average or value the differences seem to be minimal. I think there are 2 possible explanations for this.

1. Right now I'm still using 5 modes, and when looking at the modal coefficients or only the norm of the modal sequence I see definite improvement. But its possible that there content from the higher spatial frequencies is swamping the overall results. A good way to test this, and to see just how many modes I should use, would be to apply a disturbance and look at the closed-loop wavefronts projected onto all the modes. The size of the individual modal sequences and their correlation with the overall RMS wavefront should give me an idea of how many modes I need to see some improvement. Of course, I could also "cheat" by only applying the disturbance to the modes I can control. This might be a good test as well.

2. There might also be some nonlinear intensity bullshit going on that's affecting the measurement, but isn't showing up in the modal sequence. This should be evident if restricting the disturbance to the controlled modes doesn't help. If this is the case, I'm not sure there's much that can be done without the experiment rebuild that I'm planning.

10.5.10

With a conference deadline on the horizon, the focus the next couple days is to see just how much improvement I can squeeze out of the experiment in its current form. If it looks like I can see a significant improvement over the classical loop, even if not that many modes are in play, I think I'll have enough time to cobble together a decent paper to submit. Between my prospectus and previous stuff from our lave there should be enough material to minimize the writing that I'd have to do.

I'm optimistic based on what I've seen so far that I'll be able to pull this off, although I haven't looked to see how much the Strehls are improving. If all goes well I can work on getting specific results later in the week.

Write Stuff Yourself

I've basically struggled over the past week+ to figure out what the deal is with the optimal filter. The puzzling thing was that simulations from the command line would look good, whitening an otherwise off-white output PSD, but when it came time to Simulink the outputs would look almost identical.

Finally on Monday, after much cursing I figured it out the problem after comparing basically every internal signal in the Simulink model to what it should be using lsim. It turns out that the multi-channel transfer function block I was using in the LTI controller was spitting out garbage. Fixing this involved copying the little fucker from a working diagram I received from my advisor. What was maddening was that both blocks implemented the identical transfer function...at least identical algebraically.

Now, I had to use this custom block because Mathworks, in their infinite, overpriced wisdom, doesn't have a transfer function Simulink block that works with multiple channels to my knowledge. Our lab created this one to use, but unbeknownst to me it assumes the denominator is monic, which wasn't the case in the block I was using. This is what I get for using software without really knowing the details under the hood.

Anyway, shits sort of working now with multiple channels in the experiment, just meeting my little deadline. Saturation's the enemy now, but I think I can fix that with the forthcoming hardware mods. There's still a paper deadline in a couple weeks though that I'm going to try for.

9.21.10 [2]

I've ordered parts for the new and improved experiment. Mainly just a ton of lenses, they should arrive relatively quickly. I'm hoping realignment should be straightforward, but I'm worried since the tolerances on the reimaging telescopes is pretty thin. I might have to resort to CADing everything out, but even that would involve a lot of guesswork.

There's apparently a conference submission deadline at the end of the month, so it turns out that my goal to do multichannel adaptive control by the end of September is a good plan. I'm going to try to get some decent results that can go into a preliminary paper before I tear my experiment asunder and start over. For the time being I'll have to run <10Hz so that the single delay DM model holds.

While the adaptive loop seems to work well without much modification, so far I haven't gotten much out of the optimal IIR filter/Kalman predictor. It works well enough in flattening the PSD when I use the identified disturbance model directly to generate the noise, but in the experiment its effect is negligible. I suspect this is a result of a shitty ID. It might be interesting to look at the prediction error with the actual experiment/simulation, instead of just driving the identified model.

Overall the plan is to spend the remainder of September getting preliminary results for this conference, then worry about experimental modifications in October. Make it so.

9.21.10

Vacation injury report:
- 1.5" cut, left shin
- 2" cut, right shin
- 5" bruise, hip
- multiple bruises, left thigh
- 1" bruise, chest (x2)
- skinned left elbow (despite armor)
- scraped left knee (various)
- slightly chapped lips

hey, what's the point of paying for health insurance if you're not going to use it?

9.12.10

So I'm taking a week of to visit places like this



But on the other hand I have plenty of time to digest what I learned on my little business trip last weekend. The good news is that the DM delay I've experienced was well known, and it turns out not to be due to the DM at all. Instead, the problem is that the WFS returns a frame from a buffer somewhere when requested, and at higher frame rates there's no guarantee how fresh or stale that image might be.

The solution is to use a hardware trigger for the camera so it only returns a recent frame when requested. The good news is that the current driver box I'm using for the 61 actuator DM can be modded to do this. The bad is that I have to solder a connection inside this $5000 box. We'll see when that happens.

Other than that I learned just how short my optics knowledge is when I talked about my experiment. Contrary to what I'm seeing, the beam size and intensity shouldn't change with DM commands as long as the WFS and disturbance DM are on imaging planes. Right now light is just beamed in without regard for human life. Some relatively simple hardware changes should solve this, but that means yet another alignment. Really I shouldn't be tinkering with the experiment at this point, but you can't fix stupid.

All said, I should be able to use a 10x10 lenslet array and fix the DM delay, which would allow me to boost the speed up to 100Hz and beyond. I'm aiming for the end of Oct for this, but who knows.

9.6.10

So I'm headed out to ABQ tomorrow to check out some other AO experiments irl. Although it probably would have been more useful to go there months ago when I was still tinkering with hardware, hopefully I'll get some nice ideas about how to improve the frame rate of my experiment, something my advisor seems to focus on.

I'm more concerned about the control aspects, and I doubt I'll hear anything interesting about that although you never know. I've made some progress computing the Kalman predictor like I described. Identifying the right disturbance model turns out to be a shittier experience than I thought, and I'm still not sure if I have the best procedure nailed down yet. I wasn't even able to get er done in the single channel case. The one IIR filter (for 5 channels) I managed to implement didn't do much to improve the wavefront error in either simulation or experiment. So either something is wrong with the calculation, or the whole idea of using a simple n-step predictor is mistaken somewhere.

That'll have to wait until I get back, or longer since I'm taking next week off to get out of town before the unwashed masses return to campus at the end of the month. Hopefully I can use that time to wrap my head around some simple RLS and (ideally) primitive lattice filter example in between mountain bike runs.

If I work hard like a good grad student, I think I'm still on track to get a multichannel version of the adaptive filter running by the end of the month, although surprisingly the multichannel optimal IIR filter may come first.

IIR Filtering Ideas

This post is going to be in pseudo-formal speak since I'm fleshing out ideas for my dissertation. Although that's tough without adding any equations.

The problem of constructing the optimal IIR controller for a given closed-loop plant and disturbance model can be solved as an LQR problem with a particular state-space system. However, the condition that the plant transfer matrix is commutable with the filter turns out to be overly restrictive. Suppose the transfer matrix can be factored into the product of minimum and non-minimnum phase matrices. We can define a new filter which is the product of the minimum phase component and the optimal filter F, this leaving the non-minimum phase component to be compensated. The requirement is now that this non-minimum phase component is commutable, which happens if its equal to a scalar transfer function times the identify matrix. If this is satisfied, we can perform the LQR problem to identify the controller, then multiply it by the inverse of the minimum phase component to recover the actual optimal filter that is implemented in the software.

For the adaptive optics experiment, the lack of significant DM dynamics simplifies the problem. If the non-minimum phase transfer matrix consists solely of n-step delays on the diagonal, then the optimal IIR filter is simply the n-step Kalman predictor for the disturbance model. The disturbance model is itself in innovations form, thus the Kalman predictor can be constructed directly from the state-space model generated by the subspace identification algorithm.

...some math showing how this is done....

The result is a filter which predicts the disturbance wavefronts n-steps ahead on the basis of the current wavefront measurement.

Beautiful.

Overly Ambitious

Now that the FIR filter is basically working for the single channel experiment, I think its a good time to set some targets for the next four weeks. The clear next step is to start working on a multichannel version using more modes. Theoretically there isn't that much difference here, but I suspect there will be practical problems with actuator saturation and other shittyness that will slow things down.

I think a reasonable goal is a 10 channel adaptive/optimal filter in 4 weeks. Here are some things that will need to happen:

1. Characterize closed-loop transfer matrix. How similar are the diagonal terms? How significant are the off diagonals? What's the best scalar transfer function approximation?

2. Get the adaptive controller working given an identified or ideal transfer matrix.

3. Write a script to compute the optimal multichannel FIR and IIR filters.

4. Get target camera working to compute Strehl ratios.

5. Find/write/steal a simulink block that can implement multichannel transfer functions. The pole at 1 in the pure integrator I'm using now might (will) lead to saturation when more modes are controlled.

6. Questions: How to the PSD's of the output channels compare? How does changing the number of modes alter steady-state performance?

A lot of this will require running many experiments or simulations, so there should be plenty of down time to pursue some theoretical stuff for the SISO case. Basically, I'd like to write m-files that do the following:

1. Compute the optimal IIR filter. How does performance compare to the FIR case?

2. Compute the optimal FIR gains using and RLS array algorithm.

3. Compute the optimal FIR gains using an RLS lattice filter.

4. Do something about implementing a Laguerre filter.

SInce these will all be m-files, I don't expect to implement these in the actual experiment right away. Mainly, I want to get some idea of the theoretical performance benefits by using increasingly complicated methods. Obviously I want to do all of this for the multichannel case one day, but the details of that are so complicated my head might explode first. We'll see.

Phucking Transpose

Yes, a freaking missing apostrophe was responsible for nearly a weeks delay. To try to narrow down the problem with the impulse response filter calculation, I was trying to match the results with the data driven m-file using made up disturbance models comprised of random matrices. It turned out that both filters were the same as long as the A matrix was diagonal. The only place in the code where this mattered were locations where I needed A transpose. The function call to Matlab's dlyap function was the freaking culprit. That piece of shit is one of those functions that's screwed me in the past, and of course the one time I wasn't careful it bits me in the ass.

Anyway, with the fix the impulse response method now returns basically the same FIR filter coefficients as using data. I also realized that the results from the adaptive loop I posted yesterday were crap. Somehow I was using the wrong model for the closed loop plant, chalk that up to shitty variable names. Here are the proper PSD's and modal outputs


My advisor thinks these results are stellar. Amazingly the PSD with the optimal FIR filter is pretty similar to the AO PSD, hopefully showing that my idea of dividing out the part of the disturbance cancelled by the classical loop is correct. In this case both the adaptive and fixed gain FIR filter are using 4 taps, so you might ask why the AO loop does better than the "optimal" filter at certain frequencies. The reason is that the adaptive loop can compensate somewhat for modeling error.

Right now I'm trying to run things without the shitty DM pause, which speeds things up to around 20Hz. I suspect the results won't be so peachy, but the time savings would be huge (8 minutes vs 40 for 10000 frames), and I wouldn't have to spend so much time quality time with youtube waiting for my experiments to run.

Also, I'd like to look at how the number of filter coefficients changes the steady-state performance, although I don't think adding many more taps will make much difference. Also I'd be cute to have the Strehl ratio performance to look at too.

Peace out.

Case of the Mondays

Here are the first results from using the "optimal" FIR filter, computed using the data-drive approach. Surprisingly it performs pretty well compared to the AO loop, the fact that its not spitting out absolute crap is a small miracle.



Here's a sampling of the modal output


I'm not sure what's going on with the AO loop. Looking at the commands with the adaptive loop closed shows lots of lower-end saturation going on about 1/3 of the time, so something is probably screwed up somewhere in the experiment. Hard to say at the moment since I'm running this remotely from home. The frustrating part is that it takes to friggin long to run an experiment, around 40 minutes for 10000 frames, that its easy to distract my already OCD mindset. I'm going to have to start doing this in simulations first.

This is good for a first step, but there are still some outstanding questions I'd like to look at this week. The first few deal with this optimal FIR filter calculation:

1. Determine what's really causing the difference between the data and impulse response drive methods to finding the optimal gains.

2. What's the real disturbance model that should be used in the calculation? What's the difference between computing it and identifying it from i/o data? Should it be SISO or MISO?

3. How does the filter order affect performance?

4. Write a script to determine the optimal IIR filter by solving an LQR problem.

Also, all of this stuff so far has been for the first focus mode. Sooner or later I'm going to have to do everything over again al MIMO, so I'd be nice to have some heads up if there are potential problems in the road. The first step is to look at the transfer matrix for multiple modes with the classical loop closed. Everything depends on this being diagonal with the same SISO tf on the diagonals. If this doesn't hold to a reasonable extent then there could be serious limitations. With that in mind:

1. How similar are the diagonal transfer functions for each mode? Models identified with significant saturation are garbage.

2. If they're all of the same form, but with a different gain, can the transfer matrix be factored into a single transfer function times a static gain matrix? If so, can this matrix just be incorporated into the poke matrix?

3. What's the difference between doing a MIMO subspace ID and multiple SISO id's?

4. Does the simulation even have enough accuracy to identify the model for multiple channels?

All this will be much faster if I just suck it up and do it in silico first.

8.16.10

Still having trouble getting decent results with the FIR filter. I still can't get the impulse response method to agree with what the least-squares solution spits out, even when I include the noise covariance in the state-space model. I might try a third method, there the filter coefficients are spit out from a finite-time LQR problem.

One thing I noticed is that the disturbance model I use isn't exactly the state-space system identified directly from the disturbances. Instead, its the part of the disturbance left over after going through the classical control loop. After untangling the block diagram, you end up dividing the original disturbance system by some transfer function involving the plant model. The problem I have is that this transfer function might not be exactly minimum phase, so you can end up with an unstable disturbance model to put into your FIR calculation.

I think its time to visit my advisor.

8.10.10 [2]

I feel like I'm loosing the script here, so a quick sitrep on what's going on: I currently have 2 different methods written to calculate the optimal FIR disturbance rejection filter. One uses state-space models of the disturbance and plant to generate impulse response sequences. These can be used to form a Weiner-Hopf problem and solved for the optimal coefficients a la earlier work we did on jitter control. The second method uses the models to simulate data directly. Given enough samples, the solution to another (similar) linear equation yields the coefficients.

Theoretically, both of these should give similar results (I think). But so far no luck. Here's a comparison of the output PSD with filters calculated using each method compared to using no filter (F=1).



I used the actual plant disturbance models I identified from the experiment. Using the data approach works pretty well, although its pretty cumbersome, and would be stupid with multiple modes. The method using the impulse responses, however, is just crap, clearly making things worse.

Confusingly, both methods crap out the identical filter with less complicated disturbance models. I think the problem is that the input noise covariance matrix isn't really accounted for in the state-space model of the disturbance. It comes into play in the data driven case since I have to use it to generate the input, but it doesn't show up directly in the impulse response as the moment. It should be easily, however, to incorporate it into the state-space model by multiplying the input matrix.

Thats the plan for the afternoon, as soon as I finish blogging here in a coffee shop.

8.10.10

After doing a system ID on the new disturbance model, I was finally able to get my "optimal" FIR filter working. Or rather, functional since in the experiment I get saturation and in the simulation I get crap. Right now I'm trying to write a similar script that finds the optimal coefficients by using simulated data directly in the least-squares problem, instead of just impulse response terms. We'll see if I get the same results as with the other method.

I can already see the next stop on this pain train. The adaptive filter basically solves this least-squares problem recursively using either LMS or RLS filter, so the obvious next step is to write my own adaptive code. The only piece missing is my ignorance about writing S-functions for Simulink, but there are hints that I might have to learn that eventually anyway.

One Thing Leads To Another

I think my plan to do a subspace ID on the actual disturbances as measured by the WFS is a good one, but it turned out that the code we have to do it requires the measurements to be on a square grid. Stupidly, I've been using a rectangular 19x22 measurement area on the WFS, with the DM area (found by adding all the influence functions) shifted to the right by around 5 columns. Putting disturbances from a state space model on this odd configuration required scaling the image, shifting it in an attempt to align it with the DM area, an only then performing a least-squares fit with the poke matrix. Naturally the results were shit, as shown in the video in 6.18.10.

My slope calculation code is ludicrously cumbersome, so it took a day to properly rewrite it to use a 19x19 grid (actually a down-sampled 38x38 grid) and make sure it was bug-free. Realigning the beam and removing tilt so that the area for both DMs was centered took another. My advisor commented that he doesn't know how I keep everything straight in my head with so much shit going on. I assured him I have no idea what I'm doing.

Anyway, its good to periodically tinker with the experiment and realign everything anyway to keep my monkey skills sharp. Today I put some state-space generated disturbances on the DM, which now only requires rescaling the state-space output to a slightly larger grid. The resulting phases look much better. Here's a comparison between (L to R) the state-space output (1 phase screen model on a 17x17 grid), the DM phase predicted using the poke matrix (on a 19x19 grid), and the actual phase measured by the WFS (with the bias removed of course).



If you squint you can actually see the similarity in the phases as it flows across the aperture. Either way it much cleaner than the random flatulence I was getting before.

Tomorrow I'll look at how this affects the performance of the adaptive loop. Now that the grid is square I can also go ahead with my original plan and compute an optimal FIR filter.

7.31.10

Ahh crap its August.

Finished some code to calculate the optimal FIR filter (in the SISO case) in the disturbance rejection problem by solving the Weiner-Hopf equations. I have no clue if it works, but it seemed to give non-bullshit answers at the few, simple problems I threw at it. To actually use it in the experiment I have to harness the disturbance state-space model, but because of all the reshaping and massaging required to get the disturbance commands I'm not sure the original model would be valid. Right now I'm working on identifying a new model based on the measured wavefronts, so the basic procedure retardedly involves pulling a subspace ID twice. At that point I'm probably just getting complete nonsense, but its worth a try.

7.26.10

I was able to get the experiment running around 20Hz with Simulink by removing the pause between DM commands. This is great, except it now looks like DM dynamics are definitely screwing things up.

Here's a plot comparing the PSD's from 10000 frames using the same disturbance input and several different plant models.


Clearly using the original plant model in the AO loop, which contains a single delay and PI controller, produces crap; its worse than using just the classical controller. From my ARX experiments with the DM, I found that running at full speed seems to add an additional delay, and sure enough multiplying this ideal plant model with a delay works much better. Unsurprisingly the best results come with identifying a plant model first.

None of these results are as good as what I get with the artificial pause between DM commands, but the time difference is significant (20Hz vs. 4 Hz). I get the feeling this is a fact I'll just have to live with for the time being.