PID control loops - closed loop feedback

[10intheCrunch]

Before we limited the integral, we found that it could wind itself up into the thousands if we weren't *very* careful. That could happen if the OI was off, the robot was on, and the arm moved, or if a velocity went in and the arm was held down. An integral that high means that when the arm is allowed to move, it will smash all the way over and ram into itself, or do other nasty things to itself.

We found that the integral never actually gets higher than 30-50, and thats very rare too. Usually it is under 20.

We run the elbow loop at 10hz, and the wrist loop at 5hz. That leaves enough time to create a speed error we can actually work with...too much faster and we get mostly 0 speed with intermittant high speed as it actually moves. Very bad.

edit: To the above poster: You're right. The proportional is supposed to be the major factor when the speed error is large, and the integral builds up to balance it out and hold steady as the speed error decreases (ie the integral maintains the speed the proportional generates). It just so happened that the arm worked best for us when the proportional and integral were both 1/8. It took a lot of testing and frustration to find the right values.

[Larry Barello]

Originally Posted by maxlobovsky

ok, but i thought the solution to that is to sum over a shorter period of time and use a small enough coeffecient. The integral term just becomes an additional proportional term in the code posted above when the error is large enough.

.... on second though, that isnt really a problem as the integral term isn't needed when the error is large. And i was presumptious enough to think that years of science and engineering could be faulty....

The PID controller is a vast simplification. It takes a while to get a handle on all the things going on and why it works, or, more importantly, doesn't work.

The best way to think of the integral term is that it, eventually, will compensate for all those unknown things that prevent you from getting to your goal (position or velocity). The problem is that if your position setpoint is moving all the time (plus & minus, typical for an arm) the integral needed going forward is precisely the wrong thing for moving in reverse! Best to just leave out.

[10intheCrunch]

Originally Posted by Larry Barello

The problem is that if your position setpoint is moving all the time (plus & minus, typical for an arm) the integral needed going forward is precisely the wrong thing for moving in reverse! Best to just leave out.

True, the integral is going to be in the wrong direction at times, and you are going to have a slower response time because your joystick is not hooked directly to the motor values coming from your program. But best to leave out? No...

Without an integral in our program there would be no way for us to control our arm, much less control it with a ball. The integral needs to build up to maintain zero velocity when the lever arm and torque is great, or the arm will simply fall. There really is no way to manage it dynamically otherwise.

We suggest you use the PID loop to control velocity, because that's what's coming out of your joystick. Position may be very tricky, and as Jay and I said, the position system just generates its own velocity value. Don't knock PI loops until you've tried them! We would never have done so well without it.

[Rickertsen2]

Originally Posted by 10intheCrunch

True, the integral is going to be in the wrong direction at times, and you are going to have a slower response time because your joystick is not hooked directly to the motor values coming from your program. But best to leave out? No...

Without an integral in our program there would be no way for us to control our arm, much less control it with a ball. The integral needs to build up to maintain zero velocity when the lever arm and torque is great, or the arm will simply fall. There really is no way to manage it dynamically otherwise.

We suggest you use the PID loop to control velocity, because that's what's coming out of your joystick. Position may be very tricky, and as Jay and I said, the position system just generates its own velocity value. Don't knock PI loops until you've tried them! We would never have done so well without it.

I was thinking about PID loops in situation with rapidly changing w, and the phase lag time of the I term causing problems when this occured to me, and i was wondering if anybody had any input, wanted to tell my why i'm wrong, or if they had tried this before:

The PI algorithm that we use for everything uses a data element we invented called a CSStack for the I term. Its basically a dynamic variable lenght mutable circular buffer. It seems to me that response could be improved by dropping certian old values from the buffer in times of rapid w change. What about dynamically changing Ki according to the derivitave of w? Any input? What other sorts of optimizations have people made to the basic PID algorithm? Is anybody using somethign other than some variation of a PID controller?

[Max Lobovsky]

Originally Posted by Rickertsen2

I was thinking about PID loops in situation with rapidly changing w, and the phase lag time of the I term causing problems when this occured to me, and i was wondering if anybody had any input, wanted to tell my why i'm wrong, or if they had tried this before:

