Team 610 pre-season drivetrain

[Kernaghan]

Originally Posted by JohnFogarty

Where do you buy your 1x4 tubing?

You can get it here, stock number is T34118

[waialua359]

Originally Posted by Rob Stehlik

I doubt it. In my opinion, two speed transmissions are silly and largely unnecessary. In most robot games, the vast majority of your movements will be short sprints from game piece to goal, and avoiding other robots in between. This calls for acceleration, not a high top speed. Slower is faster.

Over the years based on our experiences, I find this very true.
However, when we had our software controlled auto transmission in a previous year, we found that to be highly effective......except we scrapped it when our roll pin from the dog gear went sour in matches. We didnt last an entire tournament without having issues with it.

The first time I saw shifting was 2001 (I think) at the SVR regional when 254 used low gear shifting to balance on the bridge much easier. It was very quick that year. EJ drove......maybe he can comment if it was worth it.

[DampRobot]

Originally Posted by waialua359

Over the years based on our experiences, I find this very true.
However, when we had our software controlled auto transmission in a previous year, we found that to be highly effective......except we scrapped it when our roll pin from the dog gear went sour in matches. We didnt last an entire tournament without having issues with it.

The first time I saw shifting was 2001 (I think) at the SVR regional when 254 used low gear shifting to balance on the bridge much easier. It was very quick that year. EJ drove......maybe he can comment if it was worth it.

I'm kinda lolling at the thought of EJ driving a robot in a FRC competition.

I used to share this thought, but have found through experience that the idea that slower top speed=faster isn't necessarily true. My current belief is that you should optimize your acceleration by reducing the mass of the robot as much as possible, and as a last resort, adding more power. Limiting your top speed to improve your acceleration is a risky proposition at best. We geared our robot too low in 2012 (where conventional wisdom would say that you needed acceleration a lot more than speed), and we really found it limited our performance. Sure, we accelerated quick, but it took forever to go anywhere.

This offseason, we played with an approximately 90lb bot (not including bat and bumpers), and geared to go around 18fps with a WCP DS. Simply put, the acceleration and speed were fantastic, even compared to a bot only 30lbs heavier. 18fps adjusted was a good speed for short runs around defense too. We got heavy d played on us all through quals, and we only really started shifting in elims. That robot flew, and it was because it was light and we geared really fast.

My opinion tends to be that for robots with a decent center of gravity, speeds of 16+fps are reasonable for most games (with a shifter). Of course, others have different well supported ideas about the "best" top speed.

[MichaelBick]

Originally Posted by DampRobot

I'm kinda lolling at the thought of EJ driving a robot in a FRC competition.

I used to share this thought, but have found through experience that the idea that slower top speed=faster isn't necessarily true. My current belief is that you should optimize your acceleration by reducing the mass of the robot as much as possible, and as a last resort, adding more power. Limiting your top speed to improve your acceleration is a risky proposition at best. We geared our robot too low in 2012 (where conventional wisdom would say that you needed acceleration a lot more than speed), and we really found it limited our performance. Sure, we accelerated quick, but it took forever to go anywhere.

This offseason, we played with an approximately 90lb bot (not including bat and bumpers), and geared to go around 18fps with a WCP DS. Simply put, the acceleration and speed were fantastic, even compared to a bot only 30lbs heavier. 18fps adjusted was a good speed for short runs around defense too. We got heavy d played on us all through quals, and we only really started shifting in elims. That robot flew, and it was because it was light and we geared really fast.

My opinion tends to be that for robots with a decent center of gravity, speeds of 16+fps are reasonable for most games (with a shifter). Of course, others have different well supported ideas about the "best" top speed.

I agree with this thought. 6 motors is just so easy now, especially if they keep even half of the motors available. If you have the motors I see little reason in not going 6 motor drive.

[DampRobot]

Originally Posted by MichaelBick

I agree with this thought. 6 motors is just so easy now, especially if they keep even half of the motors available. If you have the motors I see little reason in not going 6 motor drive.

Tripping the main breaker is a serious concern with a 6 CIM drive.

Originally Posted by MichaelBick

I agree with this thought. 6 motors is just so easy now, especially if they keep even half of the motors available. If you have the motors I see little reason in not going 6 motor drive.

Michael, Damp's argument is that he'd rather shift on a light bot than add more motors to the drive.

[MichaelBick]

Originally Posted by Andrew Lawrence

Michael, Damp's argument is that he'd rather shift on a light bot than add more motors to the drive.

Ok, I misunderstood. Regardless, 6 CIMs is overkill unless you are running a PTO. Otherwise I would max out at 4 CIM + 2 Mini CIM.

[cadandcookies]

