12.15.10

The first 3 of yesterday's stuff went fine. Amazingly I was able to get a license for the driver quickly, so accessing both cameras simultaneously through the same interface is no problem. Current target position seems fine for now, here's an example image with both DMs at the bias voltage.



I'll start looking at performance measures today. Incidentally, here's an illustration of the strange bias WF problem I've been having.



This is a composite of the reference SHWFS image from last night and from this morning. Clearly there's been a change in the focus, which is a mystery since no one's been the lab afaik. This is fixed by adjusting L2 (after the spatial filter), and doing some basic realignment, but its bitch to do correctly.

12.14.10

FIR code still isn't working right. Diagonal terms always seem to be wrong in both the LS and normal-equation versions. I think I'm going to table this for now since I really only need it to compare the performance of the adaptive controller.

I really want to focus on getting the target cam working this week so I can start generating some complete data for possible paper submissions. In the process of getting the driver license right now, but its taking a while due to some admin delays. Luckily I can still access the image (although sometimes with a watermark). Stuff that needs to be done:

- Code to generate camera object in Matlab. Can the target and WFS be active simultaneously?

- Determine some nominal positioning where the spot size is reasonably small.

- Find decent camera settings for said position.

- Reconfig HDR code to use if necessary.

- Look at possible performance metrics. See how they respond to basic WF disturbances (step input to DM61, sinusoidal disturbances in a single mode, etc).

- Look at results using different non-PI controllers.

Ideally I'll have all this done by Friday.

12.6.10

Finally managed to get all 3 control situations running on the same disturbance data. For some reason, the bias WF changes significantly from time to time, forcing me to do a realignment each time. The usual symptom of this is a crappy poke matrix, or highly saturated commands when identifying the CL dist. model.

Anyway, something's screwed up with the adaptive loop (AO) as shown below. In the past (and I think in theory), it has outperformed the LTI loop since it can better compensate for plant modeling error. One possibility is that the adaptive filter order is insufficient (right now, the adaptive filter is FIR with order 4). I think I'm going to update the code I have to compute the optimal FIR filter so I can look at how the theoretical FIR impulse looks.




For tomorrow:
- Update FIR code
- Figure out what the deal is with the target camera so I can get some Strehl ratio measurements.

12.2.10: Plotfest 2010

I put in another beam splitter to send the beam to the target camera, so I wanted to run the LTI loop again to make sure everything was still ok. Luckily things still seem to be working, and I ended up spending most of the day thinking about what plots might be useful in analyzing what's spit out.

The controller only projects the wavefront onto the modes that are controlled, but since the modes aren't totally uncoupled irl, looking at these sequences don't tell the whole story. Instead, I projected the wavefront sequence onto ALL the modes and only looked at the the ones that are controlled. The difference is that there is some cross talk from the higher order modes that you don't see if you neglect them from the projection. For the plots here, the experiment used 25 control modes. The LTI predictor was estimated using 10000 frames with a prediction error around 0.38.

Anyway, one of the more useful plots is obviously the PSD's for each modal sequence. Clearly the classical controller is killing the low frequency/static disturbances but does shit for anything else as expected. The LTI controller does a decent job flattening the spectrum, with surprisingly little high frequency amplification like I was seeing before. My experience has been that this amplification shows up when the predictor model is crap, so I guess it was good enough this time. Plant modeling error should also contribute to that, so if the AO loop does even better I'll have an idea that the closed-loop plant isn't matching the theoretical version in the controller.



Next up is the modal sequence itself for a few of the modes. You can clearly see how the completely open-loop disturbances have zero mean (i.e. in Mode 1), a static error that's knocked out by the integrator. The LTI controller makes quick work of the remaining high-amplitude spikes. One thing I really have to do is estimate a noise floor that shows in the stead-state (with no disturbances) due to the WFS.



The temporal RMS for each mode is also instructive. This is key since sometimes the RMS improvement may not be so impressive even if the PSD's are white. Luckily the LTI improves the RMS for every mode, so I guess they're all fairly well formed on the DM. Note the the integrator sometimes does worse in certain modes, I guess those are being sacrificed for the sake of modes that contribute more to the noise power. i.e., modes with the largest RMS improvement should be the ones that have the highest open-loop value (ex. 6 and 9 compared to 8). Notice that after mode 25 there's almost no improvement as expected. But, there is some difference, indicating the influence of the controlled modes creeping in.