The PI algorithm that we use for everything uses a data element we invented called a CSStack for the I term. Its basically a dynamic variable lenght mutable circular buffer. It seems to me that response could be improved by dropping certian old values from the buffer in times of rapid w change. What about dynamically changing Ki according to the derivitave of w? Any input? What other sorts of optimizations have people made to the basic PID algorithm? Is anybody using somethign other than some variation of a PID controller?

well this buffer was what i was invisioning when i was asking about having the integral last over a certain length of time rather than from initialization. I didnt think about changing this length of time dynamically, but that could make for a pretty complex, if not effective, control. I have been doing a lot of research and some loops do have dynamic coefficients. Regardless, it seems to me that when you are dealing with 8 bit or less precisions and when the systems are so full of unpredicted forces that Larry Barello was right when he described FIRST as being classified as low performance. If you do implement anything this advanced, please post some data comparing it to simpler algorithms. IE response times, or even better, response curves.

[10intheCrunch]

If you start dropping values off of your integral, you are going to have a hard time keeping a steady state (ie velocity = 0) for any amount of time. You won't have a speed error, and so your integral won't change, but you still want it to hold still.

Rick is probably right in that you can increase your performance by dropping values off during times of high theta change (high omega), but the complexity of performing that may become difficult in C--I would think an object oriented language would assist much more in this (dynamically sized queues are also really difficult to program on our tiny little memory block on the robot...). Conceivably you could make another PID loop feed into your main one to change the constant's values, but just the straight loop works quite well with a little driver knowledge. I think that inputting another loop or trying to dynamically drop values will either make it far too jumpy or unstable.

One last (though possibly minor) problem is drawing too hard on the battery and overheating the motors. We considered zeroing the integral if the direction of the motion was opposite the target direction but concluded it would draw too hard and be harder to control in the long run.

[Rickertsen2]

Originally Posted by maxlobovsky

If you do implement anything this advanced, please post some data comparing it to simpler algorithms. IE response times, or even better, response curves.

Alright i will. Once we get our robot back, this is the sort of thing i will be messing with the rest of the year. Also, who says that jsut because you have an 8-bit processor you are limited to 8 bit precision. There are other data types that arn't 8-bit. We needed something that could handle decimal values, but didn't want to use floating point, so we invinted our own fixed point system. I may publish that at some later time. I mean in the end we are limited to 8-bit motor control, but that shouldn't be too much of a problem. It seems like thats plenty. As far as input resolution goes we arn't really limited. We can add whatever sensors we want, and higher precision ADC, etc to support them.

Btw, you say you have been doing research on variable coeff algorithms, do you have any links? Any books i might read? I have wanted to learn more about feedback control loops, particulary adaptive ones, but havn't really known where to look. A freind of mine gave me a book on feedback control, but its more about analyzing the effectiveness of control loops rather than designing them.

[KenWittlief]

any college library would have a shelf full of books on control systems - only problem is they require you to understand the math they use - most of it is worked out in the frequency domain - convolution - imaginary numbers

lots of fun at first, but once you get your head into that way of thinking it becomes intuitive.

another good source is to seach the web for companies that sell control system hardware - stepper motors and servo motors - linear amps and feedback sensors - lots of them put out application books and white papers on how to use their stuff- and its all based on PID control loops.

[TedP]

Because this thread is so long, I haven't had a chance to read it all, but I see some common themes coming up... some people fighting for using PID... some people fighting to understand the math behind it... some people just looking for examples. I do a great deal of linear and non-linear control applications when I'm not doing FIRST, so I was thrilled this year to have some time to help the team build in some simple feedback controls systems to control not only our drive train but a two-jointed articulated arm.

And so I want to comment on a few things... But first, as a reference, if you would like some examples of PID (actually PIID, notice the second I) feedback loops as well as some other important modifications, take a look at our code for this year's Pittsburgh regional:

http://www.osufirst.org/twiki/bin/vi...04RegionalCode

