ARMAing

The general idea behind an ARMA model is to express the current output as a linear combination of past outputs (the autoregressive part), and current and past inputs (the moving average part). This essentially identifies a transfer function of some order for the system, and since the coefficients appear linearly, the "optimal" values can be found by constructing an appropriate least-squares problem.

I wasn't really interested in coming up with a complete model for the DM dynamics since its time constant is small compared to the sampling time I can get with the WFS. But is it small enough to be negligible when the experiment is running at full speed? The majority of AO papers consider a DM with insignificant dynamics, modeling it instead with a static poke matrix. This was muy bueno with me, except that when trying to identify a poke matrix I basically get garbage unless I insert a pause between applying a DM command and reading the wavefront.

Anyway after much reading, checking, rechecking and cursing I finally wrote a basic ARMA estimation script that organizes all the data into the right places and does the least-squares problem. Basically I gathered some number of DM commands and the resulting WFS measurement, and looked into the coefficients when a pause was included between sending the commands or not. To make things simpler I projected the slope vectors onto the space of actuators. In the ideal case, when the WFS measurements depend only on the current command, the first coefficient should be the identity matrix.

Amazingly, the data was clean enough so that this is actually what happens when I put in a pause before reading the WFS. What's interesting is that without a pause, when the WFS is read immediately after applying the commands, its the second coefficient that's identity, indicating that it takes essentially 1 sample time for the DM to achieve the desired shape. With no pause the sampling frequency was around 20 Hz.

Here's a comparison of the first 5 MA coefficients with a pause (top) and without (bottom. The AR coefficients turned out to be pretty negligible (as you'd expect). Also shown are the norms of the coefficients in each case.



This result seems to verify that the DM does indeed have some time constant, contradicting what everyone says about infinitely fast dynamics. In particular, the 0.05 time constant roughly matches what I found earlier when actuating the DM and capturing WFS frames at a high frame rate.



Incidentally the prediction error on new data is around 15% in either case, and not projecting the slopes into actuator coordinates results in the poke matrix instead of the identity.

The question now is whether or not its worth it to incorporate these dynamics into the controller, or just stick a pause in there and ignore it. Even with the dynamics the model is very simple, just a 1 sample delay with no other significant coefficients, so it shouldn't be hard to do. Of course, I say that now...

4.13.10

On Friday I got back from my first academic "workshop" up in Monterey. To my surprise it was actually informative, both in terms of AO and in witnessing the unique social interactions that take place at these things. My advisor's assertion that some of the people there were "world class pricks" turned out to be a good assessment of character in some cases.

But that's for another day. For all the interesting stuff I heard there, there were only a few thoughts that materially affect my work at the moment. Even though its April, there's more snow in the forecast for the mountains, so this week is bound to be a short one. Here's what I've been focusing on:

Fourier transforms. One presenter at the workshop extolled the benefit of using Fourier modes to do predictive wavefront control. A common theme among the talks was this idea of frozen flow; basically modeling turbulence as a superposition of a finite number of static layers, each moving with an independent velocity. Under this model, decomposing the wavefront using the DFT is beneficial since shifting a Fourier mode with a certain velocity simply involves rotating the (complex valued) modal coefficient some number of degrees. For a given coefficient, each moving layer would impart a certain periodicity related to the layer's velocity. Thus one could identify the layers by looking at the PSD of each mode and looking for spikes corresponding to this periodic behavior....I think.

DM ARX model. I've been meaning to do this for a while, but its only now that I think I know how to compute MIMO ARX models using least-squares. Of course its close to the scalar version, but I wanted to work everything out to make sure. Because I'm anal about verifying every segment of code, its taken some time to get the actual m-file written up. I finished the MA part on Sunday, and just finished the full ARX code a few hours ago. I'll test it all tomorrow.

Return of the SLM. One of the other grad students at this workshop had a working experiment very similar to mine, but using SLM's as disturbance generators. My advisor was intrigued, especially since there seemed to be an easy way to use it in Matlab, and it now looks like we'll be ordering one of these puppies soon. What exactly I'll use it for I don't know, but maybe I can put it to work mitigating the static bias.

Moar Modes

Sure enough, the problem with the poke matrix in this new configuration was caused by the beam size. With the bias voltage the beam was much more compressed than with a general random command. So when the bias wavefront was subtracted from the residual wavefront to get a measurement of the DM phase, it was only modifying the center of the residual.

