paper: Optimization and Analysis of Drivetrain Movement

[ThaddeusMaximus]

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

Optimization and Analysis of Drivetrain Movement (http://www.chiefdelphi.com/media/papers/3193?) by ThaddeusMaximus

[apalrd]

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.

[ThaddeusMaximus]

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.

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. :P This originally started as a "can this be done?" project.

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.

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.

[apalrd]

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

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.

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

[Rob Stehlik]

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/

[RyanCahoon]

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.

Thanks very much for posting that spreadsheet - I've been using it a lot the last couple of years. I made a version (http://www.chiefdelphi.com/media/papers/3195) with a more updated version of the JVN calc, in case anyone finds it useful.

[ThaddeusMaximus]

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/

Done. :)

[tomer]

This is AMAZING.

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

[Mr. Lim]

Super cool.

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)

[ThaddeusMaximus]

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)

If teams are looking for a good freeware alternative, SageMath is good. Not as pretty but it's a nice suite of tools that works.

https://cloud.sagemath.com/

We wrote equivalent code in it.

[Ether]

If teams are looking for a good freeware alternative, SageMath is good.

I use Maxima (http://maxima.sourceforge.net/). Recommended for symbolic work.

GNU Octave (https://www.gnu.org/software/octave/) is great for numerical work and linear algebra.