To give some background, the robot is driven by one joystick out of the box, a number of buttons and switches, and a mock-up of our actual two-jointed arm. This mock-up has potentiometers built into each joint just like our big arm. Our big arm tracks the position of the small arm. Additionally, our drive train wheels have Banner sensors encoding every 36 degrees of their rotations into "ticks" that can be handled by interrupt handlers tied to digital inputs 1 and 2. If we had our ticks spaced correctly, we could run the Banner "normally closed" input into two more digital inputs to get double the resolution. There are some other software tricks to increase resolution, but they need speed first... and we need speed first anyway...


Use Speed Control for Actual Motor Control Whenever Possible

So my first comment is on speed control. Because motors inherently output speed and not position, even though you have position sensors (effectively), it's much easier to control speed. However, it's not trivial to calculate speed on such a robot with all of these quantization issues. For example, it's tempting to calculate speed by counting the number of ticks that pass by your encoder in a particular time. If you have lots and lots of ticks and are not sampling that fast, this works fine. However, if you're sampling fast with respect to the tick changes and you don't have that much resolution so the ticks take a long time to get noticed, you need a new way to calculate speed.


How to Calculate Speed in Software Quickly

On our robot, we have a clock running that keeps track of the number of 100ths of a second (centiseconds) that have passed. This is an "elapsedTime" variable. This is setup using interrupts, as is explained on IFI as well as many places here. Now, the interesting part is that our interrupt handler that catches the tick transitions of each wheel doesn't just increment a counter; it also calculates the time difference between the current tick and the last tick and also stores the current time. This time difference allows for the current speed to be easily calculated (in our code, in inches per second), except the problem is that if the robot stops turning, it will never register that we've slowed down to 0. So in our fast code, we calculate the difference between the current time and the previous tick time, and if that grows too large for our slowest speed (slowest speed is found by ramping up input until the robot moves and recording that speed), then we assume we've stopped.


Calculate Acceleration Too: This is Important Later

At each tick, calculate a new acceleration based on the change in speed over the time it took to move from tick to tick. This is much simpler than the speed calculation, but you should do it here rather than anywhere else so that it stays constant from tick to tick. Again, you should have some way of bringing the acceleration to 0 if the robot is stopped.


Use Constant Time Sampling

It doesn't always pay to do things as fast as you can. In these applications, sampling your actual data at 100 times a second is probably enough. So even though you are calculating speed very quickly from those interrupt handlers, actually create "speed samples" that will be known to be constant over the whole sample. This will become more important later when implementing the PID controller.


System Identification: Keep It Linear!

While a great deal in engineering is random, unknown, and often unsolvable, nothing in engineering is black magic. Once you can capture speed being outputted each 100th of a second to the program port, it is easy to characterize your system (or a linear approximation of it). This can be done by software encoding an input which sits at 0 for a small time and then immediately jumps up to some value (otherwise known as a "step" input). The input speed from the wheel turning due to such an input can actually give you the PID coefficients almost directly. (REMEMBER TO USE CONSTANT TIME SAMPLING!!) If you are not familiar with this compensation process or have no one around you who is familiar with root locus and/or Ziegler-Nichols methods, then you can bypass this section entirely.

However, if you do do system identification on your robot, be sure that your step is not too large!! Having your robot jump into a speed that is approaching its saturation point will unfortunately cause your response to characterize a particular point on a very non-linear side of the motor. If you want to approximate your motor as a simple second-order linear time-invariant system, you probably should do it in the region where the change in output over change in input is still fairly constant.

Note that in the 1014 code, we actually took a step and implemented it, but unfortunately our drive train changed substantially after the step was taken and we weren't able to use our optimized coefficients in time for competition. We resulted to setting these coefficients heuristically, and things worked very well during competition.


Before Implementing: Condition Inputs and Outputs

Create functions that will take in a value from -128 to 127 and output a PWM signal that has had a dead-zone applied (and possibly a hold-over zone) that goes from 0 to 255. Keeping your code in terms of -128 to 127 will simplify things GREATLY. This makes things all "linear" rather than "affine."


The Basic PID Controller