I fixed this by adjusting the optics to make the beam larger when the bias is applied, something I probably should have done right away. The results look almost perfect, though slightly larger than before






Its possible I could make the modes even smaller by moving stuff around, but at this point I don't want to mess with it any more. I'll settle for Amish perfect.

The Happening

Back from the North, I've spent the last couple days using some new lenses to reduce the beam size. So far so good, and I've been able to reduce the un-molested beam to around 5mm in diameter, half what it was before. With this change almost the entire beam fits into the WFS measurement area I'm using (around 1000x800 px, usually sub-sampled).

Its taken some tinkering, but I've been able to get a recognizable poke matrix out of this configuration.





Notice how nearly the full extent of the modes are in the frame, much closer to the theoretical version. Its not all rainbows and puppies though, as you can see in this comparison between actuator influence functions (for the same actuator) using the small and large beams



Notice the depression surrounding the peak when the smaller beam is used. I would expect the peak to be narrower since the beam is condensed, but this is unexplained. Maybe related to that is the ring that often appears around the modes in the modal poke matrix.

I think this crap shows up because the beam diameter really changes when commands are applied, and the effect is more noticeable when the whole beam is in the WFS frame. Essentially, the problem is the assumption that each WFS sub-aperture measures the same area of the beam, independent of the command. In reality, the beam changes shape with a changed wavefront, so sub-apertures are actually measuring different parts of the beam each time a new command is generated. For small commands, or when the beam is much larger than the measurement area this isn't really a problem, but I think its what's causing the distortions here.

Surely someone must have noticed this before, but as far as I can tell from a 30 second Google scholar search ignorance is bliss, and no one's has the stones to address it. Its a tough problem since I have a suspicion the distortion isn't easy to predict analytically. I'm looking up a few papers on beam shaping based on deformable mirrors, so maybe there's a way to do some kind of pre-warping to the beam as a function of the command, sort of like pre-warping in the bilinear transform. Maybe then the sub-aperture measurements could be linked to a specific part of the beam and used to interpolate a wavefront profile. Maybe its possible to linearize this and make it just a series of simple transformations. Maybe I've had a few too many rusty nails while writing this.

Either way, el hefe thinks this might be a reason we couldn't generate a decent poke matrix from the HEL simulation we have and instead had to rely on a theoretical version. I shall vocalize my pre-warping idea to him tomorrow and report back.

Over and out.

3.11.10

Here's an interesting look at the different sub-aperture sampling resolutions compared to the ideal case using theoretical actuator influence functions



The clear take away from this is that the 9x11 array is essentially crap, and doesn't really provide much performance enhancement over the 18x22 case at the current camera frame rates. Also, it'd be nice to get more of the beam measured since there's clearly some peripheral detail that's missing. I've ordered some new lenses that should help do that...which means more alignment.

In the mean time, I'm still trying to do some kind of system ID using the experiment as a channel, but I'm running into some mysterious Simulink problems that haven't been sorted out yet. I think the idea is solid though; the basic idea is to generate a random command sequence by passing white noise through an FIR filter. The game is to identify the filter coefficients using only the data from the WFS and the original white noise sequence. This is essentially just a basic channel identification process, except the experiment is shoe horned in between. In a perfect world the WFS would be able to perfectly reconstruct the modal commands exiting from the FIR filter, thus identifying the filter coefficients is just a least-squares problem. However in this case the original modal commands are estimated from the WFS data (the estimate is itself a least-squares approximation based on the identified poke matrix). The question is how close will the FIR estimate be given the finite resolution of the WFS? How would changing the WFS resolution affect convergence if a LMS or RLS algorithm is used instead of just a batch process? Does this even make sense?

I was attempting to explain this to my advisor this afternoon but he instead thought I was trying to identify a FIR model for the DM itself, since it looks like there are some dynamics to it after all. This actually might not be a bad experiment to try either. The simplest case would involve identifying a moving average model for the DM, i.e. the current wavefront sequence would be some linear combination of current and past inputs (with a poke matrix stuck in between). If its true that the DM dynamics are negligible, then the MA model should only have order 1. On the other hand it probably doesn't make sense to try to identify a full ARMA model.

