As my team moves into our sophomore year, we decided to implement a two speed drive system. We are using Super Shifter kits from AndyMark.
Through our driving tests, we have ran into some funky results in terms of consistency of the shifts. We boosted the quality of the programming, yet we are slightly worried about massive wear and tear. My team is looking for people’s opinions on the following:
What is optimal speed for a smooth shift up a gear?
What is optimal speed for a smooth shift down a gear?
Turning while shifting?
Would an automatic transmission be effective?
We are using pneumatics, and are very thankful because we found out that even pneumatics have a very hard time shifting under a large load (pushing another robot w/non-mecanum wheels).
There are very few teams who autoshift well. Very very very few. Some try it, most implementations are quite poor, it requires a LOT of calibrations to be perfect for it to actually make a difference. In fact, in simulation, a shift time of a few hundred ms is enough to make auto upshift on accel not worth it from a performance perspective (it is still good from an energy analysis perspective).
-When we previously ran shift schedulers (and we looked at the design of Chrysler automatic transmission software and talked to experts on this way way back when we started auto shifting), we would upshift rather low, around 60-75% of the top speed in that gear, due to the time it takes to shift.
-We ran several different downshift points based on throttles, anywhere from 8fps (higher than the ‘redline’ in low) to 2fps. The high speed downshifts were triggered by decelration (‘kickdown’ shift for torque), and the low speed downshifts were triggered by low speed (‘coastdown’ shift to prepare for a future launch).
-If you graph your acceleration curves vs velocity, you will see a clear point where it is better to accelerate in high vs low. If you look at the velocity of that point, then set the upshift point 1fps or so lower, it is pretty close to the optimal shift point.
-We never do an upshift unless the throttles are relatively high, we never do a coastdown unless the throttles are low, and we never do a kickdown unless the throttles are high.
-We never shift when turning
-We never autoshift less than 500ms after any shift (auto or manual).
Usually, for FRC shifts with dog or ball shifters, as there aren’t any wear parts and a dog failure is unlikely, we do not attempt any torque drop during a shift. Servo shifters do require it for power on shifts, but pneumatics do not.
auto shifting was easy with the super shifter when shifting at 60 psi.
just use hysteresis. average the speed between your 2 sides of the drivetrain.
shift up about 1-2 m/s slower then your low gear top speed and shift down 2m/s slower than your up shift set point. i have had 4 years experience with it. after a driver try’s it he will demand it every year.
there was no noticeable delay when it shifted.
you must use 60 psi pneumatics for this to work, if you turn down your shift pressure there will be delays when shifting under load
What do you mean by funky? Is there a strange noise? Is there visible damage? Does your robot veer to one side when shifting?
To get a smooth shift, decrease power to the motors for an upshift and increase for a downshift. This is generalized, but it will get the gearbox’s input and output speeds to match and cause less jerk.
Turning during a shift can cause your gearboxes to engage differently and cause the robot to veer to one direction.
I don’t have any experience with autoshift in FRC, but some teams do it well.
I’ll point you to this post I made a number of years ago. For clarification, it was orginally for a 4 speed automatic transmisstion, but the process works just as well for a 2 speed. The time for the reduced power is approximately 50-75 ms. We also run the air pressure around 30 psi.
i should also say that we had to switch to vexpro ball shifters after andymark changed to screws instead of the roll pin due to shifting at 60 psi we kept breaking screws but 60 psi shifting is worth no delay.
OP, I think to find optimal shift points you’ll have to do a little math to figure out what works best for your particular robot and goals. Providing more details would be great.
In our first attempt at automatic shifting we are utilizing a shift table scheme. A CSV file is loaded onto the robot representing a shift table with throttle position on one axis and speed of the robot on another axis. The robot code automatically sets the actual throttle position and speed values based on how many rows/columns are in the CSV file and based on a ‘max shift table speed’ variable, namely just above the fastest speed 1st gear can reach.
A representation of what our table looks like. We haven’t set actual values (or shape) yet.
1 indicates first gear, 2 indicates second gear, and 0 indicates keeping the last gear the robot was in to give the table some hysteresis.
We plan on setting up the table for optimal acceleration at high throttle values and energy conservation at low throttle values. Then optimizing the table through testing. As a car guy used to tuning spark and fuel maps like this it seemed like a straight-forward way to do shifting for the robot.
We don’t shift while rotating in place.
Comments from you experts who’ve been doing this for a long time are more than welcome.
Well at TORC, we are running two speeds this year, for our first time ever. We have done some autoshifting code, but it is really it is another adaptation of 2013 bee code, with some simplification due to halo drive code.
If you are a Labview team, do yourself a favor and download the killer bees 2013 code that is posted in the CD-Media and look at the “drive_auto_trans.vi” that (I assume) Andrew wrote. It is very well documented, and if you read it, you can understand the logic.
You will not be able to drop this vi in and run it, as you do not have the same operator interface their divers use, which complicates that particular .vi. But if you read the comments, and follow the logic, you can put together a very good functioning auto-shift code in a couple of days with minimal labview experience. We are just getting the bot running, but the autoshift code is debugged, and working, the kickdown and coastdown work well with our initial estimates on switch points. We still have some tuning to do on the up-shift, point. We are having some issues when the right and left do not up-shift in sync, which is mechanical in root, but hoping to minimize it with tuning.
Thanks again to Andrew, apalrd, for excellent work, and sharing. We owe you some more swedishfish!.
We never actually calibrated this software, as our driver did not require it.
The algorithm is the same one we have been using (on and off) for years. The algorithm should be solid. All of the cals are totally guessed with no testing.
The more we work with multi speed gearboxes, we keep reducing the automation as we simply don’t need most of it any more. When power was scarce and we ran 4 speeds (and 2 speeds with 1 motor per side), we needed autoshifting for the acceleration and driver overload, now with 6 motor 2 speed drivetrains we have plenty of power to spend most of the time in high. The autoshifting becomes less significant every year. We keep trying to reduce ratio spread to make the low gear usefully high, and eventually might bring back autoshifting to manage that. However, the past few years, our strategy has not required it. If we were to play Overdrive (2008) again, would likely auto shift again.
the vex transmissions just work better in every way. and shifting is smoother with the ball shifter rather then dog gears. and there much lighter and smaller
