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

Optimization and Analysis of Drivetrain Movement by: ThaddeusMaximus

_Gear ratio selection is typically based upon theoretical top speeds or pushing power, but oftentimes, this isn’t the criterion, and is a poor model for actual events. Sprint distance can play a much bigger factor for agile defense.

In this, we’ll take a look at how to optimize based on reaching a certain point first, rather than being as “fast” as possible._

In the High Level Overview, basic facts about motor curves and limitations of our models are brushed over.

In the maple sheet, I use differential equations to model the velocity and distance travelled of a typical FRC robot as a function of time and gear ratio. This will then allow me to target a specific “sprint” distance, solve for required time, and find the gear ratio which reaches this distance in minimal time.

I really like that sprint-distance analysis is getting more ‘light’ in FRC. It’s a way better metric for drivetrain performance than ‘81% adjusted speed’ that a lot of CDers throw out during discussions.

To avoid differential equations, I’ve solved the physics equations in Excel iteratively (with a time-step of e.g. 0.01s and each slice of time on a new line). then I can also plot the curve of all of the variables in Excel. This is also easier to distribute to students in FRC.

What you don’t go into detail on is how you determine what the sprint-distance you analyze to is. This all comes down to robot strategy, but it’s really really important to get this right when you analyze the gear ratios in this way. It’s all too easy to say the distance is 27’ or 50’ when really 10’ or 15’ is more appropriate for the game.

Yes, you can indeed solve DEs numerically in that fashion, but it’s hard to truly “optimize”; you’ve gotta trial-error it in every step (which, could be done, but processing power).

Also, some of my (very ambitious sophmore) students versed in calculus rather enjoyed seeing the relationship ( the (1-e^-t) curve) that goes on, which kinda vanishes when you do it discretely. This originally started as a “can this be done?” project.

Yeah, this is arbitrary and pretty much just a flexible solution. It’s something we’re a bit new to, maybe someone else has better insight. I remember 610 saying something about how they optimized with sprint distance in mind in 2013.

This is true, your approach actually optimizes the gear ratio while mine does that manually. I do like that it can solve for gear ratio instead of just sprint time to distance.

This is probably worth of an entire separate paper or more, but I don’t think it has been discussed much on CD.

33 optimized with sprint distance in mind in 2013 and 2014 as well, based on analysis I did post-season of our 2012 robot where we did not optimize to sprint. I eventually concluded that a short-spread shifter was a good thing in FRC (1.8:1 or so between gears), rather than the wide-spread shifters currently used (e.g. 2.54:1 and 4:1 AM shifters) because of sprint distance reasons at moderate distances vs full field distances.

This is really neat stuff. My calculus is very rusty, but using a theoretical model to optimize gear ratios has potential to be very effective. I don’t have or know how to use Maple though. Would it be possible for you to embed controls to vary the parameters and make it available using the Maple viewer? http://www.maplesoft.com/products/maple/Mapleplayer/

Thanks very much for posting that spreadsheet - I’ve been using it a lot the last couple of years. I made a version with a more updated version of the JVN calc, in case anyone finds it useful.

Ever since I heared the term Spring distance I tried to figure out how can I calculate it and optimize it when designing a drive train, I tried some calculus and didn’t reach anything meaningful, and we didn’t have a ME mentor available to assist me…

So early in the morning of Kickoff, I find this. Thank you!!

One thing we’ve struggled to model using the existing resources on CD is the optimal sprint taking into account decelerating to a stop at the end of the sprint. More often than not, your robot needs to be at a complete stop at the end of sprint, not blow past it at top speed.

Much of what we’ve done is anecdotal to try and take this into account - shortening the sprint distance by artificial amounts until it “felt” right. Different games have different characteristics - sometimes you need to slow down smoothly at the end of your sprint because it requires precise alignment. Other times you can practically hit something full-speed at the end of your sprint. I doubt you could effectively model the deceleration component as a result, but it would be cool to see.

Really inspiring work here. I remember I modeled optimal gear ratios for a robot that needed to drive up an incline without losing speed as a high school student in grade 11, using Maple for the very first time. I definitely didn’t use ODEs back then… but Maple is a great tool.

(Insert blatant plug for a Canadian / University of Waterloo product)

Im trying to find the optomized gear ratio for sprint distance in (Maple player) the first time i tried it worked and gave me a result,but everytime after it seems to give me an error saying “Unrecognized function “Display” where PLOT DAG expected” has anyone else encountered this issue or know how to resolve it?

I made a spreadsheet that numerically integrates the differential equation using Euler’s method. It also will handle continuously variable transmission (CVT) drive trains with the assumption that the current gear ratio is always the optimal one. Using it I got the following results:

If anyone wants the spreadsheet PM me or post and I will make a new thread with it.

I’ve done a similar Euler simulations in Matlab, including traction and voltage sag. This comment makes we want to go to add in deceleration as well. Maybe publish up some analysis here. What I found most interesting however was how much voltage sag limited the acceleration of a 6 CIM drivetrain. The graph above shows the same 130 lb robot with 4 inch wheels at 6 cims v.s. 4 cims to complete a 30 foot sprint.

This seems pretty cool! Lots of big words and spreadsheet equations that seem super helpful. Could someone please explain on a basic level how this stuff works and how we could use it to benefit our drivetrain designs?

posistion = posistion + v*timeStep;
rpm = 60*v*gearRatio/(wheelDiameter*3.14/12);
torque = cims * (28.58-.00539*rpm)/16;
force=.80*torque*gearRatio/(wheelDiameter/2);
force=min(force,traction);
amps = cims*(133-rpm*.0246);
voltage = 13-amps*resistance;
force = force*voltage/13;
a = force/mass;
v = v+(a*timeStep);
t = t+timeStep;

Basically I use a linear approximation of amperage multiplied by the system resistance (which should include the batteries internal resistance and the resistance of all components outside the motor). I found .10 ohms worked well for resistance, but that’s a bit of a fudge. In reality the system resistance is probably around .20 ohms, but 6 cims at maximum amperage would drop the voltage to 0 at that value. In reality there’s some transient effects from the system inductance and capacitance that I’m not modeling here.

Once I have amperage and resistance I calculate the voltage drop (V=IR) and subtract it from the fully charged battery voltage (around 13 volts). Using the the voltage at any time divided by the nominal voltage I’m modeling approximately what percentage of nominal torque the motor would produce under voltage sag. This is mainly to deal with the discrepancy between motor testing, which is done with a fixed voltage power supply, and motors on a robot, which receive variable voltage as the battery is loaded more heavily.

Traction is just (robot massgravitycoefficient of friction). Anytime the robot is pushing harder than traction allows the model just lowers the value of force to be equal to traction. This part of the model has a very limited effect because FRC robots are not traction limited for any significant amount of time while accelerating.

Here you will find full C source code, pre-compiled ready-to-run Win32 table-driven console executable, how to do second-order numerical simulation (Heun’s Method) instead of Euler, and documentation explaining traction and voltage sag.