Finally, the time series of the spatial RMS. The top plot shows the spatial RMS from the modal sequence, i.e. the part of the wavefront in the range space of the DM. This is fine, but ultimately the Strehl ratio of the beam depends on the entire wavefront RMS, shown in the bottom plot. This was generated by reconstructing the phase directly from the slope vector instead of just projecting it onto the range of the poke matrix. Before, when few modes were used, I think there wasn't much improvement between the controllers in this plot, and subsequently that's why there was little improvement in the Strehl as measured by the target. Based on this guy, if the Marechall approximation is true I should see some significant improvement in the measured Strehl when I finally get the target camera set up again (hopefully tomorrow.



That's all for now. gjdm.

11.30.10

With everything (basically) working, and a reasonable way to generate disturbances, I was able to run the full-blown IIR controller yesterday without any problems. I'd like to be a little more rigorous though and so some id on the closed-loop plant, and play around more with the number of modes to get a sense of how the handling is going to be. Luckily, running 5000 samples takes a few minutes now instead of an hour.

- Verify closed-loop (classical) plant matches model
- Close classical loop with different number of modes. Any instability or saturation?
- Set up target camera with CMU driver

The objective is to have the target camera working, and a good idea of the max number of modes I can use by the end of the week.

11.23.10

Many re-installations, a new software version, much cursing, and a birthday later, I finally have everything (relatively) working with the WFS. Frame rates at the ~260x260px resolution I'm using now are around 250-300 fps, but for some reason in Matlab I'm limited to a mere 30-40. The external trigger guarantees that each frame is fresh though, so this is still an order of magnitude faster than before with that ridiculous artificial pause. I suspect the frame rate problem has to do with the bytes per packet, which I can't seem to change from Matlab directly.

Anyway, at the moment that's a minor problem. This new speed means that generating a poke matrix only takes around 10 seconds. Here's an example after a few realignments:

Recall that I'm now doing differential measurements . I've tried to correct for the bias WF as much as possible, but its no a pure focus so moving lenses around won't completely obliterate it. Surprisingly, most of the modes are recognizable on the 9x9 measurement grid. For comparison, here are the ideal mode shapes resized to that grid from an original 128x128 image:


Most of them look pretty good, and the higher frequency ones might still be usable. The next step is mapping disturbances on the DM. Right now I'm trying to work out a more systematic way of doing that instead of just blindly using the reconstructor matrix. I'm thinking that projecting the desired WF onto a set of modes, other than the DM modes for the 61 actuator mirror, might be useful for this purpose. Maybe PCA modes from the original data or SVD modes of the DM.

11.12.10

Unbelievably I spent all of last week dealing with .NET issues. Mainly, I couldn't get Matlab to load the assemblies I needed to control the DM or connect to the WFS camera.

Mysteriously the problem with the DM assemblies fixed itself after reinstalling things in apparently the right order. The camera issue took a few conference calls and some digging through some arcane .NET barf logs. We finally figured out that the version of some dll the camera driver needed was slightly out of date, like v1.0.0.1 instead of v1.1.0.0, and this was enough to basically send my week down the toilet.

All's good now. I'll have to re-write some code to use the new driver, but that should be minor. The triggering, the whole reason for doing all this shit, still isn't working because of, surprise surprise, a problem loading a .NET assembly. I'll muck around with it more on Monday to see if I can sort the problem out, but my patience for fixing this shit on my own is basically nonexistant. I'm sure another conference call is on the horizon.

Hey, at least I was able to modify the driver box to accept the triggering cable without soldering anything. Who knew IDC connectors were so useful?

Stuff to finish off in the next few days (by Monday):
- Email about triggering problem
- Rewrite code to use new cam driver
- Verify it works with embedded matlab
- This .NET camera interface has no built-in preview method, so maybe I could cook one up with some incredible GUI interface

Tuesday and the rest of the week should be left to alignment, and verifying the triggering is working (using the ARX model stuff).

W7 Upgrade During Action Report

Installing the hw trigger requires a different camera driver, so rather than try to remove all the remnants of the old one I decided to wipe out my entire system and upgrade to x64. Surprise surprise, upgrading to W7 has turned out to be a huge time vampire, with the usual bullshit-every-step-of-the-way syndrome.

Invariably I'll have to go through this crap again in the near future, so to help prevent another lost week here's brief rundown of some of the problems and solutions.

Problem 1: PC wouldn't start up from W7 x64 install CD. Creating multiple CD's from different ISO's did nothing.
Solution: Created an ISO from an install CD (on my Mac no less), then used the "Windows 7 USB/DVD Download Tool" to create a bootable USB drive. But this required...

Problem 2: Since I was upgrading from XP x86 to W7 x64, the USB/DVD Download stuff required an additional program to create the MBR on the USB drive. Normally you have to download this from MS based on your purchase history, but since my ISO came from a MSDN site I had no download history.
Solution: Thankfully this is a common problem and someone on the interwebs posted a direct link to what I needed.

Problem 3: W7 activation couldn't find the DNS server to register the product key.
Solution: After a few emails to the campus network overlords, they sent me the direct address.

Problem 4: Installing video card driver resulted in everyone's favorite BSOD.
Solution: Quickly unplug all USB connections right before installer begins. Seriously.

There were other, but you get the gist.

10.28.10

Next couple days:

Thursday:
- more poke matrix adjustments
- identify components to upgrade (HD, ram)
- look into some kind of pin connector in lieu of soldering
- back up data

Friday-Sunday:
- gather installation disks
- install new hardware
- install matlab and w7
- install new optics software
- review matlab code examples

Monday:
- profit

10.26.10

Yesterday I finished the code to compute the differential slope measurements. I was able to get a decent looking poke matrix out of it after finding the right size perturbations. Of course, since the new WFS grid is only 9x9, the modal images are roughly a quarter the resolution, so some of them look more like crumpled paper without squinting. I'm probably bumping up against the spatial Nyquist with the higher modes, but I'm far to lazy to quantify that. I suspect that some of the higher DM61 modes are unobservable, although its uncertain what use those are anyway.

With that done I managed to get a stable integrator running, but of course since all the measurement are differential right now, there was basically nothing to compensate. Today I finished rewriting the code to generate disturbance commands matching the output from the state-space models, so the next step is to try out the LTI and adaptive loops (first in silico obviously).

I also tried using the pixel sub-sampling mode on the WFS, which halves the image resolution but can quadruple the frame rate. Sure enough, I was able to get nearly 450fps out of it using the current beam size; huge considering just a couple weeks ago I was struggling to get 20 fps. Obviously reducing the image resolution decreases the sensitivity of the WFS, but this might not be a problem for my purposes. The advantage of doing differential measurements is that I can basically use this mode with few code modifications. I would just have to define a new reference grid with this smaller resolution.

The next (hopefully final...please let it be final) hardware step is to get the camera triggering working so I can actually use these superfast frame rates. I've set the ball in motion on this, but it looks like its going to be pretty involved, requiring a new cam driver and modifications to the DM driver so I can use the existing NI board to generate the trigger. Having this running by the end of next week will be a tall order, but not outrageous if I can get the software in time.

Make it so.

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.