View Single Post
  #7   Spotlight this post!  
Unread 30-11-2013, 18:37
TravSatEE's Avatar
TravSatEE TravSatEE is offline
Spacecraft Engineer and more
FRC #2035 (Robo Rockin' Bots)
Team Role: Engineer
 
Join Date: Jan 2012
Rookie Year: 2002
Location: Monterey, CA
Posts: 26
TravSatEE is infamous around these partsTravSatEE is infamous around these parts
Re: Running pid loops in a separate thread.

Quote:
Originally Posted by Hypnotoad View Post
I was hoping to get a higher sampling rate so that I could arc the robot's path in autonomous if i need to.
If you are a high school student and considering trajectory-following control, good work!

Quote:
Originally Posted by Hypnotoad View Post
The way things are right now, PID does not work for moving setpoints.
This statement is vague and hard to assist without more information. How often are you changing the setpoint? My assumption is too often. A rule of thumb in control is 4-10X faster system convergence than control signal changes. Since you are limited to a ~200 Hz update rate, your setpoint should be updated only a few times a second.

To help you understand this more, I refer to the top figure on the PID Controller page. In a stable PID Controller design, the coefficients Kp, Ki, Kd are chosen ("tuned") for the system dynamics. In general most people just guess and check until something works.

When looking at that figure, what you are doing is changing r(t). This introduces new dynamics into the e(t) signal. Thus, the given set of Kp, Ki, Kd parameters may not lead to a stable controller (because they worked with the original dynamics, and not the combination of original and new). I think this is what you are experiencing based on the "PID does not work for moving setpoints" comment. In general, PID controllers do allow for changing set points (this is why that diagram shows r(t) as a function of time and not just a constant-value r). One way is to change the three coefficients, but in your use here this isn't desirable (you can explore this more in college).

Another approach is to change the nature of the dynamics added, by which I mean to change r(t) less often. Remember the first goal of a control system is stability, not time-optimal control. Thus, introducing changes to r(t) at a slower rate should help you maintain stability and allow for trajectory following.

If you still have more stability issues, then you can also try to slow down the motor speeds. I know this is less desirable to you than faster sampling, but as you prove to yourself you can do it at slower speeds, you might then try for to increase the speed later.
__________________
I have a doctoral degree in electrical engineering. My FIRST mentoring philosophy is to encourage student-led activities and create a level playing field among all teams. I believe this approach results in an exciting game, rather than emphasis on a handful of dominant teams.

FIRST FRC Teams that I have mentored: 612, 342, 2035, and 5104. FIRST FRC Teams that I have helped through build seasons: 4171, 4255, and 5171.
Reply With Quote