Showing posts with label control theory. Show all posts
Showing posts with label control theory. Show all posts

Saturday, September 24, 2011

Yeah baby! -> disturbance estimation looking good!

Howdy, ya'll!

It seems like I only blog when I'm back at Ames Research Center, here in the Bay Area.  I had to post something quick 'cause Scott (my cousin) is asleep and I can't tell him right now...  =)  Those of you that know me well, know that I have to get things out of my head and told to someone, partly so that I can stop thinking about it and go to bed, but of course part of it is for your own edificiation.  "Yes," I reply, this does apply to everyone, control theory is general, thus generally applicable.

As a special bonus today, if you read slowly though my monologue and see all the pretty pictures, I will let you see the pictures at the end of some satelite stuff that cousin Scott showed me today.

Right.  Well, here is the state of the union on the helicopter project: I have designed a new, truly high performance controller for the rotor.  This new one uses a more advanced algorithm with an algorithm called receding horizon control or Model Predictive Control (MPC).  Basically, it predicts what the flap will do some steps ahead (15 steps in my case) and then optimizes some "control" commands (5 steps in my case) to make the predicted response as close to what the setpoint reference (my desire) is asking it to do...  In order to do this, it has an internal "sense" of how the model will react to its commands, and then it plans out the next 5 control steps.  When the next control step comes, it does the whole optimization again and plans 5 more control steps ahead. 

When you stop and think about it, this is much like we act every day.  We have a plan of all the wonderful things that we are going to do today and how we will be very efficient with what we want to do.  Then when life actually happens, we have to re-optimize our day as different things come up that make us change our plan.  This controller is just a mathematical version of that.

Example: when you are driving a car, you look forward maybe 50 feet when you are moving slow, right?  you don't plan out what you are going to do and then close your eyes and do it, you watch 50 in front of you, then you drive a little bit and you are still looking 50 feet ahead of you.  This "receding horizon" is the essence of the controller, it optimizes inside a reasonble window of time into the future.


Above is the "natural" response of my system.  This means that when I suddenly tell it to go to the value of 1, this is how it reacts.  My new controller interacts with this natural response and predicts what the system will do, so it can make it settle down quicker.  See below

there are little "steps" in the model output and the command because this is how a computer see the world...  in little steps that are contant between the times that it measure them/changes them.

Anyhow, this new type of controller has the advantage of taking my control bandwidth from something like 15 Hz to now more like 250 Hz.  (not a bad improvement!).  This means that if you ask the little flap to move back and forth 250 times per second, it can and will do what you ask.... fantastic!

The biggest problem at the moment is that while the control bandwdith is great (I only needed to make it to 89 Hz), I still have a low disturbance rejection bandwidth.  disturbance rejection means that when I tell the flap to move to a particular spot and there is something else, external to the assembly that interferes (like aerodynamic forces in my case), how well does the controller deal with that, and at what frequencies will it stop responding.  Up until this point the highest disturbance rejection bandwdith I've been able to achieve was in the 15 Hz neighborhood.  I would really like the controller to be able to get up to 89 Hz disurbance rejection bandwidth to fulfill the purpose that my boss needs it for, so I've been working furiously to try and find a way to accomplish that.

Now, with that context, you can appreciate my accomplishments today (with the Lord's help).  After much research and consideration, I came to the conclusion that much of the problem is seperating what part of the measured position was due to response of the model to my command and what part was due to external disturbances.  This is a tricky thing though, because there is only one position signal that is being measured, so it is combined.  What a wonderful world that we live in that we CAN actually seperate these signals!!  I will not bore you with all the gory math details (unless you ask me of course), but I thought I'd show you some interesting results.  Here is the situation:  I want to control something at 75 Hz.  Meanwhile, some external force is affecting the flap at 120 Hz and then, to really mess things up, gravity is suddenly reduced by 50%, which produces a sudden step in the measured output.  In order to have the flap do as commanded, I have to seperate which parts of what I am measuring come from something that i told it to do (the 75 Hz) and everything else.  Below is a picture of what this would look like.
 So this is the result of my work in the last few days.  The blue is the real thing happening, the red dased line is the system's best guess or estimate about what is going on.  Notice how the guesses are not very good in the beginning but once it locks in, it really a great job!  Now that this portion has been somewhat addressed, I need to figure out what to do with this newly found information in the controller itself (this result is only a small part of the control system; it estimates what is going on that we can't measure directly).  Ideally, the top should be the sum of the bottom two. 

Thanks for hanging with me long enough to get through some cool stuff. 

As promised, here is the super, top-secret satelite pictures that I took when I visited one of the labs that Scott was working in today.  Some of the stuff in this picture is real flight hardware that will be in the final spacecraft.

Monday, July 18, 2011

Objective Successful

I am proud to report that I and the many other people helping me were successful this evening in "closing the loop" of the controller here at Ames.  This means that we can now issue a command to the assembly, say something like, "please oscillate at 35 Hz and at a magnitude of 1 degree."  and it will do so, but you have to say please and ask in a nice voice.  =)

This is a huge step forward for the team in general and for me personally.  This evening marks the first time I have been involved with a closed-loop control project wherein we have gone through the formal experimental and modeling stages and closed-loop control design and had a reasonably high performance controller.  While I didn't get to be involved as much as I would have liked to be in the controller (due to time), I was able to add a modifying controller (an "outer loop") that boosted one of the weaknesses of the inner controller, which was nice to be able to contribute.

One of my mentors, Hossein, and I spent this whole weekend working through the varioius implementation details including safety mechanisms, etc and we finally got the system breathing Sunday evening at about 9pm!  whew!  (the demonstration is taking place at 2pm on Monday...)



This is a funny cartoon kinda showing what closed-loop control is all about, a good reference for those reading this who have no idea what i'm talking about.

Well, I'm gonna hit the hay.  Happy trails partner!

Gavino