Experimentally, the problem with this is the frame rate of the camera. In the past catching the mirror dynamics required frame rates higher than what I'm using right now to read from the WFS, so I might have to use a pretty reduced measurement area to see anything interesting. This might not be a problem though, if I'm apply random commands to the entire mirror surface. I wouldn't even have to use the modes necessarily since I could do a multichannel identification based just on the number of lenslets used.

Anyway, tomorrow I leave for Wyoming on a family vacay, so I'll have 32 hours of driving over the next week to iron these issues out en cerebrum before getting to work in front of the keyboard.

3.9.10

Downsampling the sub-aperture array worked pretty well in reducing the computation time for constructing the slope vector. The image itself is still pretty large, around 900x900 px, but this saves me from having to screw with the beam diameter further. An image of that size allows for roughly a 36x44 lenslet array. Sampling every other sub-aperture essentially doubles the speed; enough such that capturing an image and computing a down sampled, 18x22 dimension slope vector can happen at around 30 Hz, near the 40 fps frame rate of the camera at that resolution/shutter speed. I can get even closer by going to a 9x11 array, but the savings aren't great, and the resulting phase profiles start to look pretty crappy at higher spatial frequencies.

I think this is about as fast as I can expect to go without any (drastic?) changes to the beam size or any additional info on the DM dynamics. The DM presents an interesting problem. I can really only see the dynamics with a very high WFS frame rate (100 fps+), which means a small image with just a few sub-apertures. The trouble is that getting meaningful modal information is hard with so few sub-apertures, so computing an actual frequency response using the modes as control channels would be tough.

I want to move on to some controls applications. One thing I want to try first is to generate random disturbance commands, pass them through a low order FIR filter and apply them to DM61, first with a single modal channel, and the more. Eventually, I'd like to read the resulting open loop WFS data and try to identify the FIR coefficients in some way, either adaptively or using a subspace ID algorithm. This is basically the first step in designing a time-invariant LQG controller, the topic of the first paper I can probably get out. One interesting question in an adaptive situation would be to investigate how the convergence rate is affected by the density of the sub-aperture array. How badly does down sampling screw up the ID? I suspect its significant at higher resolutions.

3.4.10

I talked to my advisor about my concern that I don't have any papers on deck now that my experiment is essentially in place. He didn't seem that worried, so I guess that's all that matters, and assured me that we'd get things going soon enough. He mentioned that the easiest, publishable experiment to work towards would be designing an LQR controller using an identified noise model. However, he's still stressing the idea of running the experiment in real time, so I'm going to have to either make some real advances there, or exhaust all the practical possibilities.

I've managed to get the Simulink version of the PI controller working about as fast as the M-file version. Nominally, sending commands to both actuators each iteration, I can run the thing around 4 Hz. Pretty pathetic, but there are a few things I can work on to speed things up.

WFS: the current sub aperture array size, around 30x45, encapsulates most of the actuator influence functions for the beam size I'm using right now. With partial frame mode, I can capture images of that size at around 45 fps. Since I'm no where near that, and reducing the beam size further would be a pain in the ass, this serves as an upper bound on performance for now. Still, with that many lenslets, computing the slope vector can only be done around 10 Hz. This number of sub apertures is much much higher than what others use, so one idea is to down sample the image and compute centroids for a set of lenslets, like every third or something. I think this would be a linear improvement in the performance of the slope vector calculation.

DMs: the mirrors clearly have some dynamics, so there has to be some pause between sending a command and reading the WFS. When computing a poke matrix, a pause of less than 0.08s yields crappy results, but the PI controller works pretty well when there is no pause at all.

Tomorrow I'd like to look at the down sampling idea since that shows the most promise. There's also the idea of doing the slope calculation in an M-file S-function instead of an EML block. I doubt that'd really improve things much, so its on the back burner for now.

2.22.10

After several realignments and swapping out the mirror, I finally have the larger DM in place. I've been able to generate some pretty hot poke matrices from it; now that I know its working fo sho I've spent the last week or so updating my code and testing it out. Overall it behaves much like the smaller DM, albeit with a greater effect on the beam. I'm not sure exactly why this is, but I suppose it might be due to the larger number of actuators. Because of this I've limited it to voltages in the range [0,180] with a bias at 90V instead of the full 255.

The reconstructed actuator influence functions looked pretty solid, so I constructed a set of modes using those instead of the idealized influence functions we used for the smaller DM. The resulting modal poke matrix looks pretty good for the first 15 or so modes, but basically random after that. I'm not sure if this is due to the commands themselves being strange, or because the mirror can't reproduce high frequency shapes.

