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
Wednesday, October 27, 2010
Tuesday, October 26, 2010
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.
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.
Friday, October 22, 2010
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.
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.
Thursday, October 21, 2010
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.
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.
Thursday, October 14, 2010
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.
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.
Tuesday, October 05, 2010
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.
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.
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.
Subscribe to:
Comments (Atom)
