We have had so many problems with our motors attached to our back wheels. First we had to replace the back left motor totally… Now the right back motor is cutting in and out. It isn’t getting to hot b/c it is cool to the touch. We are using 2 motor tank mode two drive the whole robot. Are we putting to much strain on those two separate motors asking it to power the whole bot? If so, what is an alternative?
tutman96: Add more motors to the base? What do you mean by that? Things are pretty tight… I don’t know what the deal is… It just keeps going in and out… One sec it will work and one sec it wont…
You didn’t follow up to that thread with the requested information,
but the answers didn’t change since the last time you posted.
Same answers as that thread applies, requoted below.
Note that your robot apparently has 1 motor per side for the drive train.
Most competition robots reported here have 2-3 motors per side.
Two motors driving a robot has not worked well for a team near us. We had an MSU practice meet with them and during a 1v1 match they tried ramming our robot because their lift became nonfunctional. When our robot pushed back, the other robot ended up with a broken motor. It happened to them again at a tournament when they were pushed by a different robot. To avoid this and the problem you’ve been having, I would suggest having 4 motors on the wheel base.
We ourselves had problems like yours. I have a few suggestions to offer.
-First you should check your wiring; are there any loose connections in your cables or in the cortex ports? If not, make sure your motors are plugged into the brain correctly, with the black wire facing toward the edge of the brain. Our wiring was part of our problem, and the simplest mistakes are always the first thing you should check.
-Another key factor is the ports you are using. There are two circuit breakers in the cortex: one for ports 1-5, and another for ports 6-10. If all of your motors are plugged into one breaker, it is possible that they are tripping it, which would cause the motors to stop.
-One more thing to check is the old motors you took off and replaced. Try opening them up to see if any of the internal gears are stripped or worn. If they are, you have probably been overworking them and need to add more motors to your wheels.
-If all else fails, you can’t go wrong with more power. The team I told you about that broke its motors has a sister team that uses two high-power 393s on its wheel base, and they haven’t had any problems with it.
Hey guys thanks for the feed back. Here is my wiring system:
Wheels are port 5 and 6
Arm to go up and down is 8 and 2
To suck up balls and sphere are 3 and 9…
If that is overload: Where do I move some of the wires? The are facing the correct way. I double checked that…
What do you mean 4 motors on the base? I am not understanding that…
I don’t know if I can get 393 motors b/c I have NO money, but I would be willing to spend my own if it helps my students.
Well, that is a little tiny bit of the data requested…
You didn’t mention motor type: 3-wire, 2-wire 269, 2-wire 393; I’ll assume 3-wire.
You didn’t mention wheel type: I’ll assume 4" original tread.
You added later gear ratio: direct drive 1:1
Great: It looks like you are already splitting each thing evenly across the 1-5 and 6-10 boundaries.
There are lots of “reveal” threads with pictures of better (more expensive) drive trains, if you search for them.
There are various threads on fundraising also.
You can use smaller wheels to increase torque and drive slower, and that will probably stop the motor halting, at cost of lower performance.
You can buy more and stronger motors (get 2x of these at #30 each) http://www.vexrobotics.com/products/accessories/motion/276-1668.html
You can put the existing motors on the front wheels, and put the new motors on the rear wheels.
If you don’t yet have omni-wheels P/N: 276-2185 ($25 for two) on the front, that would also be helpful to reduce wheel scrub when turning.
Advanced programming to make your own joystick to drive motor routine that changes more gradually is reported to help also. Practice driving “gently” can do the same thing, but is hard to implement in the pressure of competition.
So it sounds like you have two of the smaller 269 motors, one on each side, geared 1:1 to the back wheels. That’s not enough for all but the very lightest robot. We use push bots for demonstrations with elementary and junior high students that use two 393’s, they only weigh perhaps 5lb but can perform for hours with no problems. On the competition robots the teams use one 269 and one 393 on each side geared at 1:1, not the fastest but very reliable.
Yes, we have only 1 269 motors on each side. We do have ommi wheels on the front! We can drive 2-3 minutes then they cut out… Wait a few seconds, then they start going back again… Cut out again, ect…How do you program the motors to go slower instead of -127 to 127??? I did open up one motor and no gears or anything was busted… It was in good shape… Just started doing it more recently though. When we first started practicing it wasn’t cutting out as bad. Aslo it goes FAST but doesn’t last long… So it is “pushing” it well enough, but I guess tiring out the motors QUICK…
I don’t know… I can weight it this weekend… So I can put two motors on the omni wheels? Is that what you mean? If so then I would really have no motor ports left. I have 6 right now that would make 8… Can those motors only be on motor ports not digital or analog? Also what about programming so the motor just doesn’t jump from -127 to 127…
Assuming you are using a cortex then you have 10 motor ports, ports 1 and 10 do not need the motor controller 29. As competition robots can only use 10 motors maximum you will not run out of ports so don’t worry about that.
If you are using ROBOTC then I posted an example of motor slew rate control here, however, it’s more advanced programming so you may wish to leave that until next season. Not sure how to tackle it in EasyC but assume it would be part of the main control loop rather than in a separate task.
Yes, you should do that. And if your robot is heavy, you should use the green clutches. Last year at the World Championships we had four 269s on our robot, but without the clutches it overheated chronically, causing us to lose a lot of matches. Then we added clutches onto the robot and we won every match afterward.
So put motors on the omni wheels… That help the load on the back two I guess that is doing all the work? Also, the clutches make that big of a difference on overheating? So add the green little clutches to the motor?? How does that help? I am sorry, just not really mechanically inclined.
The function of a motor is to convert electrical energy into motion. However, when a motor encounters resistance, and it can’t move, the electrical energy can’t become motion because the motor can’t move. Instead the electricity becomes heat and overheats the motor.
The clutch is a mechanism that will grind within itself when the motor is trying to turn but the wheel can’t. So, the motor can still spin and make motion even if the wheel won’t turn. This will slow the production of heat and stop the motor from overheating.
Clutches must be replaced from time to time so if they strip. A stripped clutch will let your motor turn freely without spinning the wheel.
Okay guys… Update: Got the 2 393 in the back for the two main wheels… Put the original 2 292 motors with clutches this time, in the front for the ommni wheels… I know this, it is MUCH faster… That wasn’t my goal, my goal was for them not to cut in and out… I will let you guys know after this evening… I have robotics class from 1:45-3:25… Plan to run it w/o taking much of a break to see if they over heat or cut out… Last time we have to run 2.5 min, rest 2.5 otherwise they would cut out… I sure hope it solves our problem.
You can always reduce the speed by reducing the power on the joystick. Instead of settign the motor value directly from the joystick value, run it through some function or a simple upper limit. Something rudimentary like If joystick_val > upper_val then motor[x]=upper_val else motor[x]=joystick_val.
There are other ways of doing that too. Put a function/compute statement to take joystick value down by half or scale it somehow. But an upper limit will work if you’re just worried about going too fast in general.
If the sudden changes in speed cause the motors to be too stressed that can trip the motor too. Whipping the joystick form max up to max back can do this. Then you have to look at slew rates like jpearman showed in his post.
On a side note, running motors on front and back wheels now moves the center of rotation too. It is more getting to know your robot drive movements but it could impact your autonomous programming too for how you do turns. So you may not have to move as far forward before doing your turn since it will pivot around the center of the bot, not the center back of the bot.