Looking at modes again has also dragged up the idea of reducing the beam size to fit in the measurement area. The current number of lenslets, around 1500, is basically an order of magnitude greater than what's found in most AO systems I've heard of, including the high fidelity HEL simulation we use to generate disturbances. The idea is that this is just causing unnecessary computational overhead since the DM's only have 31 or 61 actuators; by reducing the beam size we can utilize the WFS's partial frame mode and achieve higher frame rates (since its a CMOS sensor). This sounds dandy in theory, but in practice I've had a tough time getting a good looking, curricular beam less than around 10mm in diameter, but for the beam to fit in a 5x5 lenslet array would require the diameter to be around 2mm. The trouble is that at that size the beam isn't really circular any more, and the large intensity variations across the cross section make computing centroids from a single WFS image problematic. I don't really know what's causing this, it could be that the relay's I'm using to resize the beam may be crap for that application.

The idea of running the experiment faster is pointless anyway for a couple reasons. First, even with a 5x5 lenslet array, the WFS frame rate would still be much less than the kHz required for real real time experiments, so control would still have to be run on an event driven basis. Second, despite what's been claimed, the DM's need a finite pause between commands for them to reach steady-state. Experience generating poke matrices has shown that a pause of less than 0.08s or so between random commands results in garbage, so this is essentially the upper limit of the experiment unless there are some hardware changes...and I've had enough of those.

I'll continue looking into this a little more, but actually modeling the actuator dynamics is probably beyond what I want to do, since it would require obtaining a frequency response for each DM mode.

With the disturbance DM working, its time to move on and consider what my next move is. This week I'd like to finish modifying my simulink files to apply disturbance commands to DM61. Also, I'd like to review some of my basic adaptive filter/predictor stuff, and maybe have a nice simulink example I can "easily" port over to the experiment to play around with.

For tomorrow:
- Compare mirror step responses for DM61 and DM31 using random and single actuator commands
- Try to figure out what the extra B' is for in the eigenvalue problem for generating modes.
- Review linear predictor stuff. Start building a simple Matlab/Simulink example

2.11.10

I was able to construct some modes for DM31 (the 31 actuator DM) using influence functions reconstructed from the poke matrix instead of the theoretical, simulated versions. When applied, both sets actually look pretty similar until the 10th mode or so, after which the experimental modes start to look like crap. I think part of the problem is that the WFS only samples the interior 80% or so of the beam, so several actuators peak on the edge or just outside of the frame. Since the experimental influence functions are actually pretty similar to the simulated versions (amazingly, even the amplitudes are within an order of magnitude!), I suspect that resizing the beam such that all the actuators are fully measured would help this out a little. Something to play with next week.

In the mean time, it'd still be interesting to construct modes for DM61 using its poke matrix. I found out yesterday that most of the actuators respond linearly to the square of the voltage command just like with D31, but there are 3 that don't seem to be moving at all, or or moving strangely. Tomorrow the plan is to swap out the mirror that's installed now with the spare to see if that solves the problem, and then take a look at the modes using that mirror's poke matrix.

I'm pretty clear on how to construct the modes now given a set of influence functions. Basically it just involves some clunky linear algebra. Maybe I'll write up a little short story about them one day.

Back in Business

Apparently the D/A buffers in the driver box get corrupted every time I restart, but they can be cleared by a special command. Of course, why didn't I think of that?

Premature

This all was only wishful thinkin,
this all was only wishful thinkin


Unbelievably, the DM that was working a few hours ago is broken again after restarting my computer. Maybe something happened to the hardware overnight. Maybe our lab was subverted by Chinese hackers. Maybe it was all a dream and I was just hallucinating about it working from the pain meds I took for my knee.

Maybe my experiment's become self-aware and is trying to prevent me from making a discovery that will eventually lead to the extinction of the human race. It is, after all, almost as if the piece of crap was consciously trying to screw me up at every turn. Here's a rough timeline of the last few weeks:

- DM arrives. The cables for connecting the driver to PC are 1 ft long. Order longer cables.

- Longer cables arrive. Install DAC card drivers and search fruitlessly for further instructions. Email for help.

- Help arrives in the form of a software update from DM manufacturer. Software update proceeds to not work and crash. Email again for code that will work in Matlab.