PID is simple to implement. The basic pseudocode goes something like this. Keep in mind the last note about conditioning inputs and outputs to be centered around 0. Also remember that both actual_seed and actual_accel are available as they have been calculated already. NOTICE THE USE OF Ts. This is the time between samples. If you sample 100 times a second, this is thus 0.01. THIS IS VERY IMPORTANT. It will help make your Ki gains much more reasonable. It is needed to approximate an integrator. It is the "width" of each rectangle that is being integrated.

error = desired_speed - actual_seed;
output = Kp * error + Ki * Ts * sum_error + Kd * actual_accel;
sum_error += error; // Don't actually do this!!! SEE NEXT NOTE!!!

The goal is then to set the Kp, Ki, and Kd coefficients properly. If you have identified your system, this is easy to do. If you have not, keep this in mind, and BE CAREFUL as you can EASILY CREATE OSCILLATIONS:

Kp: Proportional Gain - Sets the shape of the output to generally match the input

Ki: Creates a lag in the output that helps smooth transitions. This also causes overshoot due to this lag. However, a great thing it does is that it gaurantees no steady-state error. After some sufficiently long period of time, if enough of this term is added in, the output will match the input exactly.

Kd: Speeds up the response. This reduces the lag caused by the Ki control. However, not only does it couple in lots of noise into the system, but it can actually cause steady-state error problems (because derivatives of constants are 0).


Dealing with Integer Overflow: SATURATE

If that sum_error term just keeps getting added to over and over again, it will very quickly overflow. This will turn a VERY LARGE POSITIVE NUMBER quickly into a VERY LARGE NEGATIVE NUMBER. Integral control can on its own cause nasty oscillations just due to its delay/lag. However, adding this fun roll-over effect creates even worse ones.

To fix this, wrap something around the addition that prevents it from ever rolling over. Something like:

sum_error = safe_add( sum_error, error );

Where safe_add makes sure that if a positive is added to a positive, a positive comes out, and if a negative is added to a negative, a negative comes out.

You can see our PIID code in user_routines_fast.c. There is an additional integrator to allow us the freedom to tune our second order (ramp) input response. There are reasons for this additional I, but I am placing them outside the scope of this message. This controller does show all of the points above, including some more.


Be Careful: Literals are BYTES by Default

In this process, if you use ANY literals, be sure you explicitly cast them as, for example, int if they are negative or over 127. Otherwise your 255 looks like a -1 to the PIC.

In general, be careful about your signed/unsigned conversions. Things may not be as you think they seem.


Use State Machines in Autonomous Mode Once Good Controllers are Built

Once good speed and position controllers are built (position controllers can be built on top of speed controllers), use state machines to move from one state (motors driving forward) to another state (motors turning robot left) to another state (motors driving forward again) to...... The only time you should have to look at your feedback in autonomous mode is thus when to CHANGE STATES. Otherwise, you let the speed controller do all the hard work for you.

See the 1014 code for an example of this.

Additionally, it is possible to build "steering controllers" that are PID based in themselves. These can take angles and forward velocities and turn them into left and right motor CONTROLS which then get fed into the left and right motor PID controllers which then turn them into motor commands.


Some Simple Benefits (and Cons) of Feedback Control

Being able to count on a controller to deliver a very simple task is so important. This allows the driver to simply "suggest" a speed with his or her joystick and the robot will handle all the rest. The driver can then get up the step at a slow speed, for example. Rather than running straight into the step, the driver holds the joystick constant and the feedback controller figures out how to get up the step to maintain its own speed.

Additionally, for that same reason, a real feedback controller actually makes the torque-speed curve of a motor almost entirely horizontal (within a certain range). This actually can be dangerous because the robot will perform CONSISTENTLY under ANY BATTERY POWER and it may be easy to forget to monitor it's battery life.

Plus, these controllers are extremely robust. People spend hours dealing with open-loop filters on joystick inputs and often come up with odd non-linear controllers which have no easy way to optimize. The linear feedback control system uses the motors own natural low-pass effects to smooth out its own input. The linear feedback control system needs very little tweaking to be operational, and will do its hardest to perform as close to optimally as possible even on a low battery or when facing an odd load.

