I’m curious about how different teams have implemented a two speed drivetrain. I can see a few scenarios:
Just curious. What has your team done and how well did it work?
Most teams do manual shifting, as completely automatic shifting isn’t a trivial task.
I know all the shifting teams out here on the west coast manually shift (but rarely leave high gear).
Poorly done autoshifting will be a detriment to performance.
33 is the only team I know of in recent time that has automated it.
The teams that I have seen implement shifting transmissions have always shifted manually. They had one gear that they used for ordinary driving (they averaged speeds only slightly faster than stock Toughbox transmissions). The other gear they used in pushing matches. Everyone that I saw shifted manually.
The main reason for shifting manually would be to avoid gear hunting (similar to when your in an automatic car and going around corners at about 10 mph, it jerks around a lot because it can’t decide which gear is the best). Super shifters also take time to shift, so you only wan’t to shift when you need to.
SparX (FRC #1126) have used three and four speed automatic shifting transmissions in previous years with great success. We found that, with the right programming, they automation can be highly successful and give the drive team one less thing to worry about. See the links below for details:
2005: Three Speed Automatic
Robot / Transmission
2006: Three Speed Automatic
Robot Video / Transmission Similar to 2005
2007: Four Speed Automatic
Robot / Transmission
Same goes with 1124 out here in CT. We thought about automatic shitfting, but decided it wouldn’t be practical, since 1) we don’t use low gear that often and 2) it’s too much work on my end (programming it) for too little gain.
We did a hybrid this year.
-We had enough power to just stay in high gear most of the time.
-We had no gear hunting at any point, due to filtering and hysteresis. The algorithm is very good, and factors in everything we really wanted.
-There are three cases in which we shift:
*We are accelerating at a rate greater than a tuned parameter, the throttles are above ~80%, and we are above a threshold speed (~4 ft/sec) (shift UP)
*We are decelerating rapidly, the throttles are above ~75%, and we are below a threshold speed (~8 ft/sec)(shift DOWN) - This case handles collisions with other robots/defenders where we want to push
*We are below a threshold speed (~2 ft/sec) and the throttles are low (shift DOWN)
-We also look at:
*IF a shift has happened (automatically or manually) in the last 500ms
*The difference between the sticks (We don’t want to shift while turning).
We ended up enabling the first case and disabling the second and third. We autoshift up, and the driver toggles a downshift by pressing a button (holding the button locks it in low). We almost never downshift.
With halo/cheesy drive becoming popular, a lot of these cases can be better described without complex logic, as there is less question about if the driver is turning or driving straight. Also, with more power in the drivetrain, the need to shift down to accelerate is almost gone, so the only reason to shift down is to push hard.
We (1024) used auto-shifting successfully this year.
We used super-shifters. I’m fairly certain that they were modified somehow, but I’m not sure.
Anyway, about the programming:
I set a threshold to shift up (4 ft/s), and a threshold to shift down (3 ft/s). The purpose of having 2 different thresholds was to avoid flickering if we were driving right about at the threshold.
To handle any static/outliers (which were a problem) I took an average of the last 10 readings on a 20ms interval.
Now, I was taking these readings on both the left and the right side. At different times I used either
abs((left+right)/2) (average)
max(abs(left),abs(right)) (maximum)
The average has the advantage that it implicitly handles the condition of turning; since the signs of each are switched they average to something close to 0.
However, early in the season we had problems with one of the encoders failing, dragging the average down, and keeping the bot in low gear. So I took the maximum of the two.
Now, I also had buttons for the driver to force low, or force high. They were used, but most of the time the autoshifter did the right thing.
Code:
I know 1618’s two shifting robots (2007 and 2008) were manual-shift–low gear was generally reserved for pushing. If 2815’s 2010 robot shifted automatically, it’s news to me.
Our drive team traditionally prefers to drive in one gear where the game and robot role define the preferred “normal speed” and they have the alternate ratio available should they need it.
Some years the robot has been driven in “high” the majority of the match and “low” as needed to push or climb.
We used supershifters shifted manually and stayed in high gear for most of the match switching to low gear when pushing and picking up tubes.
Team 116 had an automatic shift built into the system early this season. We used supershifters and shifted based on the motor performance curves. But, we found that the shifting would catch the drivers by surprise and resulted in running into the wall a couple of times at high speed. So, we switched to manual selected by the fire trigger button on one of the joysticks.
But, we found that even with that modification, we never had a need to shift. There were so many robots and game pieces on the field that we really didn’t need the high speed gearing. And, there wasn’t much need for a pushing match either because of all of the penalties for incidental contact or zone incursion. So, for this game at least, all of the effort and weight for implementing a shifting drive train seems to have been for naught.
We (1771) used 2 speed automatic transmission in the 2011 game. We had no trouble with it “gear hunting” due to hysteresis.
At first we thought “Oh, let’s just do manual…”, then we tested automatic. We never went back.