paper: Team 1114 Controls and Programming Overview 2012
 

Thread created automatically to discuss a document in CD-Media.

Team 1114 Controls and Programming Overview 2012 by Michael DiRamio

Re: paper: Team 1114 Controls and Programming Overview 2012
 

WOW. THANKS for sharing this!

We'll review with our team on Friday, see if we can create a punch-list to add functionality to our bot and enhance our capabilities/skills since we're competing through November.

GOOD STUFF here...

Re: paper: Team 1114 Controls and Programming Overview 2012
 

This is awesome!! I hope someone would be kind enough to explain how you made the equations for the linearizaton of the victor. I mean sure I could use this, but I'd rather know how to do something like this as I've needed to do it in the past professionally and had to use wxMaxima to hammer out something close. I've googled around, but I just haven't found anything that spells it out step by step (e.g. curve fitting). I was going to hit Ether up on this in his equations, but I'm here now. :)

Re: paper: Team 1114 Controls and Programming Overview 2012
 

You can do curve fitting in Excel (or OpenOffice or LibreOffice) using the "trendline" function.

See this Excel spreadsheet.

Chart 1 shows the test data (A1:B20) plotted with the joystick command on the X axis and the actual Vic output on the Y axis.

Chart 2 is the inverse of Chart 1 and shows the actual Vic output on the X axis and the joystick command on the Y axis.

Chart 3 shows a 3rd degree polynomial trendline added to Chart 2. The polynomial can be used to linearize the Vic's output.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

We did this fairly quickly this year after getting frustrated with the shooter speed control. This summer we hope to generate a more accurate function.

We started by plotting programming output vs victor voltage output (as well as programming output vs shooter speed) and used this to come up with a curve of best fit for the victor output.

We then used Mathematica to generate the inverse of this function. It was pretty ugly so we hacked it a bit by plotting the values from 0 - 1 and then finding a curve of best fit for this (which became the linearization function).

There's definitely a lot of room for improvement/higher accuracy in the function, but we found this linearization made a HUGE difference in the performance of our PID loops.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Did you end up using the software "base lock" when on the bridge? We have a feature like this but only used it on the field because if the wheels slip, the PID controller would then "correct" and end up driving the robot the opposite way off the bridge. Maybe your rubber wheels don't slip on the bridge though!

Nice job!

Re: paper: Team 1114 Controls and Programming Overview 2012
 

If you plot your data so that the joystick command is on the Y axis, and the actual Vic output is on the X axis, then you don't need to invert anything analytically. It's already inverted. All you have to do is fit the trendline and you've got your linearization function. See the Excel file link in my previous post in this thread.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Yes, we did use base lock on the bridge. The two main situations that base lock was used were when we were waiting for a balancing partner to climb on and when we were close to balanced and used fine adjustment on the base lock.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Thanks for this response and so I want to flash back to this one:
http://www.chiefdelphi.com/forums/at...d=13215692 33

The curve is similar to this one you posted, but just a bit more curvy at the end. Should this process of working out the curve be custom for any given rotary system? It seems like I could use any of these equations and they would be in the ball park, but I'd probably want to go through these steps on each robot, and each closed loop rotary system because of other properties like model of victor and the work load that it is controlling. Well that is really the question, does the work load impact the kind of curve you will have? Are there other factors which may contribute to the curve being different from one robot/rotary system to the next, and if so, is it significant enough to be worth the effort?

Re: paper: Team 1114 Controls and Programming Overview 2012
 

If the model you want to fit is not supported by "trendline" -- for example you think y=p1+p2/(x-p3) might fit the data better than, say, a polynomial -- you can create and fit your own model using Tools|Solver as shown in this spreadsheet.


[edit1]
Hat tip to Joe Ross: In Excel, cell E1 can be coded directly as sumxmy2(B1:B20,C1:C20) instead of creating cells D1:D20 (if a least-squares fit objective function is desired).
[/edit1]]

