Position-Integral-Derivative Controllers

Proportional-Integral-Derivative controllers are one of the most abundant type of control systems found in the world of engineering. It provides a flexible, (relatively) simple, and dynamic way to adjust outputs to achieve a goal with the optimal behavior.

First, lets define some terms. Kp, Ki, and Kd are the constant values for the proportional, integral, and derivative components respectively. These three will be different for every situation and every PID controller. MV is the measured variable, the characteristic of the system which we can measure on some regular basis. CV is the control variable, which is the characteristic of the system which our controller can directly manipulate. SP is the setpoint, or the value which we want MV to become.

For example, examine an application where we must heat a tank of water by controlling the temperature of new water flowing into the tank. SP is the desired temperature and MV is the current temperature. CV is the temperature of the in-flowing water.

The proportional component is the simplest part of PID. In proportional control, the CV is set proportionally to the error between MV and SP. This corrects the error faster the larger the error is, which can provide a gentle correction curve. However, proportional control is prone to several errors. First, if there is some other force acting on the system (such as heat dissipation in a temperature control system or a heavy load on an elevator), MV will settle at some offset from the desired value, since the proportional correction will be equal to the other input force. Additionally, too low of a Kp may have trouble reaching SP, and too high of a Kp may overshoot or even oscillate around SP.

Integral control fixes some of the problems presented by proportional control. In integral control, a correction factor is applies that is the integral of the error term. In a real system, measurements are non-continuous, so this is approximated by adding up the error terms at some high rate. This resolves situations in proportional control where the MV has flattened out but is not yet at the setpoint, by summing up the error values and correcting for them.

Derivative control is the least common of the three components. The derivative of the error is taken, and then summed with the other components. This allows the controller to dampen itself and avoid overshoot, by decreasing the correction factor if the slope rises too high.

One way to visualize the three components by comparing which part of the process they are interested in. Proportional control only corrects based on the current value, regardless of the behavior before or after. Integral control can correct for a history of errors; if the past behavior is not reaching the setpoint, then the integral term will sum up and push MV to the setpoint. Derivative control looks at the slope of the error and can be used to control the future behavior, avoiding overshoot or other unintended behavior.

However, PID Control is not always flexible enough to control complex systems. PID assumes that the systems is controllable at a relatively high frequency, is symmetric, and behaves in a linear way. For example, a building temperature control system which has only a passive cooling method but active heating puts special restraints on what PID constants are effective.

There are many, many modifications of PID controllers that have been used to solve more complex systems. Some systems may require a "feed-forward" term, sometimes included in the other three as Kf. This is a flat term that is summed together with the other variables, and continuously drives CV. This might be used in an application that requires lifting and holding a weight. If the feed-forward term is set to counteract the force required to lift the weight, the PID controller can act as if the weight is zero.

Other solutions include wrapping a faster PID Controller inside a slower one, forcing some maximum or minimum ramp rate, using multiple PID constant values for different situations, or scaling the setpoint according to some trajectory.

Real-time control systems are systems where the controlling logic has only two ways of interacting with the system: reading sensor input, and writing to physical outputs. This field includes robotics, telescope control systems, and most applications involving a physical system being driven by a digital controller.

An approximate description of a real time system.

This diagram roughly describes the control systems of a modern real-time system. The user generates a set of input data, either by giving information through input devices such as controllers or a computer, or by inputting a desired state which the controller attempts to reach. The controller compiles together sensor data and user data, and determines a set of output data to be written to motors and actuators.

The most important and complex part in these systems is the Controller; the logic, calculations, PID controls, trajectory calculations, etc. that determine the behavior of your system happen in this controller.My next post will explain a simple overview and how to use PID, feed forward, and trajectories.

Time Began in 1970

When I was doing the first autonomous test drive of our robot, I found that no matter what I did, it always flew off in a particular diagonal direction, no matter what the inputs were. When I tried to get more information about the speeds the motor controllers were calculating, I found that I was getting massive numbers around negative two billion. This meant the robot was trying to move at billions of meters per second backwards in both the horizontal and vertical axes. Fortunately, our motors have a limit of around 10 meters per second, let alone the 1000 times the speed of light they were trying to go.

At first, I had thought that this might be an integer overflow issue. In most programming languages, integers that reach a certain maximum value wrap around into the most negative possible value, as demonstrated by the circle below.

Found at https://log0.wordpress.com/

If you traverse counterclockwise, you reach a very large positive number, then instantly find a very large negative number. My hypothesis was that the code was calculating massive velocity values incorrectly, and looping around into the negatives where for some reason it worked fine.

I soon realized that the problem was something entirely unrelated to integer overflow. First, that the values used to track the velocity of the robot are 'doubles', which have a different max value than integers. Second, although the velocities were suspiciously close to the -2147483648 of negative integers, they started at a value only coincidentally near it.

So after many more hours of debugging, we finally found the error: as far as the robot understood, it had been driving in a diagonal line since the first moment of 1970.

Time in the world of computers is measured by UNIX Time, a count of the number of seconds since 00:00:00 1/1/1970 Coordinated Universal Time (UTC). This has led to joke sayings such as "time started in 1970" or "everything before 1970 is made up." The advantage of UNIX time is that it allows time measurements to be consistent to a second across all computers, and for higher level programs to generate dates and calendars in a consistent way.

However, what day it is shouldn't have any effect on the robot's driving, it only needs to know how long it's been since it started. Because the time was never shifted into relative numbers, the robot was attempting to undo 45 years of driving. The drive correction loop is proportional, so the correction velocities were very large.

http://xkcd.com/376/

An Introduction to FRC and Autonomous Robotics

Welcome!

I am a member of FRC Team #4183, also known as Bit Buckets Robotics. We are a local Tucson team consisting of an extremely talented group of High School students and mentors. As a team, we focus on finding the most effective solutions to the engineering and design challenges we face.

We participate in the FIRST Robotics Competition, which is a world-wide robotics competition design to give high school students a taste of real world engineering.

The varsity Sport for the Mind^TM, FRC combines the excitement of sport with the rigors of science and technology. Under strict rules, limited resources, and time limits, teams of 25 students or more are challenged to raise funds, design a team "brand," hone teamwork skills, and build and program robots to perform prescribed tasks against a field of competitors. It’s as close to "real-world engineering" as a student can get. Volunteer professional mentors lend their time and talents to guide each team. -FIRST

 Competing in FRC is a task which requires a team to excel in many different fields - CAD design, electrical engineering, fabrication, computer programming, robot driving skill, graphic design, project management, organization, fundraising, obtaining sponsors, networking. I personally am part of the programming team, and most of my time researching, writing, documenting, and testing code which will run our robot.

While programming a robot is the job of multiple people on our team, I personally am in charge of programming the autonomous side of the robot. This years FRC competition requires the robot to operate without any user input for the 15 seconds of the match.

Autonomous programming is something that many teams fail to complete to a reasonable degree - some because they run out of time programming other parts of their robot, or some because they do not understand an effective way to go about it.

The goal of this Senior Project is twofold: first, to learn and program effective autonomous operation on team 4183's robot, and second, to teach and assist other teams in attempting autonomous operation in future years.