[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.