However, there is a much stronger dependence on hardware. There is a tremendous increase in complexity. There simply are costs for all the things that the feedback gains you.


Anyway, I hope that code might help some people. I'm afraid my post might be too long to help pepole directly, but hopefully some will read it. The system works great on our robot; I hope it can help yours.

[10intheCrunch]

Wow, great post!

A few questions, though: first, how high a resolution encoder are you using? You spoke about sampling at 100hz, which is *much* higher than our sample rate (5 and 10hz)--we found that anything higher didn't allow for much change at all during one tick and as a result operated inproperly. We use a potentiometer on the motor with 1024 ticks on it (10 turns), using about 900 in the actual arm scope.

Two, just as general practice, make sure to use 254 instead of 255 (and -127 instead of -128, or you're adding too much); you can get into trouble with the speed controllers with 255.

Three, what circumstances are you dealing with integer overflow? We've never had anything close to that high an integral, much less wanted it (it would cause the motor to swing all the way over and jam the arm into the robot...). Perhaps we have radically different output systems, but our integral never really gets higher than 30-50 (and that can be dangerous).

Hey but thanks for this! Now I gotta sit down and try to understand the part about linearizing it...

[KenWittlief]

Great post by TedP - only thing I would add is the motor speed is not the only way to go

for our auton mode we were more concerned with robot heading, so using a yaw rate sensor was the easiest solution - for most driving situtaions getting the robot pointed in the right direction is the trick, how fast it move (preciesly) is of less concern

you can calculate how fast your bot is turning by having speed sensors on both wheels, but its much simpler to plant a yaw rate sensor on your frame somewhere and read it directly.

BTW - if anyone is wondering if this stuff is worth the trouble- yes! our auton mode worked very well when our team coach remembered which 'left' to set the switch to (left or the other left)

and at Buckeye our team won the Johnson & Johnson quality in controls award - I think not so much because of the PID closed loop feedback we had on our steering, arm elevation and arm extension, and the use of IR sensors - but because our students could explain so well to the judges how it all works.

sophestication is good - understanding is excellent :^)

[Larry Barello]

I am very cuious, why do you use the double integration? What was the issue with leaving it out?

For team #492, we only used PI for our velocity control and PD for our arm had excellent results. Attached is our servo code. It is considerably different from the typical examples and I will be publishing (sometime) a white paper on the subject out at http://www.titanrobotics.net on the subject. Highlights:

1. we modeled the drive motors and compensated for the back-EMF with some posative velocity driven feedback. By moving this large, known error, outside of the control loop, we were able to remove most of the integral term and vastly improve the stability of the system while keeping tight control.

When properly implemented, back-EMF compensation (when in "torque" control mode) makes the robot feels "frictionless". Very cool to be able to push the robot and have it glide across the floor... In fact, that is how I tuned it: pushed the robot back and forth and adjusted the kemf values (left, right, forward, reverse) until the robot glided without speeding up or slowing down, in a straight line. This has obvious control implications: speed errors generate a torque command, when up to speed, the torque command goes to zero (no integral term needed!) yet the robot continues to zoom along.

2. We used gain scheduling on our arm. Actually, all we did was divide the K term by 16 when overhead because of the drive slop and lack of gravity keeping things taut. Still, gain scheduling sounds cooler

3. We also limited the maximum torque (current) to our motors. Rather than using the FIRST supplied current sensors (which would have been the precise way to do this) we used the back-EMF technique. Anyway, by limiting the maximum torque we avoided all issues of overheating our motors and popping circuit breakers. With a dual motor, simple gearbox (no shifting) design we still had plenty of power to push goals and robots around

[Larry Barello]

Originally Posted by 10intheCrunch

...
Three, what circumstances are you dealing with integer overflow? We've never had anything close to that high an integral, much less wanted it (it would cause the motor to swing all the way over and jam the arm into the robot...). Perhaps we have radically different output systems, but our integral never really gets higher than 30-50 (and that can be dangerous).