- Example Matlab code arrives. Cryptic and mysterious, it uses syntax and a programming interface I'm unfamiliar with. Running it invokes errors and crashes Matlab. Email for help with suspected code.

- Correct faulty Matlab code and run it to discover...more errors. By now I can fix the "example" code myself.

- Matlab code runs without error. It works successfully with old DM, but new DM refuses to move. Email for help.

- Update DAC card drivers to latest version. Unplug and replug cables.

- SUCCESS! Compose witty and congratulatory blog post. Drink heavily in celebration of completed experimental setup.

- Restart computer. DM again refuses to move despite no software or hardware changes. Email for help.

- Cry. Put on Taking Back Sunday and compose defeated and bitter blog post.

And that is where we stand to this day, only a mere half quarter after we started. Fuck it, I'm taking a vacation.

Now witness the power of this fully armed and operational battle station!

My experiment is complete. Today I finally, finally gotten my second DM working from Matlab after more than a few emails, wasted afternoons and computer restarts; thus all the major components are there and functioning. Here's a picture of an experiment in progress:



There are still a few idiosyncrasies to work out, but the basics of sending commands to both mirrors simultaneously seem to be working. Here's a comparison of the effect of random command vectors applied to either mirror or both simultaneousy



Clearly this new mirror doesn't quite have the range of the 31 actuator model for whatever reason, however for generating disturbances it should get the job done.

This week the focus will be on characterizing the new mirror and rewriting my code to interface with it. The first step is to generate a poke matrix; early attempts at calculating one from random commands today weren't that successful for some reason, although poking each actuator individually seemed ok. I think a good plan for tomorrow would be to

1. Try loading the straight 61 actuator configuration file. Does poking each channel give the appropriate response?

2. Realignment. Are all the actuators covered by the beam? Should the beam be resized or altered in some way? Try to eliminate tilt as much possible before proceeding.

3. Assuming all the channels are behaving as planned, try again to generate a poke matrix using random commands.

Once I can generate this mapping reliably, I can go ahead and look at things like linearity and actuator decay. Then, I can use the experimental actuator influence functions to generate DM modes.

I'm Doing Science!

Turns out expecting to produce a poke matrix by last Friday was a tad optimistic. After all, why should I expect my $15000 mirror to work out of the box or come with directions? What am I, some naive undergrad researcher?!

Most of of the problems stemmed from the example code I was sent, which contained several errors based on the "version" of the software I was using. Some of those I fixed myself, which I guess is good in retrospect since it forced me to get to know a few of the intimate joys of .NET. I'm sure this will be useful when some piece of code decides to shit the bed later.

In any case, I finally have some code written that I can use to command the USB, 31 actuator mirror using this new interface. Putting me functionally in the same place I was months ago. For some reason I still can't see the new DM from either the bundled software of Matlab, so that will take some further tinkering and emailing. It would be optimistic to plan on having this fixed by next week.

Nonetheless, tomorrow the plan is to get use to this new code and verify its producing the same results as before. Since we have 2 of the new 61 actuator DMs, I should be able to swap the hardware around to pinpoint the problem. I suspect its just some stupid software parameter somewhere that has to be checked, but its probably going to take an email to the manufacturer to figure out.

Sugar Momma

Like every good grad student I'm always looking for ways to get more money. One way of approaching that is to look at the current buzzwords that are flying out of research journals, and finding ways to use your own research in those areas.

Networked control systems seem to be a popular research topic in the control engineering world these days, and one of the major headaches there seems to be the uncertain time delay that results from unreliable data networks. I haven't read enough to know how this is dealt with in practice, but I would guess some kind of ZOH handwaving is used to duct tape the problem.

The AO problem deals with time delays explicitly by predicting future outputs. This is possible since wavefronts exhibit some correlation so we can usually do better than pure guessing on average. Adaptive controllers work even better because the nature of the correlation is uncertain or changes over time.

NCS problems also have time delays, but the problem is exacerbated because the delay itself is unknown. On the other hand, would it be outrageous to assume that the delays might be correlated? If that's true, could you design an adaptive controller/observer that provided an estimate that performed better than ZOH?

In other words, could you consider random delays as simply changes to the PSD of the measured signal? If so, then an adaptive controller might have some promise.

Hmm, this could all be nonsense on second thought.

Vacay's Over

