I know this has been discussed here, but it is still unclear (at least to me):
When you are attempting to choose the appropriate gear in software, what variables in the environment is the decision based on? It seems that in a manual car they are based on engine RPM (tachometer) vs. speed, as these are the two instruments that drivers are given. But others say it should be throttle (joystick values) vs. RPM. It seems weird to do it with RPM vs. speed because on robots they are linearly related (although that is probably true in cars, too). In each gear, speed = RPM * gear ratio (and the wheel circumference, which is always constant). Anyways, what are my independent and dependant variables going to be for my lookup table?
Also, when you up-shift, should you lower power to the motors enough to still be at your current speed with the new gear ratio? (eg. lower the PWM output for a given joystick input)
the PWM values for [the servo to engage] 1st, 2nd and 3rd [gears] should be adjusted in software to match the actual values. If shifted slowly, the transmissions will actually shift into “neutral” between each gear. This feature together with sensors on the wheels can be used to help the software provide smoother shifting via “software synchronization” but that is a topic for another whitepaper.
Any more info on that? Has that whitepaper been written?
Thanks in advance,
Robinson
BTW, yes I am going to have a manual override, and yes, I will have logic that prevent quickly changing gears when the 'bot is on the boundary of the curve.
With DC motors, your shift down will, as a best reference, be decided by the current draw. If you exceed a certain current draw for a period of time, say 30 amps, you need to shift to a lower gear, should one be available. Vice-versa with the up-shift. If you are moving, and yet only pulling a few amps, you can safely up-shift. Most of your decisions about shift points will have to be determined by trial and error.
And, depending on your situation, you probably want to severely limit the opportunities for software to actually shift- otherwise you’ll end up with alot of hunting, all the time. Sort of like an automatic going up a hill. Really, software should only shift if a relatively extreme limit has been passed- such as a quick jump in velocity for a field crossing, or a heavy spike in current draw during a pushing match.
Current can be measured in many ways. PWM value only relates to voltage, not current. One way to measure current is to detect the magnetic field surrounding a current-carrying wire. Another way is to measure the voltage drop across a very low-value resistor (specially built to handle the current). Do some research on that.
As to figuring out trial and error, drive the robot in high gear and see at what motor current it starts to lose pushing power. That’s where you shift to low. Then drive in low and see where you’re coming close to top speed - that’s where you shift to high.
For example. Again, this is not wild cutting-edge technology, there’s a lot on the web if you take a look.
As far as letting the motor coast between shifts- I really don’t know, but we intend to find out! We’re using Dewalt 3-speeds this year, so we may implement an auto-shifter if we have time and motivation. With respect only to the Dewalt, as a fully assembled drill, it does seem to shift smoother more regularly if you let off a bit. However, if you hit it right, even with the trigger mashed, it still will shift smoothly on the fly. Sometimes. As far as a dog or ball shifter, because the shift is one stage into the gearbox, I think you typically just shove it. Not sure on that though, so a second opinion will be a good idea…
A couple of years ago, FIRST included current sensors in the KOP. You wired them between the motor and the Victor, and it would output a signal proportional to the current. I don’t know what the part number was, nor if they would be legal under this year’s rules, but both should be able to be found with a minimal amount of research.