Perhaps this discussion of acceleration versus top speed should be split off...

Regarding top speed versus acceleration, I think it's important to remember what (I believe it was BJC) said in a whitepaper: the goal of a drive train is to get you where you need to be, when you need to get there. To that end, I'd focus on time to go a given distance: a very nice calculator for this can be found here, which was written up by Andrew Schreiber (based on the drive train acceleration model, which Ether provides a link to in the next post). It's a little bit out of date but it's good for giving reasonably accurate numbers.

Other than that, it's all about team preference. Obviously there's some math behind it (if it's going to take you longer than 25 feet or so to reach your top speed, it probably isn't worth it), but nothing that hasn't already been mentioned elsewhere.

[Ether]

Originally Posted by cadandcookies

I'd focus on time to go a given distance: a very nice calculator for this can be found here.

That calculator was written by Andrew Schreiber¹, and was based on an early version (now superseded) of the Drivetrain Acceleration Model².

The model was updated a few days later to correct a small error and include the effects of reduced motor voltage caused by circuit resistance³. Andrew's calculator has not yet been updated to reflect the updated model.

Full C source code² is provided for the Model. All you need is a C compiler and you can change the parameters, compile, and run it. Compiling and running takes less than 2 seconds. The output is a CSV file which will open directly in Excel if you set file associations. Columns in the CSV file include time, distance, speed, acceleration, motor current, and motor voltage.

¹ See post#13 in this thread http://www.chiefdelphi.com/forums/sh...d.php?t=119442

² http://www.chiefdelphi.com/media/papers/2868

³ See post#23 in this thread: http://www.chiefdelphi.com/forums/sh...d.php?t=119442

[cadandcookies]

Originally Posted by Ether

That calculator was written by Andrew Schreiber¹, and was based on an early version (now superseded) of the Drivetrain Acceleration Model².

The model was updated a few days later to correct a small error and include the effects of reduced motor voltage caused by circuit resistance³. Andrew's calculator has not yet been updated to reflect the updated model.

Full C source code² is provided for the Model. All you need is a C compiler and you can change the parameters, compile, and run it. Compiling and running takes less than 2 seconds. The output is a CSV file which will open directly in Excel if you set file associations. Columns in the CSV file include time, distance, speed, acceleration, motor current, and motor voltage.

¹ See post#13 in this thread http://www.chiefdelphi.com/forums/sh...d.php?t=119442

² http://www.chiefdelphi.com/media/papers/2868

³ See post#23 in this thread: http://www.chiefdelphi.com/forums/sh...d.php?t=119442

Sorry, I didn't mean to post that without credit. I've edited my post to reflect the information you've presented.

At this point that model is something that I use quite often for getting a reasonable estimate of time to a given distance, and it just sort of permanently hangs out in my "Useful FRC tabs" bookmarks group. In the future I'll be using the up to date source code for critical applications.

[Ether]

Originally Posted by cadandcookies

At this point that model is something that I use quite often for getting a reasonable estimate of time to a given distance, and it just sort of permanently hangs out in my "Useful FRC tabs" bookmarks group. In the future I'll be using the up to date source code for critical applications.

Just remember the old adage "Garbage in, garbage out". The model is only as good as the parameters you use: the more difficult ones being the constant, speed-dependent, and torque-dependent drivetrain losses (Kro, Krv, Kf); and the circuit resistances (Rcom and Rone).

[cadandcookies]

Originally Posted by Ether

Just remember the old adage "Garbage in, garbage out". The model is only as good as the parameters you use: the more difficult ones being the constant, speed-dependent, and torque-dependent drivetrain losses (Kro, Krv, Kf); and the circuit resistances (Rcom and Rone).

Unfortunately I have yet to find an online C compiler that will give me the output csv file, so for back of the napkin calculations it will have to do.

[Ether]

I did not fully appreciate how much of an obstacle the need for a C compiler would be.

For those who do not have, or do not care to install, a C compiler, I will look into posting a compiled executable that grabs the parameter values from the environment.

[Mr. Lim]

http://youtu.be/lQLp_F88CEg

We had a chance to take the drivetrain for a spin last night. We rang out the encoders and gyro, and all seems to be in good shape.

Our driver for the upcoming 2013-2014 season had his first crack at driving it around, and the initial feedback is very positive.

[BrendanB]

Originally Posted by Mr. Lim

http://youtu.be/lQLp_F88CEg

We had a chance to take the drivetrain for a spin last night. We rang out the encoders and gyro, and all seems to be in good shape.

Our driver for the upcoming 2013-2014 season had his first crack at driving it around, and the initial feedback is very positive.

Wrong video? The cars are pretty sweet though!