Drawbacks of a fake Ki (P loop)

Hi everyone. I’m fairly new to PID loops and started with implementing only a p loop for our last tournament. It worked pretty well except that, even with making the Kp constant larger, it slowed down too much for the final few inches to the target. A Ki would fix this problem, but due to the time-crunch I added a “fake Ki” that worked as follows:

//pseudocode 
const double Kp = 0.3;

while(error<3) {     //loop exits when the robot gets within 3 degrees of target 
error = target - averageEncoders;
power = error * Kp; 
     if (power < 10)&&(power > 0){   //false Ki for moving forward
          power = 10;
     }
     if (power > -10)&&(power <0){  //false Ki for moving backwards 
          power = -10;
    }
moveDrive(power);
pros::delay(10);
}//end of loop

This seemed to work really well and cause the robot to reach the target much faster. I’m probably not the first to think of the false Ki, but I also haven’t really seen it used regularly by other teams, which got me thinking, what are the drawbacks of having this fake Ki vs a real Ki?

In chassis movement I would typically do a combination of a kp and kd loop.

I’ve tried it before, the robot fails to settle quickly after overshooting the target

1 Like

I really wouldn’t call that “fake Ki”. If I was trying to come up with a name (in control theory lingo) for what that is similar to, I would call it feedforward constant. Because its pretty similar in practice to saying

power += 10 * sgn(power)
They would both have similar behavior in that you exasperate oscillations.

The problem you were experiencing would probably be fixed more properly with a D term as well, with a much larger kP value. The integral term in general has very little effect until the robot would have come to a complete stop without it, ie your robot comes to a complete stop 1 inch short of the goal (steady state error).

8 Likes

I didn’t know about the sgn() function, thanks for sharing! Also hadn’t thought about adding the value (in this case 10) to power itself, which would perform pretty similarly to using the if statements to set a minimum rpm (what I had called fake Ki).

Yeah, I see how it won’t work if your P loop causes the robot to overshoot all the time, but it should work fine if the P loop is tuned so that the robot falls short most of the time and then slowly crawls to the target at very low rpm.

10 was just an example value, I think we used something like a minimum rpm of 4. It would almost always settle within 5ish degree as the robot would be going too slowly to have enough inertia to overshoot by the time the loop cut.

I think I should phrase the topic’s question better. I was wondering if there are any concrete reasons where Ki would perform better than having the feedforward constant.

Both do the same job, ensuring that the output of the loop is high enough so that there isn’t steady state error.

Your technique is what I would call a minimum power (or speed) setting. It will work great in certain situations and it’s easy to understand and teach. Some students will come up with this on their own. The main drawback is that students might think that they don’t need to learn the I term of PID because this minimum power works better for their application. Also, the minimum setting is a problem for steady-state applications.

Let’s say you have an auton program where you are trying to drive (or turn) a robot to a target position, as quickly as possible. You’re not trying to hold it there, you just want to get there. Also, in this scenario, you are not going to backup if you overshoot the target, so you’ve got to get it on the first try.

With a normal P loop, as you get close to the target the power value will be too small to move the robot at all. The robot will just stop short and stay there. But if you increase the Kp it will overshoot.

If you are teaching PID and started with just the P term, then this might seem like a good opportunity to introduce the I term. However, when students encounter this issue and try and resolve it on their own, they will likely just increase the target by a small amount (set the target to 52 degrees, when they really want 50). But if you have them analyze the data as they are making the turn (the Datalog feature in RobotC was fantastic for this, I wish the V5 programs had something like it), they will see that the power value for the motor is being set to like 1 or 2, and that’s just not enough to move the robot. Having a minimum value for power is a simple solution in this scenario.

The integral term is way more complicated than having a minimum power setting. So if simple is better…?

The I term is really needed for applications that require a steady-state, like holding a lift at a certain position or driving straight. And in those situations, you do NOT want to have a minimum power setting, because if you are already on target then the minimum setting would move you away from the target.

9 Likes

Interesting topic you bring up @Gnash!

Just to summarize the previous posts, you are experiencing steady-state error and your implementation of a “fake Ki” is known as a feedforward constant.

Maybe a general answer to “integral or feedforward” is to note the pros and cons of their differences.

The main difference being: the integral term is reactive while a feedforward constant is proactive. The integral is calculated as the system is running, so any effects it has on the feedback loop would be considered reactive. Meanwhile, a feedforward term is determined either mathematically or experimentally before the action, making it proactive.

Pros and Cons of Reactive Control (Feedback Control)

In some VRC challenges, it can be widely unpredictable how much load the robot has. For example, during the ITZ season, a robot driving with no ( ~3 lb) mobile goal behaved differently than a robot with just one mobile goal or one with a full stack of cones. Now what happens if the mobile goal slipped out or the stack of cones got knocked over? A similar situation could be considered with Tower Takeover too. Using an integral term to correct the chassis movements would be beneficial since it could adapt to any number of those situations without specifying each and every case. With that being said, integral correction is not going to be perfect. Your integral may grow too slow, or it may accumulate too fast and result in an overshoot of the target. Some solutions to this may include setting a bound in which the integral is collected, reseting the integral if you pass the target, or limiting the maximum sum of the integral. In some cases, this may result in more time tuning than its worth. For that reason, @tabor473 just suggested that you retune the PD terms.

As @jrp62 mentions, feedback could be one way to hold something in place as it can determine how much power is needed.

Pros and Cons of Proactive Control (Feedforward Control)

If you have a consistent or predictable system, this is probably a quicker solution to implement. Unlike tuning a kI, this is more straightforward to determine. As mentioned above, you could experimentally determine the minimum speed to keep the system moving. However, this may not be the optimum solution for all situations. You could also use math to determine how much “holding power” is needed to counter act the force of gravity on an arm at different angles. (Try: hold a weight straight forward vs 15 degrees from your waist. Which is easier? What happens when you raise the weight past horizontal?) Another drawback with feedforward could be that you need a good approximation to begin with.

Based on your knowledge of the system you are working with, the best way to choose which approach you take is by weighing their advantages and disadvantages. Hope this gave you more insight! :smile:

11 Likes