So yesterday during our unbag time, we decided to test our autonomous that should drive straight over the defenses, and the drive is set for 70% forward. However, when we tested it for the first time on the field, instead of driving straight, it curved extremely left, crashing into the drawbridge instead of going over the moat. We went into teleop mode and made sure the shifters were set both to low gear just to be sure, then we tested it again, and it still drove to the left. We have greased our gearboxes, and have both belts set to proper tension. We did notice that the shifter coupler (interfacing the piston with the shifter) on the right side (the faster side) is rotating with the shaft, but the left side was not. What could possibly be causing this huge curve, and how would we fix it? We don’t have time to buy encoders and have them shipped to us, as we have a week 1 event. Thank you for your help!
Does it drive straight in teleop? Have you checked the current going to each motor? Have you spun the wheels by hand to see if one side is harder to turn than the other?
Do you have a gyro? Using a gyro is pretty simple these days.
First of all, does it only curve in autonomous, or in teleop as well?
If it’s only in autonomous, that would indicate a software problem.
If it curves in teleop as well, it could be any number of problems.
Are the speed controllers all calibrated? Are they all blinking at the same rate when it’s driving? Are all the motors running in the right directions? If all of those things are good, then it’s likely a mechanical issue. I’ve seen over-tensioned chains, over-tightened wheel shafts, bad spacing in gearboxes, and chains rubbing on parts of the frame all cause problems like this before.
If you can’t figure it out, could you compensate by powering one side more than the other in auton?
Are you using pneumatic wheels? If so, are the two sides aired the same amount? That could cause slight curving, but I doubt it would account for what you’re seeing. It might be a number of mechanical issues, like a bad bearing or a misaligned shaft on one side or a bad motor connection. Try pushing the robot forward manually and see if the robot curves on it’s own. Sorry if this is not much help.
For teleop, it isn’t noticeable when actually driving the robot on the field for some reason, but when we put the robot on blocks, we could tell that the right side is noticeably faster in both high and low gear. We’ll check into making sure the motors are going in the right direction.
We did get one through FIRST Choice, I’ll have our programmer look into that.
How many motors per gearbox? How are the motors connected?
We had the same problem last year and we discovered that one of the Anderson Power Pole connector contacts wasn’t fully engaged. That solved the problem for us.
We have 3 CIMs per gearbox, and we are using yellow crimp terminals.
You can use the power functions on the PDP to check the current going to each motor. If one motor is suspiciously low (or high), that could point to a mechanical or wiring problem, as opposed to a programming problem.
You can also try changing teleop to drive the motors at 70% power instead of whatever value the joystick says. That should tell you whether this is only happening in auton (the problem is in your auton code) or if it is always happening and the driver is subconsciously correcting for it (the problem is mechanical or somewhere else in the code).
Are you using PWM for your motor controllers? I had this issue in 2014 with PWM Talons until we calibrated them.
Disclaimer: Not on the manufacturing team.
But check the code. Is one side driving faster than the other in the code? If so, try boosting the left side to 80% and the right side to 70%. Just adjust so the system drives straight, even if the code says it shouldn’t (straight might be left 90% and right 60%. idk, robots do odd things.
Also, by some odd chance, does your left side have a higher gear reduction? could your gear boxes have been built just different enough?
The number of parts in a typical FRC drivetrain can make for a noticeable variation in the speeds of drive units. When run open loop, the drivetrain on our bot this year has one side a few percent faster than the other which made it curve.
Certainly calibrate all motor controllers and double check connections first. You may be able to tweak your drive train for better consistency and find a balance of motor power settings that goes approximately straight, but the real solution is using some form of feedback. A combination of wheel speed encoders and/or a gyro lets the roborio make adjustments on the fly. However this can take a fair bit of time to get coded and tuned in properly.
If you do have the time, I would advise using the gryo to make a feedback loop to keep the robot going straight. If tuned properly, that should make the drivebase drive straight regardless of any mechanical issues.
Not to pick on you directly, but this is a convenient quote.
I’d caution against ignoring the issue or papering over it, and instead start to look for the root cause. If the issue is that a motor isn’t plugged in when you thought it was, or the speed controller was disconnected or a mechanical issue, fixing it in code will make it look like everything works when it doesn’t.
The current suggestion is a good one. After that, I’d try isolating the issue. Feel each of the sides of your drivetrain and try to see if one side has more resistance than the other. Try unplugging all but 1 motor per side and see how it performs. Do that for each of the motors on a side. Try controlled experiments to see if you can discover where the problem is.
If you’re using PID for speed control, make sure the encoders are reading correctly (encoder shaft rotates with the shaft it’s coupled with, it’s wired up correctly, and you get a reading from the encoder when the wheel is spinning)
If the encoder isn’t coupled correctly with the drive shaft, a PID loop will “correct” it to 100% power
Also for PID: if your motor is inverted relative to the encoder (ie positive value to the motor results in a negative value to the encoder) a feedback loop will occur, causing the motor to go at full speed, and probably staying there even when the setpoint is 0. The solution to this is negating the setpoint instead of inverting the motor.
If you still need help at Southfield tomorrow, definitely come find me and I can take a look.
This needs to be shouted from the rooftops.
You might want to implement a PID control for the right/left side of the drive. Of course, you will need encoders for this on each side to provide feedback, but once they are plugged into the Talons, you can go about programming the wheels to set speed (or position or whatever, there are a lot of options, you’ll probably use speed) instead of percent voltage.
This will help you control the actual output from the motors rather than voltages.
This is a way to fix the issue programmatically. If you need help PM me, and I can help you (our team uses LabVIEW, but implementation in Java/C++ shouldn’t be too different, right?).
We had a similar issue at Palmetto. Our issue was that one of our Victors was bad meaning only one motor was running on one side of the robot while two was running on the other. Check the lights on on your motor controllers, that could be your problem as well.