DPRG List

 [DPRG] Re: Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] Previous message: [DPRG] Re: Next message: [DPRG] Re: ( was switcher) Subject: [DPRG] Re: From: Kipton Moravec kip at kdream.com Date: Sat Dec 27 15:27:01 CST 2003 ```Sorry David, I did not mean to wave hands. I was trying to explain what I think is wrong and gave two different ways to solve it. Obviously I did not make myself clear the last two times, and Chuck's write-up was also not clear enough, because I think he was saying the same thing in a different way. So I will try one more time. You have two options. 1. More Battery Voltage. 2. Tune it to work at a lower voltage. If your system will not preform at the lower voltage because of the torque needed to balance, then add more voltage. This is what you are already doing with the regulator. To get 24V out, you had to add batteries to make the input 27V or greater. What I am saying is to try it with the 27V (or whatever) without the regulator. What I think the problem is, has to do with running out of PWM. When you hit a PWM of 100% duty cycle you can't do more. If you are running the system close to maximum PWM, if the battery sags, you can't have more than 100% So you need more headroom, so increase the battery voltage, but pretend it is still 24V. The PID should then compensate for the lower voltage. The other option is to make it work at 18V and keep the same 24V battery. But because of the system, 18V may never work, because it does not generate enough torque to allow the robot to balance. ----------------------------- There is also a chance that the parameters are not optimal. I would propose a Monti Carlo search to determine the parameters. If you have a day this week you want to work on a Monte Carlo search for optimal parameters, I will come on down and we can work on it together. I assume you have an idea of what "good" and "better" control looks like for your system. If not, I would propose running the robot in a certain path, and summing the square of the errors. Adjust the parameters and run the robot in the same path and sum the square of the errors again. If the sum is less in the second case, then those parameters are "better". This is repeated until you can not find any "better" combination of parameters. The Monte Carlo portion of the technique adds a random number (the number can be positive or negative) to each of the parameters (K1..K4) to generate a new combination to try. Now that I have looked at the code, and see you are using integers for each of the factors perhaps it would be best to try all of the combinations of adding -1, 0, or +1 to each of the 4 K values. That would be 3^4 = 81 tries to locate the best value for one iteration. The one with the least error is the starting point for the next iteration. Fortunately you do not have to do 81 on the second iteration because some of the combinations of values have already been tested. Kip At 11:40 AM 12/27/03, you wrote: >Howdy > >Kip is accurately describing the behavior of a "normal" PID control >system. However this not an accurate description of a balancing robot. >The balancing "PID" algorithm includes two other terms in addition to >the proportional, integral, and derivative of the base position/velocity, >and those are the robot angle and and its first derivative, the angle >velocity. > >And therein lies all the difference. > >Kip's description, to alter the PWM pulse widths based on the velocity >error, is indeed how my other robots (SR04 and Legobot) work. But in the >context of the balancing robot, his described algorithm would not >drive the robot at a constant speed, but rather would make it fall over. > >So the sweeping pronouncement (for which he is justly famous!) that >"the control loop is wrong" may well be the case, but not for the >reasons that he states. > >The speed of the balancing robot cannot be controlled by adjusting the >velocity of the motors. Rather, the speed is indirectly controlled by >adjusting the tilt angle of the robot. > >This is why the simple PID algorithm which he describes below is not germain >to this problem. Give me a break, Kip! If it were that simple, I think >I could have solved it by now! :) > >In fact, the hardware solution that Brian suggested is the first approach >I've tried that actually _does_ solve the problem. If this same solution >can be implemented as a simple alteration to the control loop, then >enlighten me! > >A good place to start is the algorithm itself. I use the same one that >Dean Kamen uses on the Segway. Here's a pointer: > >http://www.geology.smu.edu/~dpa-www/robo/nbot/bal2.txt > >complete with ascii-art block diagram and C code. All suggestings are >welcome! No hand waving, please. > >On the other hand, Chuck's suggestion that the control loop adjust >current (and therefore torque) directly seems like he is on the >right track. In point of fact, that is what gets accomplished by >holding the driving voltage constant. Is there a better way to >do this? Perhaps some hybrid of the H-Bridge? In particular, >how to accomplish his suggestion that: > > > To wrap it around to the original thread, I'm guessing that if Dave > were to > > use his PWM algorithm to feed the current cut-off circuit of a chopper > > drive, then his motor control would be controlling current (and torque) > > directly, and as long as the batteries had enough voltage to generate the > > maximum torque requirement his system would remain remarkably stable. > >cheers, >dpa > > > I am trying to figure out a simple way to say this. I read Chuck's > > clarification of what I wrote, and I think some people will still be > confused. > > > > > > The PWM, or the voltage to the motors, because of ohm's law, adjusts the > > current. The current provides the motor torque, which is used to adjust > the > > rotational speed of the motor. The speed of the motor, in terms of > encoder > > ticks per unit of time, is fed back to the system and a difference (error) > > is used to determine what needs to be done. > > > > If the error is positive, meaning the desired number of ticks per unit > time > > (speed) is greater than the measured ticks then the PWM duty cycle must be > > increased. > > > > If the error is negative, meaning the desired number of ticks per unit > time > > (speed) is less than the measured ticks then the PWM duty cycle must be > > decreased. > > > > If you have completely analyzed the system and know all of the > > relationships, input voltage, PWM Duty cycle, current per unit torque of > > the motor, motor winding resistance, inertia, mass of the robot, etc, you > > can generate the math and get pretty close. But most of the time we do > not > > have all that data and it changes over time. So we have to estimate > > it. PID is a way to estimate it. It hides all of the nasty equations and > > unknown variables. > > >_______________________________________________ >DPRGlist mailing list >DPRGlist at dprg.org >http://nimon.ncc.com/mailman/listinfo/dprglist ``` Previous message: [DPRG] Re: Next message: [DPRG] Re: ( was switcher) Message index sorted by: [ date ] [ thread ] [ subject ] [ author ] More information about the DPRG mailing list