Our robots motors click when we suddenly change direction. After a while one of the teeth inside the motor will break off. The collar that holds the last gear is there. We are geared to 1.6 with 4 motors on the drive. The gears have 2 point connection so it is not them. We have tried running the motors together and separate, no change. The motors are internally geared to normal. We put brand new gears in the motor, but it did not help. Once we opened a motor to replace the gears and found the teeth ground off. What can we do to stop the gears from clicking?
We are as light as we can be without tipping over while extended.
Would putting a derivative on the forward/backward joystick variable slow down sudden changes? Like in PID control. The bigger the change in the value, the more the derivative will add (or subtract if the value is negative) thus slowing down sudden changes.
if(derivative < 3){ // so that it only slows down big changes
derivative = 0
}
motor_speed = (joystick_value + (d_gain * derivative)
motor(3) = motor speed
motor(4) = motor speed
motor(8) = motor speed * -1
motor(7) = motor speed * -1
Our driver does not want the derivative. Is there any mechanical things we could fix?
This way, it takes 400ms for the motors to fully change direction, which should save your motor gears from breaking.
There are some mechanical things you could do, such as changing the gear ratio to give you more torque, but that won’t help if your driver is “flicking” the joysticks, aka changing from full forward to full backward very quickly. This will put a lot of stress on the motors (breaking teeth), as well as loosening screws and doing other bad things. Have your driver take it slower on the joystick (we’ve threatened taping their thumbs to the joysticks before so they can’t flick them).
or your driver can practice more and drive “smoother”
we met a new team that looked like their drive was on digital control…
just full forward or full back…
This reminds me of current BEST robotics situation, where using the BEST small motors direct drive on 8" wheels on 20 pound robots can easily destroy the motor gearbox.
There are two related sources/solutions: mechanical and programming
**Mechanical: **
Shock load on motor gears is made worst by “backlash” in the gear train.
The amount of front/back wiggle your robot has, without moving the motors is backlash. Try to reduce that. Common sources of backlash are:
slack chains,
long gear trains
transmitting torque through axles, and axle slop in gear/sprocket/wheel
I promote these methods for low backlash:
only torque carrying axle is the motor axle (cant be avoided)
motor axle has HS gear with metal insert, or axle-lock-bar to gear/sprocket
Sprocket/gear is bolted to wheel, with free-spinning axle.
Simple drive trains: 1motorgear to 1wheelgear, or 1 motorsprocket to 1wheelsprocket
These things also increase drive train shock loads:
high mass robots
jerky driving
large wheels
Programming:
Since backlash cannot be completely eliminated, “driving gently” is needed,
and has been shown experimentally to reduce (BEST small) motor gearbox failure.
Programming methods can be used to enforce driving gently.
A simple while(1) {} loop may run in less than 1ms.
A good motor update interval is ~20-40ms.
Rate limiting may work as well as derivative or averaging code.
Pseudo code, must be updated from “tank4()” to “Sense-Plan-Act” model
If you have an LCD and extra potentiometers, you can sent delta and time
with the pots to let you easily drive, adjust, drive, adjust to find a sweet spot between motor destruction and driver reaction time.
time = 5 and delta = 500 will be no different than you have now
time = 40 and delta = 20 might be a good place to start, and work delta up or down from there.
int goal, actual;
int delta = 20;
int time = 40;
Setup RepeatingTimer to call Act() subroutine every time ms;
repeat forever {
Sense: goal = get joysticks
Plan: recenter and clip goal variables to (-127,+127)
misc other
}
subroutine Act{
if difference between actual and goal is less than delta
then set actual = goal
else set actual toward goal by delta
SetMotor( actual )
}
We’ve had a lot (6+) of the 269 motors die on us recently. Brand new, out of the box, in most cases. We hadn’t changed our drive train since probably November, had used the motors through a couple of competitions this year, and then we lost a drive motor in February. We replaced it with a new 269, and the new motor promptly failed after only light driving. That motor was replaced by another new 269, and that one failed too. We’ve got one 269 motor per 4" omni wheel, direct drive in the back, and 1:1 gearing in the front. The robot weighs just under 12 pounds. We’re using simple averaging to avoid flipping direction too quickly while driving. Some of the motors have had broken gears, some of them have gears that look great, but don’t work (burned out electronics?). We’ve gotten rather paranoid lately, and when we opened a new 269 motor on Saturday, we plugged it in and did a no load test on it, and it sounded like it was chewing marbles. This post has some really good tips, and we’ll follow up on them, but we’ve gotten really frustrated with the 269 motors we’ve received lately. Some that we open look almost bone dry, which doesn’t seem right for a brand new motor. Is it just us (certainly possible), or might there be some quality control issues going on? We’re frustrated enough that we’re tempted to send them all back to VEX, but don’t think that would resolve anything, particularly if we actually are doing something that’s causing them to fail. Probably just needed to vent a bit…
Studying this issue is on the to do list for the off season, however, this is something I posted a few months ago. It’s a variation on what others have suggested and I call slew rate control rather than straightforward low pass filtering. This is written in ROBOTC but it could easily be adapted to EasyC as well.
Here is the guts of an EasyC slew rate routine:
Mt[10] is array of Motor speed targets
M[10] is array of Motor speed actual slew rate controlled outputs
I didn’t make Mdmax max step size per call as an array per motor type.
The slew rate is controlled to Mdmax * loop interval.
Act is a good place to use the EasyC repeating timer feature.
Mdmax = 40; // max step size per call
for( i = 0; i<=9; i++ ){
Mdelta = Mt* - M*; // target - prevActual
if ( Abs( Mdelta) <= Mdmax ) { M* = Mt*; continue;} // target ok if small delta
// else needs stepping
if (Mdelta > 0) { M* += Mdmax; continue; } // step up
else { M* -= Mdmax; continue; } // step dn
// never gets here
} // rof
An interesting variation to consider:
Gateway standard NZ type robots with 4motor drive, 4 motor lift, 2 motor intake really only need 4 motor speed settings( Left,Right,Arm,Intake) as all the motors for the eg Left wheels can share the same values.******
yeah
our grade 8 team keeps on rebuilding their robot over and over and the only practice they get is the morning of competition…
give the joysticks to an experienced driver, and it works like a dream
nothing can replace practice
We where useing ports 1,2 and 9,10 for our drive. We thought the power might be changed when it went though the motor controller. So we moved the motors to ports 3,4 and 7,8. All of the drive is now on motor controllers. No help. We had a idea. We are geared externally with a 60 tooth on the motor and 36 tooth on the wheel. What we geared the exteral to 1:1 (our design requires that the motors be back a bit) and geared the motor to high speed. This would make it so the wheels would have less strength than the motor. So when we the robot changes direction the momentum has less strength over the motor. Would this work? I am not sure if I thought this though all the way.
I would run your drive motors in ports 1,2,9,10 with the rear motors in 1,10 and the fronts in 2,9. Try taking off your motors and leaving everything else in tack. Push it around to see how well it rolls. If you give it a push and it does not roll straight you may have some friction or your frame may not be square. Your weight may not be distributed evenly which may cause it to not operate correctly. You can also post a photo of your robot to make the troubleshooting easier.