Typically, if you are running near the edge of your control abilities (pushing your hardware to the limits, which I am *always* doing), when the output saturates (e.g. ->254 in IFI systems) and you have not made your setpoint (velocity or position) the error term grows without bounds. The solution is simple: stop accumulating errors if the output saturates.

In the code I posted (above), we have a torque limit and stop accumulating the integral error when that has been hit.

Cheers!

[TedP]

Originally Posted by 10intheCrunch

A few questions, though: first, how high a resolution encoder are you using? You spoke about sampling at 100hz, which is *much* higher than our sample rate (5 and 10hz)--we found that anything higher didn't allow for much change at all during one tick and as a result operated inproperly. We use a potentiometer on the motor with 1024 ticks on it (10 turns), using about 900 in the actual arm scope.

Re-read some of the notes I made. We don't calculate speed the same way you do. Rather than looking for the amount of ticks that go by every sample, we look at the amount of time that goes by evey tick. This is much more asynchronous and updates the speed whenever it CAN rather than whenever I want it. (and we had to add something to force the speed to go to 0, but that was a simple fix -- all of this is documented in my note and is in the code)

To answer your question directly, we only had TEN ticks per revolution on our drive wheels (unfortunately that was about 4 to 5 inches per tick) and our maximum velocity for this robot wasn't any higher than around 50 inches per second. So we were ticking very very slowly... But we didn't calculate speed every sampling period, we calculated it every tick by recording time rather than recording ticks.

Originally Posted by 10intheCrunch

Two, just as general practice, make sure to use 254 instead of 255 (and -127 instead of -128, or you're adding too much); you can get into trouble with the speed controllers with 255.

Every year I always hear that... but I never pay attention to it... and I'm always too lazy to see the reason why. I figured that 255 was some special mode that the speed controllers got in... perhaps an OFF mode or something... and I THOUGHT one year I found out why there was so much commotion about it and that particular year they removed the reason for that commotion... but I don't remember. Anyway, I've never had a problem going full scale... but that's definitely something that could easiliy be fixed.

Originally Posted by 10intheCrunch

Three, what circumstances are you dealing with integer overflow? We've never had anything close to that high an integral, much less wanted it (it would cause the motor to swing all the way over and jam the arm into the robot...). Perhaps we have radically different output systems, but our integral never really gets higher than 30-50 (and that can be dangerous).

There are lots of reasons why you would have large integral, though they don't necessarily apply to everyone's robots.

For one, an uncompensated steady state output may simply have an output offset. As you sit "still" you'll sit there and churn integral error. The integrator is what brings you back to 0.

The otherwise, in very slow moving systems, the error adds up VERY quickly since it takes you so long to get to your set point. In other words, IF YOUR SYSTEM ALREADY HAS LOTS OF LAG, then your integral term, which is supposed to ADD LAG, will explode.

Of course, we saturate when we get too high. This protection is built into the code. It's a standard technique.

Additionally, the reason you may not see much of that integral term is because you may multiply by your sampling time period immediately during the sum. We sum without that factor (0.01) and then multiply the whole sum later.

And regardless, this is hardly dangerous. If the integral term gets large, that's fine. Just make sure your integral coefficient is set moderately correctly.

Originally Posted by 10intheCrunch

Hey but thanks for this! Now I gotta sit down and try to understand the part about linearizing it...

PID with constant coefficients already IS a linear controller. However, many of our systems are highly non-linear and not necessarily time-invariant. PID controllers have the strength to control such systems in many cases. It's important to understand the cases when this is not the case, but in most of FIRST's cases, a simple PID controller will work fine.

To understand where the non-linearities come from, I'll give two examples. The drive train moves from stopped to moderately slow in appoximately a straight line. That is, a little change in input causes a change in output proportional to that change in input, and that proportion doesn't change as long as you're moving moderately slow. Note that there is a jump from 0 to some velocity that is a non-linear jump, but I'm assuming we're over that hump.

But eventually those motors have to saturate. Eventually they can't drive your robot any faster. This may happen when your joystick is only halfway through its travel. Even though your joystick can increase the signal going out to the motor, the motor simply cannot turn any faster. This is probably going to an extreme, but the point is that even a large change in input won't necessarily cause a large change in output. I know I see this with our robot as it easily moves from 0 to 45 inches per second and then creeps up toward 50 or 55 inches per second at a much slower rate.

This sort of non-linearity causes all sorts of problems. However, without getting into them, the biggest issue is that your robot USUALLY is in the linear range. Your compensator should be built for the slower range where changes in input ACTUALLY CAUSE changes in output. If you build a compensator EXPECTING a very STUBBORN motor, then it will be FAR TOO HARSH during the rest of the motor's travel. It's better for the compensator to be gentle than harsh.

The other non-linearity, a much more interesting one, involves our two-jointed articulated arm. Assuming the shoulder is holding the arm straight up into the air, the elbow joint may be moving the arm with gravity or against gravity depending on its direction AND its position. As it crosses vertical, the role of gravity will switch. In fact, as it moves toward vertical, the role of gravity drastically changes. Additionally, as weight is added onto the end of the arm when it picks up a ball, things change quite a bit.

On top of this, the shoulder's position greatly affects how gravity will affect the elbow. If the shoulder is near horiztonal, we expect different gravity effects at the elbow based on its position. So in short, now position is a major variable in the control.

However, things get more complicated when you consider shoulder movement. The shoulder has a gravity component too, but its own center of gravity changes depending on the elbow position, and that changes how fast it can move along with all the problems associated with the elbow joint. So now the elbow joint's dynamics are coupled to both its position and the shoulder's position and the SHOULDER'S DYNAMICS, and the shoulder's dynamics are coupled to the elbow's position, the shoulder's position, and the elbow's dynamics (is the elbow moving or not? and where is the elbow while it's moving?). This is a much more complicated system, and traditional approaches to the two-jointed arm problem involve forms of gravitational linearizing and other methods.

