| View previous topic :: View next topic |
| Author |
Message |
kubark42
Joined: 17 Nov 2008
Posts: 11
|
 Posted: Mon Nov 17, 2008 11:37 am Post subject: Kalman filter, LQR controller, and System Identification |
 |
|
Hi--
I'm a controls researcher at the University of Luxembourg. For my ball and plate project (anti-anti-spam, because the anti-spam won't let me post it normally: http://www.eissq.com/BandP.html ), I need to develop a new system for controlling servo velocity. I was going to do it myself, but figured it was an easy enough project that I would have some masters students at the University of Burgundy do it. (My needs are not extraordinarily high.)
I had given them a linear actuator w/potentiometer, a Syren 25 four-quadrant motor controller, and an Arduino Decimilia. However, I then chanced across your project and realized that you've pretty much done everything I could want. Sure, there are a couple things that would need changing (I communicate using RS232 instead of I2C/TWI, for instance), but instead of taking a week, this wouldn't even take half a day. So now I've got a little bit of a dilemma, because you've stolen my thunder.
I've decided instead to ask them to improve upon your project. Specifically, I would like to have three things: a Kalman Filter observer, either extended, or linearised about multiple points, with parameters stored in EEPROM; an LQR controller with integrator (better than a PID); and a reasonable system identification algorithm for determining things such as motor inertia, resistance, etc.
Before going too far, though, I'd like to hear from you guys about where you are. As I understand, this is currently a SIMO system, measuring position and current, right?
So, I didn't notice anywhere in the code a position filter of any kind. Perhaps I've been blind. I've seen a couple of posts related to Kalman filters, but there hasn't been any recent activity, though. Likewise for system identification-- where a while back ARMAX was mentioned-- and LQR control.
As it stands today, system identification might be tough to pull off on a Atmega168 due to limited SRAM, but depending on how much flash is used, it should be relatively easy to design a PBRS (pseudo-binary random sequence) that gathers data and sends it over the communication bus (I2C or serial, as the case may be) to offline processing. I guess this would be a special mode that could be accessed by a proper command or shorted pin on start-up.
I'm a little more confident on being able to design a good LQR and Kalman Filter. While the system is non-linear, there's nothing that stops us from linearizing it about multiple points. The only limitation would be memory space, but since a Kalman matrix for a system of n states and p outputs has n*p elements, it should be easy to discretize about tens, if not hundreds of points.
For the LQR controller, a system of n states and m inputs, gives m*n elements, so it, too, can be linearized about many, many points.
So how are things today? The project seems pretty alive, but with enough space left over for people like us to get on board.
Cheers,
Kenn Sebesta
[edit] Sanitized links.[/edit]
Last edited by kubark42 on Tue Nov 25, 2008 2:57 pm; edited 1 time in total |
|
| Back to top |
|
 |
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Mon Nov 17, 2008 3:48 pm Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
Hi Kubark42
Thanks for dropping by, We always appreciate feedback and help!
| kubark42 wrote: |
... Sure, there are a couple things that would need changing (I communicate using RS232 instead of I2C/TWI, for instance), but instead of taking a week, this wouldn't even take half a day. So now I've got a little bit of a dilemma, because you've stolen my thunder. |
Ahh, the power of open source
| Quote: | I've decided instead to ask them to improve upon your project. Specifically, I would like to have three things: a Kalman Filter observer, either extended, or linearised about multiple points, with parameters stored in EEPROM; an LQR controller with integrator (better than a PID); and a reasonable system identification algorithm for determining things such as motor inertia, resistance, etc.
|
Awesome! We would love for you to extend OpenServo however you want. Passing back improvements is always welcome.
| Quote: |
Before going too far, though, I'd like to hear from you guys about where you are. As I understand, this is currently a SIMO system, measuring position and current, right?
|
Yes, that is correct. In the new v3-dev code we also measure motor velocity via Back EMF voltage measurement istead of differential position measurements.
| Quote: | So, I didn't notice anywhere in the code a position filter of any kind. Perhaps I've been blind.
|
We actually use only a simple lowpass digital filter based on the algorithms described here (http://www.edn.com/article/CA6335310.html)
You can see this in action at the top of pid.c (filter_update)
While works very well for a small servo motor, a better filter would be welcome for moving larger servos, where the noise becomes obvious.
| Quote: | | I've seen a couple of posts related to Kalman filters, but there hasn't been any recent activity, though. Likewise for system identification-- where a while back ARMAX was mentioned-- and LQR control. |
Kalman filters was discussed at length, but after a small amount of analysis, it was decided that (for now) a simple filter was enough. As I mentioned above, we use a simple digital filter that works well enough.
I had a look at implementing LQR control a year or so back. I have some basic code that implements only a basic LQR controller. I found that it was a nightmare to balance all of the gains, and the improvements gained were nominal.
I would love to see someone implement more advanced control algorithms, especially as I have only a small grounding in this field.
| Quote: | As it stands today, system identification might be tough to pull off on a Atmega168 due to limited SRAM, but depending on how much flash is used, it should be relatively easy to design a PBRS (pseudo-binary random sequence) that gathers data and sends it over the communication bus (I2C or serial, as the case may be) to offline processing. I guess this would be a special mode that could be accessed by a proper command or shorted pin on start-up.
|
That sounds interesting. Offloading some of the control work is a good idea, and one that we thought about for a while. At the time we were working with an atmega8 and we had tight limitations. Now we are on the 168, it may be possible.
You could also disable some features that eat all of the flash memory, especially motion profiles.
| Quote: | I'm a little more confident on being able to design a good LQR and Kalman Filter. While the system is non-linear, there's nothing that stops us from linearizing it about multiple points. The only limitation would be memory space, but since a Kalman matrix for a system of n states and p outputs has n*p elements, it should be easy to discretize about tens, if not hundreds of points.
|
We should have enough space for that. At the moment the EEPROM is barely used, and could be used to store points.
| Quote: | | So how are things today? The project seems pretty alive, but with enough space left over for people like us to get on board. |
We are very much alive and kicking. We are at the stage where we have a good set of features, some more advanced than others (cubic motion profiling etc).
For the moment we are concentrating on building GUIs, APIs, documentation and examples, as this is the part people have trouble getting a grasp with.
We are always looking to get help from experts, and occasionally we get some gurus like yourself dropping by and doing some great work for us. We welcome this with open arms. If you want a CVS repository or anything to help you along, let us know and we will do anything we can to help.
Cheers,
Barry
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Mon Nov 17, 2008 4:44 pm Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
| ginge wrote: | | kubark42 wrote: |
... Sure, there are a couple things that would need changing (I communicate using RS232 instead of I2C/TWI, for instance), but instead of taking a week, this wouldn't even take half a day. So now I've got a little bit of a dilemma, because you've stolen my thunder. |
Ahh, the power of open source
|
In case this wasn't clear, I meant 1 week to get done with the bare necessities of where I needed things, not to recreate your project! That, I imagine, has taken you many more weeks than that. 
| ginge wrote: | | Quote: |
Before going too far, though, I'd like to hear from you guys about where you are. As I understand, this is currently a SIMO system, measuring position and current, right?
|
Yes, that is correct. In the new v3-dev code we also measure motor velocity via Back EMF voltage measurement istead of differential position measurements.
|
Can you explain (or link to an explanation) of how your SIMO system works? I can see two possibilities:
1) You control for position and have state-space constraints on the velocity and current.
2) You control for speed along a certain spatial trajectory (discretized or not) and then have the servo stop at an arbitrary position. (This kind of system leads itself to geometric control, which is sort of the ultimate in non-linear control, but it's very complicated and very specific to a given model.)
I just want it to be clear in my mind so I set off in the same direction as you.
| ginge wrote: | | Quote: | So, I didn't notice anywhere in the code a position filter of any kind. Perhaps I've been blind.
|
We actually use only a simple lowpass digital filter based on the algorithms described here (www . edn . com / article / CA6335310.html)
You can see this in action at the top of pid.c (filter_update)
While works very well for a small servo motor, a better filter would be welcome for moving larger servos, where the noise becomes obvious.
|
Ah. I hadn't seen that there. In main.c, I'd noticed the variable "position", but it seemed to me you were getting it directly from the ADC and passing it right to the PID. I admit to not having looked in the PID code as I simply assumed it would do nothing more than calculate a PID.
I might suggest a future move to include a "filter.c" file so as to separate the PID (which is a question of control and controlability) from the filter/observer (which is a question of observation and observability).
| ginge wrote: | | Quote: | | I've seen a couple of posts related to Kalman filters, but there hasn't been any recent activity, though. Likewise for system identification-- where a while back ARMAX was mentioned-- and LQR control. |
Kalman filters was discussed at length, but after a small amount of analysis, it was decided that (for now) a simple filter was enough. As I mentioned above, we use a simple digital filter that works well enough.
|
I've seen references to Least Squares with Forgetting Factor, which is just a specific variant of an EKF, surprisingly enough. If you're getting good results with that, you can usually do better with Kalman. However, we're butting up against the difference between engineers and mathematicians: the one is "theoretically" correct, and the other works well enough for the needs. I'm an engineer, but these students are theoreticians, so I completely understand your reasoning, but we'll still try to do better. <grin>
I think you'll find that if we can succeed in making a simple system ident. that the Kalman filter will give universally better results, especially for some kind of non-linear control. With a better observation of the system state, you can have faster and stronger controls. Now whether this is desirable for a CNC milling application, I strongly doubt, as you're pretty much limited by the cutting speed, not the controller.
| ginge wrote: | I had a look at implementing LQR control a year or so back. I have some basic code that implements only a basic LQR controller. I found that it was a nightmare to balance all of the gains, and the improvements gained were nominal.
I would love to see someone implement more advanced control algorithms, especially as I have only a small grounding in this field.
|
Interesting. I've always used LQR and never really had a problem with it. It's true that getting the right weights can be a little more delicate, as you need some model knowledge, but it's far more adaptable.
When you talk about the gains, are you referring to the Q and R matrices? I can give a short explanation of how to choose the weights, if you like.
| ginge wrote: | | Quote: | I'm a little more confident on being able to design a good LQR and Kalman Filter. While the system is non-linear, there's nothing that stops us from linearizing it about multiple points. The only limitation would be memory space, but since a Kalman matrix for a system of n states and p outputs has n*p elements, it should be easy to discretize about tens, if not hundreds of points.
|
We should have enough space for that. At the moment the EEPROM is barely used, and could be used to store points.
|
I gave a shot at compiling the code. With v3 (not v3_dev) you're at 51%, which means 8k left over for parameters stored in PROGMEM. Since you have three states, one input, and two outputs, that's ~8000/9 ~= 900 linearization points using 8-bit parameters.
With 10-bit ADC resolution, there's really no point in going past 1024 points, so that's approaching just about the best you can theoretically do. And of course, by choosing a saner 100 discretization points and moving to 16-bit integers, you can have lots of space left over for other code.
| ginge wrote: | | Quote: | | So how are things today? The project seems pretty alive, but with enough space left over for people like us to get on board. |
We are very much alive and kicking. We are at the stage where we have a good set of features, some more advanced than others (cubic motion profiling etc).
For the moment we are concentrating on building GUIs, APIs, documentation and examples, as this is the part people have trouble getting a grasp with.
|
GUI, eh? What kind are you thinking of? Something that graphically allows a user to plot a servo state trajectory? Sounds cool. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Mon Nov 17, 2008 6:08 pm Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
| Quote: |
| ginge wrote: |
Ahh, the power of open source
|
In case this wasn't clear, I meant 1 week to get done with the bare necessities of where I needed things, not to recreate your project! That, I imagine, has taken you many more weeks than that.
|
I guess I wasn't clear. I merely meant that the power of open source has saved you the trouble of reinventing the wheel.
| Quote: | Can you explain (or link to an explanation) of how your SIMO system works? I can see two possibilities:
1) You control for position and have state-space constraints on the velocity and current.
2) You control for speed along a certain spatial trajectory (discretized or not) and then have the servo stop at an arbitrary position. (This kind of system leads itself to geometric control, which is sort of the ultimate in non-linear control, but it's very complicated and very specific to a given model.)
|
We control for position at the moment, but factor in speed too. We use a simple differential PD controller where P is the difference in position since the last tick, and D is based on velocity.
P = (seek position - previous position) * gain
D = (seek velocity - current velocity) * gain
in D we default to seek velocity of 0 (unless otherwise set)
| Quote: | | I might suggest a future move to include a "filter.c" file so as to separate the PID (which is a question of control and controlability) from the filter/observer (which is a question of observation and observability). |
Good idea. It is only used by the PD algorithm at the moment, but we may reintroduce the IPD algos, which would benefit from filtering.
| Quote: | However, we're butting up against the difference between engineers and mathematicians: the one is "theoretically" correct, and the other works well enough for the needs. I'm an engineer, but these students are theoreticians, so I completely understand your reasoning, but we'll still try to do better. <grin>
|
Heh As you can appreciate, we often have to balance advanced features for end user simplicity. Most people expect a servo motor to be tuned with the servo specific parameters, or at the very least have a simple way to tune a servo quickly. More features == more parameters, unless you can prove otherwise
| Quote: |
| ginge wrote: | I have only a small grounding in this field.
|
Interesting. I've always used LQR and never really had a problem with it. It's true that getting the right weights can be a little more delicate, as you need some model knowledge, but it's far more adaptable.
When you talk about the gains, are you referring to the Q and R matrices? I can give a short explanation of how to choose the weights, if you like.
|
Yes, that sounds familiar. I havn't looked at this for a while, but any pointers are good Especially if it means I get to learn some more about how real motion control works!
| Quote: | I gave a shot at compiling the code. With v3 (not v3_dev) you're at 51%, which means 8k left over for parameters stored in PROGMEM. Since you have three states, one input, and two outputs, that's ~8000/9 ~= 900 linearization points using 8-bit parameters.
|
Excellent. Remember we use 2k for the bootloader, though.
| Quote: | | GUI, eh? What kind are you thinking of? Something that graphically allows a user to plot a servo state trajectory? Sounds cool. |
Pretty much the whole package. Basic toolbox for simple control, a full motion profile wave editor, a 3d preview of your model, and as you said, a trajectory generator.
Given that we can get a lot of information out of the servo, we can also build a state space controller for a simulation of the servo, and extrapolate much more interesting information.
The aim is to have a nice simple pluggable gui to allow for complex motion control.
My first application for it will be a simple AI walking robot. I will use the gui to build the algorithms, and then compile them down into a embedded machine. Or so the plan goes.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Mon Nov 17, 2008 7:01 pm Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
| ginge wrote: | We control for position at the moment, but factor in speed too. We use a simple differential PD controller where P is the difference in position since the last tick, and D is based on velocity.
P = (seek position - previous position) * gain
D = (seek velocity - current velocity) * gain
in D we default to seek velocity of 0 (unless otherwise set)
|
I see. You're just using an error term in the PD, and choosing an equilibrium set point amongst all the infinite stable equilibria. Makes sense, and seems like a good choice.
Why don't you use an integrator, though? If it were sufficiently weak, it ought to remove any "DC" bias, without reacting too strongly to the "AC" bias.
| ginge wrote: | | Quote: | However, we're butting up against the difference between engineers and mathematicians: the one is "theoretically" correct, and the other works well enough for the needs. I'm an engineer, but these students are theoreticians, so I completely understand your reasoning, but we'll still try to do better. <grin>
|
Heh As you can appreciate, we often have to balance advanced features for end user simplicity. Most people expect a servo motor to be tuned with the servo specific parameters, or at the very least have a simple way to tune a servo quickly. More features == more parameters, unless you can prove otherwise
|
I did once, but on my way to Detroit in my water-powered, 250mpg flying car, I was simultaneously assassinated by the CIA, shot down by Lockheed, incinerated by Exxon, and squashed by MAC Truck. It's hard being a maverick, maverickin' around, like mavericks do.
| Quote: | When you talk about the gains, are you referring to the Q and R matrices? I can give a short explanation of how to choose the weights, if you like.
|
| ginge wrote: | Yes, that sounds familiar. I havn't looked at this for a while, but any pointers are good Especially if it means I get to learn some more about how real motion control works!
|
You can read all about it here. Pg. 1 is an excellent overview as to what it does. Section 2.2 is also quite informative. Careful, he's giving it for the continuous time state, so you can't directly apply the eqns. http://www.ece.ucsb.edu/~hespanha/ece147c/web/lqrlqgnotes.pdf
The discrete-time algorithm implemented in my code is here. You'll find it pg. 6, Corollary 3.5: http://streaming.ictp.trieste.it/preprints/P/99/097.pdf
If you aren't already familiar with how to transform a continuous time matrix into a discrete time, let me know, as A and B must be in discrete form. (Q and R have no impact).
Remember that this Q and R have nothing to do with the Kalman Q and R, except that they have similar form. You get really weird results when you mix the two up. As I know from personal experience...
| ginge wrote: |
| Quote: | I gave a shot at compiling the code. With v3 (not v3_dev) you're at 51%, which means 8k left over for parameters stored in PROGMEM. Since you have three states, one input, and two outputs, that's ~8000/9 ~= 900 linearization points using 8-bit parameters.
|
Excellent. Remember we use 2k for the bootloader, though.
|
Well, that could put a bit of a crimp on things, but even an overly generous 100 discretization steps would only take 1800 bytes using 16-bit integer parameters.
| ginge wrote: | | Quote: | | GUI, eh? What kind are you thinking of? Something that graphically allows a user to plot a servo state trajectory? Sounds cool. |
Pretty much the whole package. Basic toolbox for simple control, a full motion profile wave editor, a 3d preview of your model, and as you said, a trajectory generator. |
Ulp. Count me out for this. Unless GUIs rejected from the 70s for being overly colorful and flamboyant are your idea of "good" design.
[edit]Sanitized links[/edit]
Last edited by kubark42 on Tue Nov 25, 2008 2:59 pm; edited 1 time in total |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Mon Nov 17, 2008 7:43 pm Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
| Quote: | Why don't you use an integrator, though? If it were sufficiently weak, it ought to remove any "DC" bias, without reacting too strongly to the "AC" bias.
|
Again it comes down to end user simplicity. The iterator was causing a lot of problems, and we found that removing it was a good balance between user friendliness and control over the motor.
| Quote: |
| ginge wrote: | unless you can prove otherwise
|
I did once, but on my way to Detroit in my water-powered, 250mpg flying car, I was simultaneously assassinated by the CIA, shot down by Lockheed, incinerated by Exxon, and squashed by MAC Truck. It's hard being a maverick, maverickin' around, like mavericks do.
|
heh. Sarcasm aside, I was hoping for a slightly different answer. What I was trying to get at was this; Is there an algorithm which has a fairly easy to calculate parameters and isn't too hard for an end user.
Apologies if you misunderstood.
| Quote: |
| ginge wrote: |
Excellent. Remember we use 2k for the bootloader, though.
|
Well, that could put a bit of a crimp on things, but even an overly generous 100 discretization steps would only take 1800 bytes using 16-bit integer parameters.
|
I'm sure something can be worked out.
| Quote: |
| ginge wrote: | | Quote: | | GUI, eh? What kind are you thinking of? Something that graphically allows a user to plot a servo state trajectory? Sounds cool. |
Pretty much the whole package. Basic toolbox for simple control, a full motion profile wave editor, a 3d preview of your model, and as you said, a trajectory generator. |
Ulp. Count me out for this. Unless GUIs rejected from the 70s for being overly colorful and flamboyant are your idea of "good" design. |
erm. hmm. well... I will try not to take offense, given you have a 1 liner explanation of what is going on.
What would you propose?
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Tue Nov 18, 2008 10:18 am Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
| ginge wrote: | The iterator was causing a lot of problems, and we found that removing it was a good balance between user friendliness and control over the motor.
|
Ah, I see. Did the users find it too confusing to find a good gain, or was the wind-up and other related gotchas getting to be too complicated? Just something for us to think about because we can include an integrator in the LQR control (it requires adding a virtual state). One thought would be to include an integrator, but set the default gain to 0 and "hide" it along with strict instructions not to turn it on unless the user is familiar with all the associated problems.
| ginge wrote: | | heh. Sarcasm aside, I was hoping for a slightly different answer. What I was trying to get at was this; Is there an algorithm which has a fairly easy to calculate parameters and isn't too hard for an end user. |
Sorry, way over here we kind of missed out on most of the election stuff-- for better and for worse-- but I thought that SNL skit was hilarious. It's the first time I've watched SNL and laughed in, gosh, I don't remember how long. But I digress...
For choosing parameters, the nice thing about a PID is that it's so easy to understand what's going on. You have three parameters, and more means, well, more. If you increase the P gain by two, you get twice as much gain. Contrast this to LQR where you're solving an optimum control, so the weights in the Q and R matrix don't have the same effect at all. The weights are used to calculate the importance of the two vectors we're trying to minimize: state and control. So more of one weight means less of the other. Plus, the LQR control matrix doesn't look intrinsically like anything.
If you look at the first pdf I "linked" (danged anti-spam filter is driving me crazy), on pg. 11 you'll find Bryson's rule, which is a pretty good rule of thumb for starting out. However, as indicated toward the end of the section, it often is just a starting point for trial-and-error tuning.
The advantage of all this LQR stuff is that it's very easy to understand the design goals. If you will, the Q matrix gives the importance of minimizing the state error, and the R matrix the importance of minimizing the control. What's great about LQR is that you get to prioritize some variables over others. So supposing that you had a 4 dimensional state-- x, y, v_x, v_y, and you wanted to track a line along the y-axis with a given speed without deviating too far from the line. In this case, you could heavily weight x, so as not to deviate from the line, and v_y, so as to maintain speed.
This is something you really can't do with a normal PID. I suppose, in a way, you could by weighting the error, that is to say you apply a gain to errors along a specific dimension, but that's not something I'm familiar with so I would tend to shy away from it out of concern that the system would have unpredictable behavior.
| Quote: | | Quote: |
Ulp. Count me out for this. Unless GUIs rejected from the 70s for being overly colorful and flamboyant are your idea of "good" design. |
erm. hmm. well... I will try not to take offense, given you have a 1 liner explanation of what is going on.
What would you propose? |
Maybe I should take a little more time in my answers. I mean that my GUI designs to date have been, how to say, "compatible" with 16 color monitors and would look fine running on Windows 1.0. I'm one of those engineers/scientists that you don't want to let anywhere near a clothing store, and whose idea of painting is knocking a bucket of paint down the stairs and then trying to clean up the aftermath. |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Tue Nov 18, 2008 12:27 pm Post subject: Re: Kalman filter, LQR controller, and System Identification |
|
|
| kubark42 wrote: | | Quote: | Ah, I see. Did the users find it too confusing to find a good gain, or was the wind-up and other related gotchas getting to be too complicated?
|
Wind up was ok, we just had a limiter... and a direction change reset, and .... damn now I remember this stuff being a pain in the backside.
...
...
... |
Whoops! 
I think phpBB took a bark somewhere. Your post is listed as being my post, and my post was gone! I put mine back in, but you might cut/paste your post that somehow got attributed to me. And then maybe this post, too, since it only makes sense as long as the rest doesn't. |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Tue Nov 18, 2008 12:41 pm Post subject: |
|
|
| Quote: | Ah, I see. Did the users find it too confusing to find a good gain, or was the wind-up and other related gotchas getting to be too complicated?
|
Wind up was ok, we just had a limiter... and a direction change reset, and .... damn now I remember this stuff being a pain in the backside.
| Quote: | Just something for us to think about because we can include an integrator in the LQR control (it requires adding a virtual state). One thought would be to include an integrator, but set the default gain to 0 and "hide" it along with strict instructions not to turn it on unless the user is familiar with all the associated problems.
|
Up until version 1.8 we had the Iterator in place. We got tired of people enabling it and trying to balance it, so we just took it out.
There is no real reason why it couldn't go back in.
| Quote: |
Sorry, way over here we kind of missed out on most of the election stuff-- for better and for worse-- but I thought that SNL skit was hilarious. It's the first time I've watched SNL and laughed in, gosh, I don't remember how long. But I digress...
|
Ahh that explains it. I'm European so it was lost on me (but I am tempted to look it up on one of those fandangled video sharing thingys)
| Quote: | If you look at the first pdf I "linked" (danged anti-spam filter is driving me crazy),
|
You should be past the spam filter now, it is time and post limited.
I will go back and edit your first post to sanitise the link.
| Quote: |
The advantage of all this LQR stuff is that it's very easy to understand the design goals. If you will, the Q matrix gives the importance of minimizing the state error, and the R matrix the importance of minimizing the control. What's great about LQR is that you get to prioritize some variables over others. So supposing that you had a 4 dimensional state-- x, y, v_x, v_y, and you wanted to track a line along the y-axis with a given speed without deviating too far from the line. In this case, you could heavily weight x, so as not to deviate from the line, and v_y, so as to maintain speed.
|
Sounds great. assuming you can balance those weights to good effect.
| Quote: |
This is something you really can't do with a normal PID. I suppose, in a way, you could by weighting the error, that is to say you apply a gain to errors along a specific dimension,
|
Indeed. I tried something similar to this to allow more rigidity in the system when choosing motion mode. It oscillated, uncontrollably, and then exploded. It was a nice way of making a non-linear system much worse.
| Quote: |
Maybe I should take a little more time in my answers. I mean that my GUI designs to date have been, how to say, "compatible" with 16 color monitors and would look fine running on Windows 1.0. I'm one of those engineers/scientists that you don't want to let anywhere near a clothing store, and whose idea of painting is knocking a bucket of paint down the stairs and then trying to clean up the aftermath.
|
Don't you just love the nature of communication. Phrase something differently and you can start a war 
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
ginge
Site Admin
Joined: 14 Jan 2006
Posts: 1029
Location: Manchester, UK
|
| Posted: Tue Nov 18, 2008 12:42 pm Post subject: |
|
|
Wow! no idea what happened there. Something went horribly wrong.
I have merged your post back into your original post, and removed my post. See above for a repost. Confused? I am.
_________________
http://www.headfuzz.co.uk/
http://www.robotfuzz.co.uk/ |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Tue Nov 18, 2008 1:14 pm Post subject: |
|
|
| ginge wrote: | | Quote: | Ah, I see. Did the users find it too confusing to find a good gain, or was the wind-up and other related gotchas getting to be too complicated?
|
Wind up was ok, we just had a limiter... and a direction change reset, and .... damn now I remember this stuff being a pain in the backside.
|
Oh, you definitely don't want to reset the integrator if you change directions! Or at least not in most cases, I think. And, yeah, integrators always are a PITA because they do things people don't really expect. If it works without, do without.
| ginge wrote: | | Quote: | Just something for us to think about because we can include an integrator in the LQR control (it requires adding a virtual state). One thought would be to include an integrator, but set the default gain to 0 and "hide" it along with strict instructions not to turn it on unless the user is familiar with all the associated problems.
|
Up until version 1.8 we had the Iterator in place. We got tired of people enabling it and trying to balance it, so we just took it out.
There is no real reason why it couldn't go back in.
|
I agree with your reasons for taking it out. We'll inevitably put it back in along with the LQR because I'll need it for long-term calibration, but I see where this will run into problems.
| ginge wrote: | | Quote: | If you look at the first pdf I "linked" (danged anti-spam filter is driving me crazy),
|
You should be past the spam filter now, it is time and post limited.
I will go back and edit your first post to sanitise the link.
|
Thanks. It still doesn't work yet-- hasn't been two days since I signed up-- but I'll take care of the rest of the links once the ban is lifted.
| ginge wrote: | | Quote: |
The advantage of all this LQR stuff is that it's very easy to understand the design goals. If you will, the Q matrix gives the importance of minimizing the state error, and the R matrix the importance of minimizing the control. What's great about LQR is that you get to prioritize some variables over others. So supposing that you had a 4 dimensional state-- x, y, v_x, v_y, and you wanted to track a line along the y-axis with a given speed without deviating too far from the line. In this case, you could heavily weight x, so as not to deviate from the line, and v_y, so as to maintain speed.
|
Sounds great. assuming you can balance those weights to good effect.
|
As a general rule, I don't have too many problems, but I work with the stuff so that's not necessarily a fair judge. You can just assign use the identity matrix and go from there, that's one way to do it. I guess it really depends on what your user experience has been. I can easily imagine this being nightmarishly difficult, especially since the ramifications of a poor choice can be so catastrophic.
| ginge wrote: | | Quote: |
This is something you really can't do with a normal PID. I suppose, in a way, you could by weighting the error, that is to say you apply a gain to errors along a specific dimension,
|
Indeed. I tried something similar to this to allow more rigidity in the system when choosing motion mode. It oscillated, uncontrollably, and then exploded. It was a nice way of making a non-linear system much worse.
|
Yup, that's about what I would have expected. Once our code is working, we might try your system again with an LQR and see how you like it. Is this the one controlling a robotic arm? |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Tue Nov 18, 2008 1:22 pm Post subject: |
|
|
| ginge wrote: | Wow! no idea what happened there. Something went horribly wrong.
I have merged your post back into your original post, and removed my post. See above for a repost. Confused? I am. |
Woof? (because my 'f' key is pretty far from my 'k'. )
I'm confused, too, but it seems to be sorted out. Maybe I hit the edit button right at the moment you were hitting submit? I noticed because I was trying to edit a post, and it kept on giving me some weird text I hadn't written. It took me a minute to figure it out. On top of that, I didn't receive a response notification, so the system must have been as confused as the two of us were. |
|
| Back to top |
|
|
guru
Joined: 03 Jan 2006
Posts: 128
Location: St Pete Beach, FL
|
| Posted: Tue Nov 25, 2008 2:34 pm Post subject: |
|
|
Kubark2, can I ask what sort of applications you are interested in using the openservo for? You mentioned CNC milling, are you looking into servo control for the axis or spindle?
I am thinking it can't be CNC, you wouldnt be thinking about using Pots but rather encoders.
Colin |
|
| Back to top |
|
|
kubark42
Joined: 17 Nov 2008
Posts: 11
|
| Posted: Tue Nov 25, 2008 3:00 pm Post subject: |
|
|
| It's for my ball and plate project: http://www.eissq.com/BandP.html. I actually had a link to it in my first post, but because of the two-day anti-spamming measure I had to obfuscate it so you probably didn't see it. It's fixed now. |
|
| Back to top |
|
|
guru
Joined: 03 Jan 2006
Posts: 128
Location: St Pete Beach, FL
|
| Posted: Fri Nov 28, 2008 10:59 am Post subject: |
|
|
I had a look at your project and all the documentation...great work on the full documentation btw. I can only imagine all the diffuculties you must have faced with building a such a system.
In case you decide to use 2d convolution and require C lib, you can look at http://www.fftw.org/ . It has 2d image convolution routines, it's very fast, and easy to use. I used it for a number of DSP projects.
C |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