[edit2]
Note that not only the model but also the objective function is user-configurable using the tools|solver modeling technique. For example, suppose that instead of minimizing the sum of the squares of the model errors (least squares fit) you want to find the parameters which produce the minimum maximum absolute error. This is easily accomplished by making cells D1:D20 equal to the absolute model error (for each data point), and making cell E1 equal to the maximum of cells D:D20. Then use tools|solver to minimize cell E1. Note: this does not work well (or at all) in Excel because of the algorithms used; and in OpenOffice takes several minutes (instead of seconds) but does find a solution. For the spreadsheet linked in this post, OO3.3 found the following solution for minimum maximum error: y = -0.2651 -0.419013/(x-1.3281551). Here's a graph of the solution. The solid black line is the raw data. The dashed black line is the inverted data. The solid red line is the linearization function, which uses only 2 adds and 1 divide.
[/edit2]

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Wow, thanks for this!

Could you also post the data you used to develop your linearization code? I'd like to compare it to other data I've found around.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Why would you want to reduce the d constant of PID in certain circumstances for speed PID?

Re: paper: Team 1114 Controls and Programming Overview 2012
 

I presume this was the
"Different from standard PID control. Instead of the PID calculation setting
the output, the PID calculation is an adjustment to the output
o output = output + calcPID(currentSpeed)
"
?

But if I had to guess, I know that (at least for our power wheel)... the more momentum and kinetic energy built up on higher speeds the less P is needed... but I cannot see yet how that equates to D except that if D is too high it will reverse oscillate. We too had to use a large D though. This attachment is P=4 and D=7. Where magenta is the predicted velocity, Cyan is the encoder velocity, green is the voltage, and yellow is the PID in action.

I'm still trying to master PID... I'd love to get it down to a 2 radian per second tolerance like 1114 has done! We are around 20 radians tolerance.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Your post was linked to my post, so I assume you were asking me?

If that is the case, the Victor calibration data I used came from the 1114's paper (the subject of this thread), on page 3 (the red dots). Is that what you were asking? If so, the data is in the spreadsheets in cells A1:B20.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

For the Vic, I believe the answer is "yes" (and perhaps significantly) but I have no data to confirm that.

If I am right (that the variation of the Vic's "effective % of full scale output vs input command" curve varies significantly with working load), then it wouldn't make much sense to worry too much about getting the "linearization function" exactly right when the load varies greatly.

Does anyone have such data¹ they'd be willing to share?


¹ e.g. with a motor connected to the Vic: no-load motor speed vs input command to the Vic, and stalled motor torque vs input command to the Vic. Of course the data for the "stalled motor" curve would have to be limited to small inputs.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

I'm not going to be able to address the example directly with the no load motor speed, but I can share something that could be an interesting test to see.

As of today I've deployed the simbotics curve equations for the Admiral II for preliminary testing... I'll post back some gif's... it will be interesting to see how well they work. I've made a list of procedures of what I'll be doing here:

http://www.termstech.com/articles/Li...procedure.html

Comments, corrections... are welcome as this is new ground for me.

On the first point in the procedures I'll make a somewhat steady state graph... I can slow the rate down enough or we can get fixed point measurements as well. One of the graphs will apply the simbotics curve and then we can see how linear the line will become with it applied. I'm hoping to get these made and tested next week.

Re: paper: Team 1114 Controls and Programming Overview 2012
 

Here is
3.1199*x^4 + -4.4664*x^3 + t2=2.2378*x^2 + 0.1222*x

when it is placed against
0.7134*x^3 + -2.2091*x^2 + 2.4878*x

Green show the voltage applied using the simbots equations
Magenta is the linear line we'd like to see in velocity (please ignore the skip at the beginning... that is a key pressing artifact in the simulation)

Cyan is a simulated encoder, emulating the victor equation that is listed on the simbotics pdf.

It is interesting to see how well they line up, but they are not perfect... I'm interested in how this inverse equation was made given the original equation.