Automatic shifting software

[StevenB]

Our team is working on a multi-speed drive system with using the DeWalt transmissions. It's my belief that we really need automatic shifting to make the most effective use of it. For those that have done this before, I have some questions:
What was the basic algorithm you followed?
What sensors did you use?
Were you able to make it shift without a major speed jolt when going up or down, and how?

In the NBD whitepaper, Joe P. mentions something about using "software syncronization" to acheive smoother shifting. I'm guessing this involves shifting into "neutral", matching the input and output speeds to the correct ratio, and then shifting into gear. Is this correct, and could someone explain how they made it work?
Thanks!

[Rickertsen2]

You could create tables of absolute joystick position vs rpm. There would be such tables to indicate when to upshift and tables to show when to downshift. This is how the shifting works in many cars.

The tables would basically say "if you are at 10% joystick, wait till x rpm to upshift" or "if you are at 30% joystick wait till y rpm to downshift. The tables would be setup so that at higher throttle, shifts occur sooner. At lower throttle, when you don't need the extra torque shifts would occur later. There would be some hysteresis in the system. The upshift and downshift points for each gear would differ to avoid excessive shifting. Perhaps an override in the form of a "low" switch could be provided for pushing matches or percision maneuvers.

The approach would obviously necessitate some means of measuring rpm.

I think that you could draw a parallel between racecars and FIRST Robots. For the same reason you don't see automatic racecars i don't know that it would necessarily be and advantage to have an automatic FIRST robot. One of the things that makes a good robot is predictibility. When you shift the chanracteristics of the robot change. If they change when you don't want them to, the robot is less predictible. I think that a well trained driver may be better than an automatic shifting algorithm. Once you get used to a manual, its not hard. I've never driven a FIRST robot with a shifter but i would assume that applies to robots as well.

[Jonathan Norris]

I can see the theoretical appeal to an automatic shifting system, but the practical application is not as clear. The ultimate horror situation I can think of with an automatic shifting system, is if you are in a pushing match with another robot and your software decides to shift you into a lower gear. But because of this extra force on your robot the shifting does not work properly, I have had this situation with a dog-shifting system. Theoretically this seems like a good idea, but practically I am not sure its necessary or as advantageous as it seems. Possibly the best solution would be a mix of automatic shifting with some operator control still involved.

[jagman2882]

1126 began using an iteration of killer bees 4 speed transmittion in 2005 and again last year. we have never had a problem of the computer shifting and not engaging...we have used shaft encoders count the revolutions and then have a program telling the bot when to upshift or downshift...IMO it has been the greatest thing that we have done...it is reliable and slick...im not quite sure of what the exact software is but good luck on the automatic...again we have never had a problem with it coming out of gear or ne thing like that...we never worry about it

[Mike Bortfeldt]

To expand a little on what Cory has already said...

We have had an automatic transmission for the past two years. The current iteration has quadrature encoders on the output shaft of each transmission and this signal is converted to the actual robot speed (in inches/sec) which is used throughout the rest of the code (each encoder generates approximately 2500 interrupts/sec at full speed and a timer with a resolution of 250 microseconds is used for the calculation). The transmission up shifts at speed points calculated mostly based on the output torque curves of the motors (maximize acceleration). Since both or our transmissions are paralleled off the same solenoids, the robot speed is determined by the average of the absolute value of each drive system. Typically, a difference of 8 in/sec is used between the down shift points and the up shift points to prevent the system from unnecessary cycling between 2 gears. For example, switching from second to third gear might occur at 32 in/sec but switching back down into second from third would occur at 24 in/sec. Also, to eliminate erroneous shifting, especially when starting or stopping, the shift points must be exceeded for two consecutive calls to Process_Data_From_Master_uP (about 50 ms).

As Jonathan has mentioned, when the transmission is under very high loads, it has a tendency to not properly shift gears. We noticed this during some of our initial tests. To minimize this from occurring, we temporarily limit the output to the motors to a maximum of about 15% of full power while the shifting takes place. The drop in power is not really noticeable as it only occurs for only a small fraction of a second.

The system also has 1st gear override which is enabled when holding the joystick trigger for use when pushing (or for last year’s game, climbing the ramp). As with most of our automated systems, there is the capability of switching into a completely manual mode in the event of an encoder failure or the like.
Have fun working on this project. We have found it extremely beneficial.

Mike

[jagman2882]

thanks mike....i really didnt know any of the software stuff which is really really important and makes the whole thing work

[StevenB]

I plan on having manual override, just in case.
Does the robot jolt when you shift, and do you compensate for this somehow?

[efoote868]

Our team purchased 2 AM servo shifters, so its now the programmers job to mess with them a bit.

I think with what we're going to do is have automatic shifting, once a gear-tooth counter counts to whatever, then decrease motor outputs automatically, and then "gradually" bring them back up to speed, depending where the joy is at.

We also plan to have a switch to manually override the shifting... low, high, auto.

Hope this helps!

[Tom Bottiglieri]

Originally Posted by efoote868

Our team purchased 2 AM servo shifters, so its now the programmers job to mess with them a bit.

I think with what we're going to do is have automatic shifting, once a gear-tooth counter counts to whatever, then decrease motor outputs automatically, and then "gradually" bring them back up to speed, depending where the joy is at.

We also plan to have a switch to manually override the shifting... low, high, auto.

Hope this helps!

Remember, it will take about half a second for the servo shifters to change gears. It seems unless you have a rock solid shifting algorithm, you will be wasting a lot of time on the field going nowhere and may experience quite a bit of "shift shock".

[Greg Marra]

Personally, I think that a driver should be able to handle shifting during a match himself. I find that usually you don't need to shift more than 5 or 6 times tops per match. Having the robot shift on its own seems prone to unwanted behavior.

Unless you can make the robot shift better than a person (like a CMUCam aims better than a person), why make it do it?

[JessR]

We have used a 2 speed tranny with encoder driven autoshifting the past 2 years and find it works well. As with Sparx above, we have offset the upshift & downshift points. We also reduce power for the 1/4 second or so it takes to shift.
Similarly our (homemade) 2 channel encoders give a quadrature signal that lets the software keep an absolute count & if you're going forwards or backwards.
Note in software you can 'have it all":
A toggle switch on the driver controls is labeled 'auto - manual'
In manual mode the trigger upshifts & thumb button downshifts.

With velocity based shifting, autoshift is just the thing for those closing seconds when you are distracted, burnt out & need to just peg the joysticks and head for home.

[Alan Anderson]

Originally Posted by Greg Marra

Unless you can make the robot shift better than a person (like a CMUCam aims better than a person), why make it do it?

The thing is, you can make the robot shift better than a person. A well-programmed robot knows how fast it's going, knows what gear will provide the best power at that speed, and knows how to make the shift smoothly.

[StevenB]

Has anyone done automatic shifting with the DeWalt transmissions? Are there things about them that make shifting different?

[chris31]

Taking what Alan, Jess and Greg said I think that the best idea is to have an manual and auto switch. That way the user can control it when he/she needs to and then turn on auto when it would best be done by the robot calculations.

[gnirts]

How does one figure out at what RPM/velocity/joystick position shifting is ideal? (We are using four small CIMs and Dewault transmissions.)

And how should the lookup table be structured? Why should it be joystick (throttle) position vs. speed? In a manual shifting car you get back RPM (tachometer) vs. speed (speedometer) and shift based on that (I think...). So shouldn't you shift up when your motors reach a certain RPM, while lowering power to the motors to maintain constant speed? That way you can continue going faster.

Thanks in advance,
Robinson