However, our arm was so slow and had such a major gear reduction from motor to output joint (1250 reduction on the shoulder), we were able to use the simple PID controller on both joints fairly well.

BUT... we did add an integral term to both joints. We didn't want to slow things down, but we wanted to make sure that as the robot sat idle, it would correct any offset errors which were produced during its movement.

The topic of linear time-invariant systems is worth a whole career. The top of linear controllers fits into there. However, non-linear systems is an entirely different topic, and often does not benefit at all from linear system theory. Lukcilly, most FIRST systems are simple enough to not require such sophistication.

And, of course, the thing that won our Engineering Inspiration Award in Pittsburgh was less of the technical stuff we did here, but more of the ability of our students to use it to aid in their understanding of engineering. When our STUDENTS said that we had no error because the integral term compensated for it, the judges really appreciated that. When our students explained that a system can be characterized by its ideal PID coefficients and thus the PID coefficients need to be traded off from one to the other to find the right equilibirum, that's what impressed the judges. How well we did enforced that, and that we were able to help other teams with similar mechanical systems but very different controls surely helped... but I hope it's what the students portrayed that got us recognized.

[Larry Barello]

Originally Posted by TedP

...

Every year I always hear that... but I never pay attention to it... and I'm always too lazy to see the reason why. I figured that 255 was some special mode that the speed controllers got in... perhaps an OFF mode or something... and I THOUGHT one year I found out why there was so much commotion about it and that particular year they removed the reason for that commotion... but I don't remember. Anyway, I've never had a problem going full scale... but that's definitely something that could easiliy be fixed.

The 255 issue is a holdover from the old PBasic days. The packet sent between the the user processor and the control processor used two "255" in a row to delimit the end of a packet. If you sent out a bunch of 255 as PWM values the packet would be truncated. This happened to us in 2001: at stick extremes the two PWMs went to 255 and got the packets out of synch and all heck broke loose.

The current system still uses the 2x255 but hides it from you by "adjusting" 255 to 254 before sending it to the control processor. We discovered this when trying to send telemetry data back. We were using some of the unused PWM slots for the dashport, so we could get data back each cycle. Well, no such luck. So we limited the data to 7 bits and used two slots to pass 14 bits of data back. (it was gyro angle in .1 deg so it needed to be an int).

Now that IFI has given us a real processor, it is time to give a real radio without these limitations.