Last week I finished writing a new slope calculation script based on idea of using 2 linear operators and dividing the result. IS this faster than looping through each sub-aperture in Matlab? Nope.
The problem is that the matrix to calculate the unnormalized slopes is 2N*M, where N is the number of sub-apertures and M is the total number of pixels in the image. Since the WFS has around 1600 sub-apertures, and the image is more than 1000x1000, this matrix is gigantic. Even though its sparse, it takes up more than 1.5 MB of space. The matrix to calculate the total intensity of each sub-aperture is around the same order of magnitude, so combined the script has to load over 2MB of data each time a WFS image is captured. This takes more than a second in Matlab, so that option is off the table for now. Simply loading them into the workspace beforehand and passing them to the script is much faster, but still around the same speed as using loops.
Ultimately, when I get the DM working faster (still waiting for word on that from the manufacturer), I'll have to write the slope algorithm as a mex file and run it in C. What's another wasted week?
Tuesday, July 28, 2009
Wednesday, July 22, 2009
Faster
I've heard from the company that manufactures our DM and WFS that they can achieve frame rates an order of magnitude higher than what I'm capable of doing, around 800 Hz. This blows my mind since I have no idea how I make any more than incremental improvements with the Matlab commands I'm using now. In a sense this pisses me off since I'm not sure how we would have found this out if my advisor hadn't brought it up. It seems common in this industry for companies to ignore what most people are doing and write their own, barely adequate, proprietary software, and then go into stealth mode with the support.
Anyway, we're focusing on the DM first since that's most likely the harder problem. I'm actually skeptical they can get the frame rates they claim, but who knows. I've sent them the code I'm current using-code that was adapted from stuff they sent us-so I should hear something soon. I fully expect to hear complaints about a variety of minor coding transgressions and other shit that doesn't matter.
Nonetheless, I'm assuming that I can eventually speed things up significantly on the hardware side, which means that my software will have to change as well. Right now the most significant software bottleneck is the script for calculating the slope vector from the WFS image. For a full frame 1280x1024 Hartmann image, calculating the slopes in Matlab takes around 0.08 seconds for a grid of around 40x40 lenselets. The problem, as I mentioned before, is that finding the centroids is not a linear operation since you have to divide by the sub-aperature intensity, thus you can't just multiply the image by some matrix. Loops in Matlab are shit, so looping over all the sub-aperatures is what causes most of the delay.
Right now I'd like to try to reduce the computation time in Matlab by reducing the centroid calculation to 2 linear operations on the image. if I is the vectorized image, then there is a (sparse, large) matrix A such that S1 = A*I, where S1 is a vector of unnormalized slopes. There is also another matrix Q such that L = Q*I where L contains the total intensity in each sub-aperature. The slope vector is then (in Matlab speak) S = S1./[L;L] (since S1 contains x and y slopes).
I have no idea if this is really faster, but there's enough evidence to give it a try. Coming up with A efficiently though isn't easy, but hopetully I'll finish that tomorrow.
Anyway, we're focusing on the DM first since that's most likely the harder problem. I'm actually skeptical they can get the frame rates they claim, but who knows. I've sent them the code I'm current using-code that was adapted from stuff they sent us-so I should hear something soon. I fully expect to hear complaints about a variety of minor coding transgressions and other shit that doesn't matter.
Nonetheless, I'm assuming that I can eventually speed things up significantly on the hardware side, which means that my software will have to change as well. Right now the most significant software bottleneck is the script for calculating the slope vector from the WFS image. For a full frame 1280x1024 Hartmann image, calculating the slopes in Matlab takes around 0.08 seconds for a grid of around 40x40 lenselets. The problem, as I mentioned before, is that finding the centroids is not a linear operation since you have to divide by the sub-aperature intensity, thus you can't just multiply the image by some matrix. Loops in Matlab are shit, so looping over all the sub-aperatures is what causes most of the delay.
Right now I'd like to try to reduce the computation time in Matlab by reducing the centroid calculation to 2 linear operations on the image. if I is the vectorized image, then there is a (sparse, large) matrix A such that S1 = A*I, where S1 is a vector of unnormalized slopes. There is also another matrix Q such that L = Q*I where L contains the total intensity in each sub-aperature. The slope vector is then (in Matlab speak) S = S1./[L;L] (since S1 contains x and y slopes).
I have no idea if this is really faster, but there's enough evidence to give it a try. Coming up with A efficiently though isn't easy, but hopetully I'll finish that tomorrow.
Sunday, July 19, 2009
5.19.09
Last weekend I ran a couple long SPGD experiments with and without the SLM to see if it had any noticeable effect on the performance. I ran each lasted for around 10,000 iterations, and since I can only update the SLM every 3 seconds they each took over 8 frickin hours to run. I feel like a biologist.
For the "w/ SLM" case the image was set to a focus with a sinusoidally varying intensity such that the maximum phase distortion occurs at the center of the focus at the peak sinusoidal amplitue. Maybe I'm just cynical, but its not really clear to me that the SLM has any effect. Its nice the the algorithm can sort of maximize the image cost function (J), ignoring those unexplained spikes, but its hard to distinguish any difference between the 2 cases. Control starts at k=1000.
Here's a close up of a section of the uncontrolled iterations.
The SLM obviously has an effect on the objective function, but its not much, and it doesn't look like that effect more than the noise from calculating the image objective function. What is clear though is that unless I can speed things up, using the SLM at all is totally impractical. This 3 second bullshit can't go on if I'm going to really be using it.
For the "w/ SLM" case the image was set to a focus with a sinusoidally varying intensity such that the maximum phase distortion occurs at the center of the focus at the peak sinusoidal amplitue. Maybe I'm just cynical, but its not really clear to me that the SLM has any effect. Its nice the the algorithm can sort of maximize the image cost function (J), ignoring those unexplained spikes, but its hard to distinguish any difference between the 2 cases. Control starts at k=1000.
Here's a close up of a section of the uncontrolled iterations.
The SLM obviously has an effect on the objective function, but its not much, and it doesn't look like that effect more than the noise from calculating the image objective function. What is clear though is that unless I can speed things up, using the SLM at all is totally impractical. This 3 second bullshit can't go on if I'm going to really be using it.
Thursday, July 09, 2009
I'm not totally convinced the SLM is doing much to the phase. I'm pretty sure its working, but since I'm not measuring the phase directly I don't know if a single wavelength of change is much.
It's clear that something is happening. Here's a plot of the target image variance (J) and slope vector norm with the SLM active. At 300 iterations it displays a focus shape (not that easy to calculate efficiently!) where the amplitude varies sinusoidally from the max displacement to min.
The good news is that the sinusoidal pattern is reflected in both objective functions. But although the change is visible, its miniscule percentage compared to what's available with the DM. As a comparison, the maximum stroke of the DM is in the range of 10 microns. The SLM is limited to 2pi rad, about 650 nm. This wouldn't matter much if I were mapping the phase measurement back to the range of [0,2pi], such as with a SRI. But since I'm not measuring the phase directly, I'm not sure how variations like that are mapped in a Hartmann sensor.
The other problem is the ludicrously slow response time of the SLR, which I still have to limit to 1/3 Hz. Given the shit this thing has given me over the last few months, I think the best plan of action is to convince my advisor to ditch the SLM and get another DM. That will require me to exhaust all obvious ways to speed things up, but at this rate that shouldn't be hard.
It's clear that something is happening. Here's a plot of the target image variance (J) and slope vector norm with the SLM active. At 300 iterations it displays a focus shape (not that easy to calculate efficiently!) where the amplitude varies sinusoidally from the max displacement to min.
The good news is that the sinusoidal pattern is reflected in both objective functions. But although the change is visible, its miniscule percentage compared to what's available with the DM. As a comparison, the maximum stroke of the DM is in the range of 10 microns. The SLM is limited to 2pi rad, about 650 nm. This wouldn't matter much if I were mapping the phase measurement back to the range of [0,2pi], such as with a SRI. But since I'm not measuring the phase directly, I'm not sure how variations like that are mapped in a Hartmann sensor.
The other problem is the ludicrously slow response time of the SLR, which I still have to limit to 1/3 Hz. Given the shit this thing has given me over the last few months, I think the best plan of action is to convince my advisor to ditch the SLM and get another DM. That will require me to exhaust all obvious ways to speed things up, but at this rate that shouldn't be hard.
Wednesday, July 08, 2009
Damn the torpedoes
I'm finally back in the swing of things after my little excursion to the Old World. Its amazing how difficult it is to get used to "work" again.
The SLM is still heinously slow, still limited to around 1/3 Hz....yes 1 frame every 3 seconds. Personally, I think its unlikely I'll ever find a solution to this, but right now the best hope for a fix is to try using with with the other SLM's hardware (which is working fine). I'm also going to email BNL, but since I didn't write the modified code to control it using Matlab, doubt that'll result in anything useful.
Nevertheless, I'm going on as if everything was operating normally. I've devoted this week to determining if the SLM is doing anything at all. Here's a plot showing a few relevant objective functions as a focus bias was applied to the SLM with sinusoidally varying intensity. Since the bitch has been fighting me every step of the way, I was surprised to see actual sinusoidal responses here, even though their amplitude might be too small to be useful. The DM was stationary in the bias position for these experiments, and the SLM is set to zero until iteration 300:
Of course, at 1/3 Hz, these experiments take half an hour to perform. Nonetheless, there's at least an indication that the SLM may be useful to generate disturbances if I can get it moving faster. For tomorrow, I'd like begin adding such SLM disturbances into the SPGD algorithm, even though a full experiment might take a day to run (I can do it over night if necessary).
As another side project, my advisor wants me to characterize the response times of each component in my system. Unfortunately he's starting to think about real-time experiments, which seems infeasible now considering the problems I'm already having.
The SLM is still heinously slow, still limited to around 1/3 Hz....yes 1 frame every 3 seconds. Personally, I think its unlikely I'll ever find a solution to this, but right now the best hope for a fix is to try using with with the other SLM's hardware (which is working fine). I'm also going to email BNL, but since I didn't write the modified code to control it using Matlab, doubt that'll result in anything useful.
Nevertheless, I'm going on as if everything was operating normally. I've devoted this week to determining if the SLM is doing anything at all. Here's a plot showing a few relevant objective functions as a focus bias was applied to the SLM with sinusoidally varying intensity. Since the bitch has been fighting me every step of the way, I was surprised to see actual sinusoidal responses here, even though their amplitude might be too small to be useful. The DM was stationary in the bias position for these experiments, and the SLM is set to zero until iteration 300:
Of course, at 1/3 Hz, these experiments take half an hour to perform. Nonetheless, there's at least an indication that the SLM may be useful to generate disturbances if I can get it moving faster. For tomorrow, I'd like begin adding such SLM disturbances into the SPGD algorithm, even though a full experiment might take a day to run (I can do it over night if necessary).
As another side project, my advisor wants me to characterize the response times of each component in my system. Unfortunately he's starting to think about real-time experiments, which seems infeasible now considering the problems I'm already having.
Monday, June 29, 2009
Thursday, June 18, 2009
6.18.09
I've been fiddling more with my setup this week to get the classical and SPGD algorithms working like I expect them to, and think I about have it. Most of the hassle involved positioning the target camera. Interestingly, the SPGD algorithm was able to successfully maximize Strehl ratio from the image, but the PI controller with the WFS failed to achieve the same steady state performance. Ultimately, I think the reason for this was that the target camera was positioned slightly off plane, so an unaberrated phase didn't result in a focused spot.
Tomorrow I want to try running these algorithms with some significant, static SLM disturbance. I still can't send commands to the frickin thing faster than 1/3 Hz, so dynamic disturbance simulations are going to be sloooow until I can get that resolved.
Tomorrow I want to try running these algorithms with some significant, static SLM disturbance. I still can't send commands to the frickin thing faster than 1/3 Hz, so dynamic disturbance simulations are going to be sloooow until I can get that resolved.
Sunday, June 14, 2009
Distracted
I got a new laptop this week, so progress was...muted. I was able to write some code to generate superpixels for the SLM, and I used it to get some preliminary poke matrix data. Basically the phase response is pretty strange as the individual pixel values change and I haven't quite figured it out yet. I did learn though that the WFS isn't capable of really detecting unit changes in pixel values, however. Luckily this doesn't really matter much since I intend to use the SLM primarily to product noise of a particular bandwidth.
I have a large trip planned at the end of next week, so I'm not sure how preoccupied I'll be over the next few days preparing. Ideally, I'd like to take another look at the experimental implementation of the gradient descent and look at how it responds to (slowly) changing disturbances. Maybe like step changes every 100 iterations or something like that.
I have a large trip planned at the end of next week, so I'm not sure how preoccupied I'll be over the next few days preparing. Ideally, I'd like to take another look at the experimental implementation of the gradient descent and look at how it responds to (slowly) changing disturbances. Maybe like step changes every 100 iterations or something like that.
Tuesday, June 09, 2009
Case of the Mondays
My adviser and one of the post-docs are out at a conference this weeks, so I'm practically alone in lab this week. Its hard to find motivation.
Today I aligned the target camera, so for the first time I have all my devices together in a single experiment: laser, DM, SLM, target camera, and WFS. Hey it only took a year!
I also finished the Simulink model that I can use to close the AO loop with any desired controller (although right now its using Simulink's integral controller block). To finish it off I added a block that reads images from the target camera and computes the image variance, although its easy to change that to any other desired performance metric.
Currently, the controller doesn't provide much improvement in the wavefront variance. I suspect this is probably because the phase is fairly flat to to begin with, and any aberration is relatively of high frequency and can't be corrected with the DM. Now that I have control of the SLM, the goal this week is to introduce (static) artificial disturbances and see how well the classical controller compensates. Next week I'd like to try some basic dynamic disturbances.
So the plan for this week:
1. Finish alignment, check tilt modes
2. Write a script to generate SLM poke matrix, begin applying static disturbances that result in a know slope disturbance.
3. Investigate performance of gradient descent algorithm using identified turbulence models.
4. Create Simulink model that implements gradient descent controller with an arbitrary performance metric.
Today I aligned the target camera, so for the first time I have all my devices together in a single experiment: laser, DM, SLM, target camera, and WFS. Hey it only took a year!
I also finished the Simulink model that I can use to close the AO loop with any desired controller (although right now its using Simulink's integral controller block). To finish it off I added a block that reads images from the target camera and computes the image variance, although its easy to change that to any other desired performance metric.
Currently, the controller doesn't provide much improvement in the wavefront variance. I suspect this is probably because the phase is fairly flat to to begin with, and any aberration is relatively of high frequency and can't be corrected with the DM. Now that I have control of the SLM, the goal this week is to introduce (static) artificial disturbances and see how well the classical controller compensates. Next week I'd like to try some basic dynamic disturbances.
So the plan for this week:
1. Finish alignment, check tilt modes
2. Write a script to generate SLM poke matrix, begin applying static disturbances that result in a know slope disturbance.
3. Investigate performance of gradient descent algorithm using identified turbulence models.
4. Create Simulink model that implements gradient descent controller with an arbitrary performance metric.
Thursday, June 04, 2009
6.4.09
I've spent most of this week porting my control algorithms to Simulink and the "suggestion" of my adviser. Conceptually this shouldn't be that hard since I already have a simulation using the experimental poke matrices. Reading the WFS image is trivial with the image acquisition toolbox. However implementing my custom code for calculating slopes and sending commands to the mirror requires me to use these Embedded Matlab blocks that translate m-files into C code for execution in Simulink, and that process involves a whole shit storm of issues. I found a pretty simple, slightly cheating, way of doing it that basically just involves calling my existing code as "extrinsic" functions that don't compile into C, but instead run in the Matlab workspace. This seems to work pretty well and right now I have my PI controller running beautifully (albeit slowly) in Simulink.
I've gotten the code necessary to control the SLM from Matlab as well, and its pretty clunky and generally crap, although I guess its functional enough to use. Getting it to work in Simulink as above though is, not surprisingly, a pain in the ass.
Tomorrow we meet with some Ophthalmologists to see if we can use any AO techniques on their retinal imaging machines. This has been done before by some people at Berkeley, so what they ask for might not be particularly novel, probably difficult (getting the optics setup), and from a control perspective not very interesting (the phase distortion of the eye is basically constant). Still, it doesn't hurt to talk.
I've gotten the code necessary to control the SLM from Matlab as well, and its pretty clunky and generally crap, although I guess its functional enough to use. Getting it to work in Simulink as above though is, not surprisingly, a pain in the ass.
Tomorrow we meet with some Ophthalmologists to see if we can use any AO techniques on their retinal imaging machines. This has been done before by some people at Berkeley, so what they ask for might not be particularly novel, probably difficult (getting the optics setup), and from a control perspective not very interesting (the phase distortion of the eye is basically constant). Still, it doesn't hurt to talk.
Thursday, May 28, 2009
Wednesday, May 27, 2009
1. Cut a Hole in a Box
Finally received all the cables to install the SLM. In one final kick to the balls the connector for this new cable was too wide for the back of my PC case, so I had to pry this pointless plastic cover off the back. Why Dell shields their cases with useless crap like that I don't know.
I did some basic realignment and it looks like everything is attached correctly. Tomorrow I'll do some testing to see if the SLM's producing the phase changes its supposed to. After that, I need to figure out a way to get it working from Matlab.
In other news I've been working on the SPGD simulation with dynamic colored noise and multiple channels. To my surprise it actually works pretty well if the noise is kept to around 1% of the Nyquist frequency, but my adviser tells me this is pretty good. The idea is that by using the Strehl as the cost criteria potentially allows for the use of a photodiode instead of a full wavefront sensor. Thus, performance would probably only limited by the bandwidth of the DM controller, rather than the WFS framerate. Ideally, this would mean that sampling rates in the KHz range would be possible (and cheap).
Here are some typical results using 3 channels. More channels seem to work, but tuning the parameters is a bitch. In particular, the spikes in the cost function can be reduced by increasing the size of the perturbations, which (I think) get swamped by the disturbance sequence with higher noise variances.
Control begins at iteration 5000. This plot doesn't show the change in the cost function due to the dithering at each step to estimate the gradient. Its hard to tell from the plot, but the controlled cost function has an average value that is around 40% of the uncontrolled average. Note that these results don't look as good as those a couple days ago. In those results I forgot that I had a sinusoidal disturbance in addition to the colored noise sequence.
I did some basic realignment and it looks like everything is attached correctly. Tomorrow I'll do some testing to see if the SLM's producing the phase changes its supposed to. After that, I need to figure out a way to get it working from Matlab.
In other news I've been working on the SPGD simulation with dynamic colored noise and multiple channels. To my surprise it actually works pretty well if the noise is kept to around 1% of the Nyquist frequency, but my adviser tells me this is pretty good. The idea is that by using the Strehl as the cost criteria potentially allows for the use of a photodiode instead of a full wavefront sensor. Thus, performance would probably only limited by the bandwidth of the DM controller, rather than the WFS framerate. Ideally, this would mean that sampling rates in the KHz range would be possible (and cheap).
Here are some typical results using 3 channels. More channels seem to work, but tuning the parameters is a bitch. In particular, the spikes in the cost function can be reduced by increasing the size of the perturbations, which (I think) get swamped by the disturbance sequence with higher noise variances.
Control begins at iteration 5000. This plot doesn't show the change in the cost function due to the dithering at each step to estimate the gradient. Its hard to tell from the plot, but the controlled cost function has an average value that is around 40% of the uncontrolled average. Note that these results don't look as good as those a couple days ago. In those results I forgot that I had a sinusoidal disturbance in addition to the colored noise sequence.
Tuesday, May 26, 2009
5.26.09
My gradient descent simulation is showing some progress in rejecting dynamic disturbances. Here's a plot showing the cost function (log of the Strehl ratio using the Marichal approx), noise term, and control sequence using a noise bandwidth that's 1% of the Nyquist frequency. Control starts at 5000 iterations.
My view at the moment is that the command sequence essentially acts as a first order system, exponentially changing in response to a step disturbance. The transient response of this system is governed by the size of the optimization step. So as long as the period of the dynamic disturbances are sufficiently larger than the rise time, the algorithm shouldn't have a problem rejecting it.
This analogy isn't exactly correct since the gradient must be estimated at each step, and the step size is only constant if the normalize gradient and constant gain are used, which isn't always the case. Still, the problem basically boils down to finding a control gain large enough to provide convergence, but small enough to be stable. Even more, since the objective function is basically quadratic, there's probably some way to quantify the optimal step size, but I'm too lazy at the moment to spend much time on that street.
The current simulation is very simple, using a single channel with no poke matrices or actuator nonlinearities. The next step still be to gradually introduce these features until I have a realistic model. If this works at all, it might be worth looking into other first-order algorithms that have even faster convergence properties. i.e. pseudo-Newton and Nesterov's.
My view at the moment is that the command sequence essentially acts as a first order system, exponentially changing in response to a step disturbance. The transient response of this system is governed by the size of the optimization step. So as long as the period of the dynamic disturbances are sufficiently larger than the rise time, the algorithm shouldn't have a problem rejecting it.
This analogy isn't exactly correct since the gradient must be estimated at each step, and the step size is only constant if the normalize gradient and constant gain are used, which isn't always the case. Still, the problem basically boils down to finding a control gain large enough to provide convergence, but small enough to be stable. Even more, since the objective function is basically quadratic, there's probably some way to quantify the optimal step size, but I'm too lazy at the moment to spend much time on that street.
The current simulation is very simple, using a single channel with no poke matrices or actuator nonlinearities. The next step still be to gradually introduce these features until I have a realistic model. If this works at all, it might be worth looking into other first-order algorithms that have even faster convergence properties. i.e. pseudo-Newton and Nesterov's.
Thursday, May 21, 2009
5.20.09
I gave up waiting for a reply about the SLM cables, so I went ahead and ordered what I think are the right ones. Hopefully they'll be here next week.
Until then I've gone back to testing out gradient descent methods on a more complicated model, and using the "Marishal approximation" of the strehl ratio. Because this equation is a log-concave function of the wavefront (spatial) variance, I should be able to apply any number of nonlinear, first-order optimization techniques as long as I can get an accurate estimate of the gradient. In contrast to my previous experiments with this, I've added a colored noise term that corrupts the wavefront with some bandwidth. The question is how can I obtain an accurate gradient estimate in the presence of such garbage? And how are those estimates corroded by increasing the bandwidth (and hence correlation) of the noisy input?
Another person in my lab is trying to work the same problem with an extended Kalman filter, which know nothing about. This perspective views the Strehl ratio approximation as a nonlinear observer of the system's state. There are some notes online from some Stanford course (EE236) that has a good explanation of the EKF, so I might have to read that over at some point.
Until then I've gone back to testing out gradient descent methods on a more complicated model, and using the "Marishal approximation" of the strehl ratio. Because this equation is a log-concave function of the wavefront (spatial) variance, I should be able to apply any number of nonlinear, first-order optimization techniques as long as I can get an accurate estimate of the gradient. In contrast to my previous experiments with this, I've added a colored noise term that corrupts the wavefront with some bandwidth. The question is how can I obtain an accurate gradient estimate in the presence of such garbage? And how are those estimates corroded by increasing the bandwidth (and hence correlation) of the noisy input?
Another person in my lab is trying to work the same problem with an extended Kalman filter, which know nothing about. This perspective views the Strehl ratio approximation as a nonlinear observer of the system's state. There are some notes online from some Stanford course (EE236) that has a good explanation of the EKF, so I might have to read that over at some point.
Tuesday, May 19, 2009
5.18.09
The last couple days have been a frustrating string of delays in gathering the components I need to install the SLM. At the moment, I'm trying to get longer cables to connect the DAC board to my PC, since the supplied cables are retardedly short. The exact type of cable isn't specified in the thin manual that I have for it, and it doesn't help that there are a million nearly identical types of scsi connectors. So after scouring the net for images of obscure 20 year old cables, I finally emailed the manufacturer. Hopefully they'll get back to me tomorrow and will be willing to spill the info. Ahh the joys of experimental research.
In the mean time I'm continuing to review some controls material, particularly adaptive filtering and digital control. I was happy to find out that my adviser is pretty interested in trying these Laguerre lattice filters, but I have a ways to go in my review before I get to that level.
In the mean time I'm continuing to review some controls material, particularly adaptive filtering and digital control. I was happy to find out that my adviser is pretty interested in trying these Laguerre lattice filters, but I have a ways to go in my review before I get to that level.
Tuesday, May 12, 2009
FIR, LMS, RLS, WTF?
Now that my hardware setup is approaching something near its final form, I think its time to start thinking about what I'd like to accomplish here come check out time. Thus, I present...
A 7 point plan for dissertation ass kicking:
1. Finish configuring the SLM to generate disturbances. If that fails, use a DM or other active optical element. These disturbances should originate, using various simulation parameters, from the HEL simulation.
2. Try basic classical AO controllers with said disturbances. Characterize bandwidth properties and relationship to number of modes used.
3. Try "blind" optimization algorithms using target camera information only. Ideally, the cost function used would be somehow related to the Strehl ratio, and could be measured using a photodiode if desired (e.g. intensity). Some interesting first-order algorithms to try include: simple gradient descent, quasi-newton, gradient mapping, and (not first-order) interior point methods.
4. With dynamic disturbances, try to identify a FIR controller using LMS offline. In real time, use a basic RLS fixed-order controllers.
5. Lattice based, order-recursive FIR controllers
6. RLS Laguerre, order-recursive IIR controllers
7. Try RLS adaptation using some other set of orthogonal transfer functions. Maybe something could be done here using Q-parametrization.
That last one might be off in la-la land, but if there's time it could be interesting. S. Boyd's book on Linear Controller Design might have some interesting material related to that.
A 7 point plan for dissertation ass kicking:
1. Finish configuring the SLM to generate disturbances. If that fails, use a DM or other active optical element. These disturbances should originate, using various simulation parameters, from the HEL simulation.
2. Try basic classical AO controllers with said disturbances. Characterize bandwidth properties and relationship to number of modes used.
3. Try "blind" optimization algorithms using target camera information only. Ideally, the cost function used would be somehow related to the Strehl ratio, and could be measured using a photodiode if desired (e.g. intensity). Some interesting first-order algorithms to try include: simple gradient descent, quasi-newton, gradient mapping, and (not first-order) interior point methods.
4. With dynamic disturbances, try to identify a FIR controller using LMS offline. In real time, use a basic RLS fixed-order controllers.
5. Lattice based, order-recursive FIR controllers
6. RLS Laguerre, order-recursive IIR controllers
7. Try RLS adaptation using some other set of orthogonal transfer functions. Maybe something could be done here using Q-parametrization.
That last one might be off in la-la land, but if there's time it could be interesting. S. Boyd's book on Linear Controller Design might have some interesting material related to that.
Monday, May 11, 2009
5.11.09
Truncating the sensor image turned out not to be the nightmare I thought it would be, so removing shadowed spots from the slope calculation seems to work pretty well. The classical controller seems to do a pretty good job flattening the phase, here's a before and after comparison of the reconstructed phase:
The norm of the wavefront slope error isn't really reduced much, <10 percent usually, but I think this is because the reference wavefront is already pretty flat. Right now I'm playing around with deliberately adding a strong focus bias by moving a lens to see if the controller can still compensate.
The norm of the wavefront slope error isn't really reduced much, <10 percent usually, but I think this is because the reference wavefront is already pretty flat. Right now I'm playing around with deliberately adding a strong focus bias by moving a lens to see if the controller can still compensate.
Friday, May 08, 2009
5.8.09
More classical control stuff today. It seems like there's a problem with the WFS measurements. Although the controller successfully reduces the measured slope norm, reconstructing the actual wavefront reveals a deeper story:
The top plot is the reconstructed phase with zero command (dac=180), while the bottom is with the steady-state control value. Clearly the end result has more phase variation in the center, even though the slope norm is minimized. I think the problem is at the corners. Physically, the WFS has a long barrel opening before the image plane, and this is causing some corner sub-apertures to be shadowed. Currently, my code just sets the slopes at these these locations to zero, and I think that's causing the reconstructed phase surface to dive at the corners like that.
The result is this artificial bowl shape, and this causes a large projection into the focus DM mode even though most of the reference wavefront is pretty flat. It looks like the controller is attempting to compensate for this by depressing the center. Touching, but ultimately wrong. Note that this wasn't a problem in generating the poke matrix, since in that case I was subtracting out the reference wavefront from each measurement. Here I'm attempting to reduce the total wavefront.
To solve this I'll have to change my code to exclude those slope measurements from the corners, rather than just set them to zero. This isn't as easy as it sounds, since the indexing there and in the phase reconstructor is gnarly. If it doesn't drive me insane I'll hopefully have that done Monday.
The top plot is the reconstructed phase with zero command (dac=180), while the bottom is with the steady-state control value. Clearly the end result has more phase variation in the center, even though the slope norm is minimized. I think the problem is at the corners. Physically, the WFS has a long barrel opening before the image plane, and this is causing some corner sub-apertures to be shadowed. Currently, my code just sets the slopes at these these locations to zero, and I think that's causing the reconstructed phase surface to dive at the corners like that.
The result is this artificial bowl shape, and this causes a large projection into the focus DM mode even though most of the reference wavefront is pretty flat. It looks like the controller is attempting to compensate for this by depressing the center. Touching, but ultimately wrong. Note that this wasn't a problem in generating the poke matrix, since in that case I was subtracting out the reference wavefront from each measurement. Here I'm attempting to reduce the total wavefront.
To solve this I'll have to change my code to exclude those slope measurements from the corners, rather than just set them to zero. This isn't as easy as it sounds, since the indexing there and in the phase reconstructor is gnarly. If it doesn't drive me insane I'll hopefully have that done Monday.
Thursday, May 07, 2009
5.7.09
After a few setbacks, I finally have the experiment hardware set up with the SLM in place, although its not attached to my PC yet. Basically, I had to add another beam splitter and 2 new lenses to accommodate another actuator, and for some reason this really magnified intensity distortion in the laser spot. The result was that the classical AO controller wasn't able to handle more than 2 or 3 modes before the sensor started returning bad data. To fix this I changed laser (which meant changing the focusing optics), and after days and days of tinkering, I finally have it working pretty well.
Another note is that almost all of the beam reflected off of the DM must hit the sensor. Anything else and things go to hell for some reason.
Right now the SLM is just there passively as I run through all my control code to test for goodness, but over the next few days I'd like to get it attached to my computer and taking commands from matlab. This requires a PCI card that I have to find, so it could take some time. There's some question about whether this SLM works, but I'm open to using another DM if I have to, although that would take months to order.
Another note is that almost all of the beam reflected off of the DM must hit the sensor. Anything else and things go to hell for some reason.
Right now the SLM is just there passively as I run through all my control code to test for goodness, but over the next few days I'd like to get it attached to my computer and taking commands from matlab. This requires a PCI card that I have to find, so it could take some time. There's some question about whether this SLM works, but I'm open to using another DM if I have to, although that would take months to order.
Saturday, May 02, 2009
Subscribe to:
Posts (Atom)
