Re: Tuning PID Constants Over a Range
 

Don't forget that you are tuning an electro-mechanical system.

For example if it is too hard to (begin) a turn then tuning the servo, by any means, is very difficult. This past year things like proper inflation of the pneumatic tires made all the difference (we were running Austin's state-space code).

An arm-like mechanism that takes much more power to move up than down is also very difficult to tune - so balance the motion against gravity with a gas shock or surgical tubing.

Set yourself up for success with good mechanical design, software can only do so much!

Re: Tuning PID Constants Over a Range
 

What software do people use to graph and plot data? I found some, such as mathplotlib, but I am wondering what other teams use.

Re: Tuning PID Constants Over a Range
 

We found success using a velocity PID loop on the roboRio, and in retrospect we should have run the velocity PID loop on the talon. The main issue we were trying to solve was left/right sides moving at different speeds when given the same input, which a motion profile would not solve alone.

Re: Tuning PID Constants Over a Range
 

We use matplotlib and some python scripts to parse and plot our data. We've also used gnuplot.

The trickier part is how to log data real-time. Most/all IO is not real-time. You can get away with writing data to a file from your control loop thread for quick tests, but that's risky for longer tests. (Sometimes when I'm really lazy, I'll stick the file IO operations in the main code, time them and abort if they take too long. This lets me least know if I'm getting bad data.) We queue up the data we want to write into a queue, and write it to disk in a separate thread. This unfortunately adds significant complexity.

Re: Tuning PID Constants Over a Range
 

Absolutely, P can compensate for that. But we also were using the same equation for path following so we wanted it to be in the ballpark.

Re: Tuning PID Constants Over a Range
 

We logged everything to csv and used gnuplot to view it.

Re: Tuning PID Constants Over a Range
 

Just want to point out that this is probably easier than you think to control - you can do feed forward by applying voltage proportional to the cosine of the angle of the arm to cancel out gravity, at which point it becomes a (approximately) linear system, that is fairly easy to control (Although there are still some considerations to be taken with the difference between going up and down). A FF + PID arm is much easier to control than one with surgical tubing or a gas shock, imo.

The point that programming can only do so much is definitely valid, I just wanted to point out that arms aren't too difficult, as that's what we spent our season doing :)

Re: Tuning PID Constants Over a Range
 

There's another compounding factor that isn't apparent here. The efficiency of a gearbox removes power regardless of if you are accelerating the arm or decelerating it. So, if you apply a torque at the motor to accelerate the arm, you will see a reduction in torque. If you apply torque at the motor to decelerate the arm, you will see an amplification of the motor torque. (Look at what conservation of energy says to verify) This year, for our shoulder joint, we had to gain schedule based on whether or not we were accelerating or decelerating to compensate for this. It took a couple weeks of hard work to figure that out.

In the end, yes, you can compensate for a lot of nonlinear junk in software, but the more you do in hardware, the better you are off. 971 robots move like they do both because the software lets them do that, but also because we go to great depths to do things like reduce backlash, reduce friction, increase stiffness, etc, to make it easier to write the software.

/end tangent...

Re: Tuning PID Constants Over a Range
 

Unfortunately, unlike motion profiling or simple PID, there isn't a nice way to do this on a Talon (right?).

Re: Tuning PID Constants Over a Range
 

Talon SRX closed loop control implements PIDF. The "F" stands for feedforward - and this works in all of the available closed-loop control modes (current, velocity, position, profile).

However, the feedforward gain is constant until you change it, so compensating for an arm by using a cosine function would require some form of gain scheduling. The Talon SRX Software Reference Manual talks at length about a couple of ways you could do this.

I also believe that you can hack the motion profile control mode to do what you want. This control mode is fundamentally position control plus a feedforward velocity (voltage) command for each trajectory point. There is no requirement that the integral of the feedforward velocities be equal to the subsequent position command. So you could calculate a profile to move your arm from any angle to any other angle, and account for gravity, spring assistance, or up/down asymmetry by manipulating the feedforward part of each trajectory point to provide a voltage disturbance in the desired direction.

Re: Tuning PID Constants Over a Range
 

A few questions (just started taking physics this year, apologizes if any of these questions have obvious answers that I haven't learned yet).

1. How did you determine the multiplier required to allow the arm to cancel out gravity?
2. How does multiplying by the cosine of the angle of the arm result in a linear system? Isn't cosine non-linear by definition?
3. Why do you not simple scale your voltage multiplier in proportion to the angle of the arm?

Thanks for all your help!

Re: Tuning PID Constants Over a Range
 

If you work out the physics, you'll get the following:

torque = J * angular_acceleration + r cross F_gravity

F_gravity cross r -> F_gravity * r * cos(theta)

So, you get

torque = J * d^2 (theta) /dt^2 + F_gravity * r * cos(theta)


When linearizing, you want to convert your system to be linear. The only nonlinear term above (assuming that torque is your input, which is a reasonable assumption for now) is the F_gravity * r * cos(theta). So, if we define

torque = torque_linear + F_gravity * r * cos(theta)

And then do a variable substitution, we get a linear system back. i.e.

torque_linear = J * d^2 (theta) /dt^2

Yay! (I think this answers 2 and 3).

As long as you aren't too far off, your system will work just fine with the wrong gain. One way to do it would be to measure the voltage required to hold your arm horizontal, and use that as the coefficient. We've traditionally ignored this term and let the rest of the loop take up the slack.

Re: Tuning PID Constants Over a Range
 

Austin is completely correct with his math AFAIK, but there's also an intuitive way to think about it: When your arm is at 90deg (straight up), you don't want to be applying any force to counter gravity - it can balance like that. However, when it's at 0 deg (flat on the robot), you want to be applying the maximum counter gravity force. cosine is 1 at 0deg and 0 at 90deg, so this makes sense.

The reason that cosine makes sense (to me) is that you can imagine the arm as a line on a circle, going from the centre to the edge. You can get the x position of the arm (which is what will determine the amount of force due to gravity) with the cosine of the angle of the pivot. This, I think, answers your 3rd question - it's because force of gravity doesn't scale linearly with the angle, it scales with the linear position of the centre of gravity of the arm.

Cosine is nonlinear, but because of the reasons above, (and what Austin mentioned, which is basically the same thing but with actual math behind it) it's in the system already - what we're applying just counteracts that, allowing us to ignore gravity (which makes the entire thing a linear system).

For your 1st question, we just did guess and check, IIRC :P You can also find it from the system dynamics (Weight/MOI of arm, force of gravity, and torque applied by motor), but you'll usually need to tune it anyways. It's also not a huge deal if you get it a bit wrong - the control loop can absorb a lot of it if needed.

Re: Tuning PID Constants Over a Range
 

We covered this in non-linear control theory. Take a model of your system, in this case angle vs. the force required to hold the arm in place and then invert it.

Mathematically, we describe it as this (provided I remember it correctly):
You have some system for which y = f(x) where x is you control signal.
There is another system for which g(f(x)) = x.
You can treat your system as a linear system if you use g(x) as your control signal.

Re: Tuning PID Constants Over a Range
 

Thanks for the advice! I spent my study period learning about how cross vectors worked and then went over a few of the concepts with my Physics teacher. I now have a good understanding of what's going on with the feedforward.
Two questions:
1. Shouldn't torque_linear = J* d^2(theta)/dt^2? *
2. Is the goal of the voltage scalar to be as close as possible to so that it becomes the non-linear part of the equation when multiplied by cosine(theta)?

*I start calculus next semester and have learned only the very basics from the edX class I have started taking to prepare for it (only 1 week in). Apologies if I am missing something obvious.