OCCRA
Go to Post A good robot can score a lot of points. A great robot can do it when the other alliance does everything they can to stop it. - Rick TYler [more]
Home
Go Back   Chief Delphi > CD-Media > White Papers
CD-Events   CD-Media   CD-Spy   FRC-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

photos

papers

everything



Team 1114 Controls and Programming Overview 2012

By: Michael DiRamio
New: 05-15-2012 09:35 AM
Updated: 05-15-2012 09:35 AM
Total downloads: 1022 times


This document was put together by the Controls and Programming subteam as an overview of the different elements of our controls this year.

Overview of Team 1114 Controls and Programming for the 2012 competition.

Attached Files

  • pdf FRC1114 Controls 2012.pdf

    FRC1114 Controls 2012.pdf

    downloaddownload file

    uploaded: 05-15-2012 09:35 AM
    filetype: pdf
    filesize: 813.98kb
    downloads: 1020



Recent Downloaders

Discussion

view entire thread

Reply

05-15-2012 10:43 AM

Michael Blake


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Michael DiRamio View Post
Thread created automatically to discuss a document in CD-Media.

Team 1114 Controls and Programming Overview 2012 by Michael DiRamio
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...



05-15-2012 11:15 AM

JamesTerm


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Michael DiRamio View Post
Thread created automatically to discuss a document in CD-Media.

Team 1114 Controls and Programming Overview 2012 by Michael DiRamio
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.



05-15-2012 12:26 PM

Ether


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by JamesTerm View Post
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.

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.




05-15-2012 12:36 PM

Michael DiRamio


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by JamesTerm View Post
I hope someone would be kind enough to explain how you made the equations for the linearizaton of the victor.
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.



05-15-2012 12:44 PM

Hjelstrom


Unread 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!



05-15-2012 12:51 PM

Ether


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Michael DiRamio View Post
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.
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.




05-15-2012 01:03 PM

Q-Tip


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Hjelstrom View Post
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 get "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!
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.



05-15-2012 01:37 PM

JamesTerm


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Ether View Post
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.

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?



05-15-2012 01:43 PM

Ether


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Ether View Post
You can do curve fitting in Excel (or OpenOffice or LibreOffice) using the "trendline" function.

See this Excel spreadsheet.
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]




05-15-2012 05:17 PM

slijin


Unread 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.



05-15-2012 05:36 PM

MichaelBick


Unread 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?



05-15-2012 05:50 PM

JamesTerm


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by MICHAELABICK View Post
Why would you want to reduce the d constant of PID in certain circumstances for speed PID?
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.



05-15-2012 06:38 PM

Ether


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by slijin View Post
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.
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.




05-15-2012 09:00 PM

Ether


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by JamesTerm View Post
does the work load impact the kind of curve you will have?
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 data1 they'd be willing to share?


1 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.



07-17-2012 03:00 PM

JamesTerm


Unread Re: paper: Team 1114 Controls and Programming Overview 2012

Quote:
Originally Posted by Ether View Post
For the Vic, I believe the answer is "yes" (and perhaps significantly) but I have no data to confirm that.

Does anyone have such data1 they'd be willing to share?
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.



07-23-2012 06:28 PM

JamesTerm


Unread 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.



view entire thread

Reply

Tags

loading ...



All times are GMT -5. The time now is 07:12 AM.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi