View Single Post
  Spotlight this post!  
Unread 27-12-2012, 12:54
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Programming for a Shifting Gearbox

1. That's John V-Neun's spreadsheet. I added a few columns and a graph, but the majority of it is JVN's.

2. Yes, we have done this. Our 2011 code release includes such functionality. It's in drivetrain/autotrans.vi. Upshift is enabled and was used frequently, downshift was disabled. The driver wanted the robot to stay in high while placing a tube unless he commanded a shift, because a shift would change the turning behavior. We also never calibrated the downshifts as well as the upshift, mostly due to testing time. Since that robot had a 2-speed the logic only calculates upshift when in low and downshift while in high, if we had a multi-speed the architecture would be different but the logic would be the same.

The logic works basically in three ways: power-on upshift, kickdown, and coastdown. Upshift occurs based on robot acceleration, vehicle speed, and throttle positions. Kickdown (downshift for power) occurs when the robot is decelerating, is below a vehicle speed threshold (~8fps), and the driver is not requesting slow down (sticks > 0.85). Coastdown (downshift at very low speed) occurs when the driver is not requesting power, and the vehicle speed is very low (~2fps). We never autoshift while turning, and we prevent autoshifts 500ms after any shift.

We based the 2011 algorithm off our previous algorithms originating in 2004, which were developed from automatic transmission algorithms for cars. The logic is basically a bunch of thresholds on acceleration, speed, and driver input, and when they are all true it shifts.

This algorithm is most useful in high-speed full field games. It is much less useful in short games where the high gear acceleration is higher (due to lower top speed), and it basically requires the shifters to shift synchronously (no servo shifting) or the robot will randomly twist during an unexpected shift, which the driver will not like.

Edit:
I never had any issue shifting under load with the pneumatically-shifted AndyMark transmissions. The servo transmissions wouldn't shift under load period, but the pneumatic ones seemed fine. The life cycle of an FRC robot is measured in hours, so properly greased gearboxes don't usually wear like cars. Some motorcycle transmissions shift without using the clutch, and they live.
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack

Last edited by apalrd : 27-12-2012 at 12:58.