We built this reverse drive so the robot will drive straight with out programing. It was easy to build and we will be testing it on our robot soon. We had it modified in 3 hours.
Two things:
-
What’s a reverse drive?
-
Do most teams need programming for straight driving, or have I just been on two incredibly lucky teams?
-
I believe its a method to overcome possible direction bias of cims, enabling both sides to spin in the same direction by adding one more stage of 1:1 gearing.
-
We’ve never had issues either…well aside from misaligned swerve modules but that’s a different story
We’ve never had issues either, the CIMs are neutrally timed as far as I know. Differences in speeds are more commonly from extra friction.
We have always had trouble during autonomous mode. The robot always wanders to the left and we have to program it out. All electric motors go faster one direction than the other. This is a very simple fix.
If you don’t have the programming skills, I could send you some simple LabVIEW code to drive straight, using kit encoders. Just PM me if you want it. It’s a simple drop-in block for Autonomous Independent that drives straight, at a fixed speed (in ft/sec), for a fixed distance. You need to give it two encoders and a RobotDrive, and tune the gain slightly.
Mad props to you good sir.
Just one thing though, you wouldn’t happen to have CAD models or drawings would you, becuase if this is really simple, then perhaps our own design team would like to incorporate it into the 6-wheel tank drive we’re modeling this preseason.
This seems like the way to go to me. It may not even be problems with the motors (or even if that does exist): friction in the drivetrain, imperfections in the play surface, wheel slipping (encoders attached directly to the drivetrain can’t fix this though), among other things.
–Ryan
Just to be clear, maybe all electric motors in the KoP have bias, but the statement is not true of electric motors in general, especially brushless motors.
**
Our drivetrains go straighter in autonomous after we switched from victor speed controllers to jaguars, which don’t have an offset center.
A [quadrature] encoder and velocity PD control loops are lighter than an additional gear.
While true, if this is a big problem for this team and driving straight is fixed by a single additional gear, a team heavy on the mechanical but light on the programming resources could pretty reasonably decide the tradeoff is worth it.
That being said, I’ve been told many times before that CIMs have no significant motor bias whatsoever. I have no data, but my team has also never had this problem so I’m inclined to think for my purposes, it’s not a big deal. Your team and setup could be completely different, particularly if you have a 2WD robot which has no turning scrub.
The only time we’ve ever had a significant problem driving straight was when we had drag due to a worn mechanical component. We’ve always used skid-steered drivetrains however, and those tend to stay straight because of the their frictional interaction with the floor.
Every one of our issues in driving straight has either had to do with an imbalance in friction or in a misalignment of a wheel. While fixable in software, the unfortunate side effect of such a fix is the robot moving slower overall. Software fixes also add complexity to debugging an autonomous like 2008 (go straight a set distance, turn a to set heading, straight, turn, straight …) in that the autonomous is less likely to be 100% consistent.
A little bit of extra code sure seems like it would weigh less than extra gears. This seems like a good way to waste ounces to me.
Hm… I’m curious as to why that works? It would seem like it wouldn’t make that much of a difference…
As far as I can tell the direction bias of the CIMS is less than 100 rpm.
But why add an extra gearing stage when you could simply mount the gearbox in the same direction.
I was just gonna suggest this. Also, the only problem we had with turning was with our open loop autonomous when we went straight we turned slightly. this was probably cause by our electric board and battery being on the same side and nothing on the other. We tool a Tachometer and measured the speed of the motors with no load and they were going the same speed. Are you sure this wasn’t your problem? or maybe they have a direction basis while under load?
That’s a good point, There are also differences motor to motor especially for older motors.
Using the 100 RPM bias figure that Coffeeism mentioned (note–I’m not sure how accurate that is; someone may want to figure it out), and the free speed of a CIM at 5500 RPM, that’s a 1.8% difference from switching directions. Pretty small. When you gear down a CIM, you multiply that a bit–but it’s still pretty small. For a free-speed motor, it’s entirely possible that one motor and its otherwise identical twin have a larger free-speed difference than a motor and its bias.
Would it work? Probably. Are there other, simpler, and possibly more elegant, ways of doing the same thing? Yep; I can think of 2-3 off the top of my head, ranging from ignoring automode entirely to having a gyro and a pair of encoders and some programming to ensure that the robot maintains heading to within 1/1000 of a degree or some other ridiculous degree.
I think it’s a new solution to a much-solved problem; while I can appreciate the engineering, I don’t see why it’s better than the other solutions.