Its been a relaxing month of unmitigated laziness since I passed my Quals. In that time I've managed to do less than I ever thought possible, other than ski and eat.

The presentation itself, rushed into production like a Soviet washing machine, went over well. Taking a hint from all the seminars I've slept through, I tried to avoid putting in too much text that would be ignored and instead focused on graphics and charts that I could explain. In my experience, this approach is what usually separated a presentation given by a grizzled transparency veteran, new to powerpoint but not to verbose explanation, and a recently minted academic who still possessed the new PhD smell.

Scheduling it during finals week turned out to be a blessing. Since most of my committee had limited time to spare between giving exams and review sessions to the little ones, I only had an hour or so to talk. A mere 40 minutes remained by the time everyone arrived and I finally opened my mouth, but this limit meant that I could avoid any really technical questions.

Anyway, with a supposedly clear path ahead, the next step is to install and test out the new 61 actuator DM we received. I actually came in a few days over the break to do some alignment, despite the department's attempt to prevent this by turning off the lights and stopping garbage collection. This week the focus will be on commanding the mirror itself. This new mirror only has twice the actuators, but apparently sending it commands is ten times as difficult. Rather than a simple USB driver box, signals to this mirror travel through an NI DAQ card before hitting some other voltage amplifier that actually connects to the actuators. To use this system with Matlab I'll have to upgrade to 2009A, and use the .NET interface to access the DM driver's DLL library. Hooray.

A rough, optimistic schedule of events:

Tues: Finish installing cables, test mirror functionality using V. 1.8 software, begin dissecting AOS .NET example code

Wed: Upgrade Matlab if possible, continue code dissection

Thurs: Adapt code into Matlab DM control function

Fri: create 61 actuator poke matrix

Demo

In anticipation of my Qualifying Exam in 2 days, I've created a working demo of my experiment

All work and no play makes jack a dull boy

Spend too much time doing technical writing, and pretty soon you start thinking in proposal-eese.

The girl over there is pretty hot [5]. However, two prominent features preclude her from attaining optimal attractiveness: her diminutive height, and her apparent predilection for undesirable Australian footwear. The former of these is alleviated by her sitting position. The latter, however, is a consequence of cultural differences and cannot be mitigated directly [14].

A Question

Q: So what do you plan on doing after you graduate?

A: Enjoy not answering stupid questions about what I plan to do.

...can't wait for all the family gatherings coming up.

An Update

I finally charmed enough professors into being on my Ph.D committee. The motley crew consists of 3 controls people from MAE and one optimization prof from EE. I deliberately avoided having anyone with too much background in optics to avoid any potentially embarrassing questions, and I really want to emphasize that this is more a controls project than an optics one.

Since it looks like I'll actually be able to do my Quals this quarter, experiments have basically been nonexistent while I work on my prospectus. I'm trying go heavy on the detail to make things easier when its time to write the big boy, and right now I anticipate it'll clock in around 40-5o pages. Bigger than the average prospectus maybe, but I have been plugging away at this for some time after all. Its actually nice to review over everything at one time and see how much I've done...and how much I still have to do.

Graduation in 2010? Maybe not so far fetched after all.

Dear Diary,

I spent most of today talking with my advisor about the ability of the DM to reproduce the actuator modes. He seems suddenly interested in this even though identifying a modal poke matrix is something I've been doing for months. At least he admits his obsession with modes is "a sickness."

Yesterday there was some concern that, even though there are only 31 actuators and hence 31 degrees of freedom, somehow more than 31 modes were being produced through some nonlinearity. We looked at this problem by applying a few hundred random commands and computing Karhunen-Loeve modes for the resulting phases and/or slope data. It was hard to tell from the eigenvalues of those modes what exactly was going on, but it looked like there were far fewer than 31 principle components that had a significant contribution to the phases. Even though there were nonzero values past the 31st largest eigenvalue, there is definitely some funny business going on with the rounding, pixel error, and other nonlinear noise affects that could be contributing.

On the control front I'm trying to learn as much as I can about Youla parameterization. Of course, my idea of combining this with adaptive filtering algorithms is about 10 years too late. Still, its a relatively unused technique and there's still some potential for exploration there. Even if I don't end up rewriting the adaptive controller code our lab is currently using, I think its important to know what's going on under the hood.

We've been experiencing all four season in one week here. I need cold weather.