Does any of your team faces motor problems ? For example , motor moving slower than the other and motor not moving at all. I am just wondering if my school is the only school facing this problem. Thanks
Not really, I mean, if you put 269 on one side and a high strength on another it IS going to go at different speeds…
More details?
What I meant was , using 4 393 on the base and 6 on whatsoever . Like doing a 4 bar lift , does your motor spoil easily ?
Our team was having the same problem last year. It turned out to be the motor controler had burned out for some reason. After replacing it, we never had the problem again. I hope this helps.
Sincerley,
Team 4033B:)
Our team had a problem that our drive did not go straight. We have a 4x269 6 wheel drive. 4 of the wheels are driven and at the ratio 1:1. When we move forward, the left side is slightly faster (enough to cause us to go about 1/2 foot to right with every 5-6 feet we drive). Also, when we go backwards, our right side is slightly faster than left. We attached a sprocket on the right side, and also the left side to see the speed difference. There was a tremendous difference in the speed. Vex should make an RPM tester so you don’t have to use your eye to see if something is in tune with another. There is the encoder, but you have to write a code for that, not just pull it out of you pocket.
The problem is fixed now and the we can drive straight. I do not know how the problem was solved, most likely by itself. It could have possibly been that one or two of the motors were new and still needed to be ‘‘broken’’ in, so that caused one side to go slower. I am not sure, and doubt, that motors can be ‘‘broken’’ in though.
It sounds you are having a larger problem than me though. If the motors are burning out then you are most likely working them to hard. There could be a number of issues.
At the beginning of the year we sort of had a similar problem. We would have the same 6 wheel drive and then 1 of the motors would burn out. I still wonder why that happened. It could have possibly just been the motor itself because we had near 0 friction (tested) and no mechanism attached to the chassis, and yet the motor still overheated (I think that is the proper term). The chassis probably weighed 2-3 lbs max, so I do not know why. We ended up just replacing them for other motors, but if all yours motors are having the problem of burning out very easily I would take the motor off and run it for a minute with a very light load attached to see if it still burns out.
There are lots of things to check if motors aren’t moving.
Might hit amp breakers because:
-Gear ratio
-Friction
-Internal gears damaged
-External gears damaged
Also:
-Broken pwms
-Broken cortex ports
-Burned out motors
-Broken motor controllers
Building off of that, there are easy ways to check most of these issues.
For internal gears being damaged, often times simply letting the motor free spin without any load and listening for a rhythmatic clicking noise can indicate that some teeth inside have broken.
For friction, check to ensure your axle is supported atleast on or near both ends by bearing blocks. If not, there is a chance that the axle has cut into the metal and enlarged the initial square hole.
However to answer your question, yes. My team has came across a few motors that when tested electronically, are damaged after prolonged use.
Yes , we do have issues with the speed difference. Most of our motor are usually 269 . We are using it for a lift . 4 motor driving at 1:7 , geared for strength . Only the top 2 motor driving the size 7 gear will slow down causing the whole mechanism to slow down . There I’d also cases whereby the motor lock itself .
The issues we are experiencing is that one of the motors seems to be exhibiting a high pitched noise when connected to power. Seems like there is some sort of EMF interference causing it. Out of the 4 we have on the robot, only 2 exhibit this issue. We’ve tried switching ports on the microcontroller to see if that was the issue, but it seems to boil down to either the motor controller or the motor itself.
Also sometimes, the motor will move on its own, with no input from the joystick (393 model)
It could be a simple deadband issue, but it doesnt make sense that it only happens sometimes.
Sounds like deadband issue to me, particularly BECAUSE it only happens sometimes.
If you wiggle the joystick, does the noise change?
If you write down the exact description of how you tried switching motors between ports, and the motor response, and the response to joysticks, by the time you have it typed up you will likely have figured out the problem.
Now that I’ve figured out my EasyCv4 Array referencing correctly,
I’ll have to post my code for auto-centering.
My robot/joystick often have deadband centering issues (robot is stopped, but whines).
I made a button press/routine that says, in effect, “whereever the joystick is now, that should be the new center”. Pushing the button stops the noise.
jgraber, would you mind sharing that code? or maybe give a little more information on how that works?
I don’t have it wrapped up in a nice package yet, but here are the pieces of code.
This part detects a centering request, and saves current position.
Bcentered = GetJoystickDigital( JOY1, CHN_5, UP ); // request for recenter
if ( Bcentered > 0 ) { // any shoulder buttons mean recenter joystick
StickCenter[STK_1] = GetJoystickAnalog( JOY1, STK_1 ) ; // current is Center
StickCenter[STK_2] = GetJoystickAnalog( JOY1, STK_2 ) ;
StickCenter[STK_3] = GetJoystickAnalog( JOY1, STK_3 ) ;
StickCenter[STK_4] = GetJoystickAnalog( JOY1, STK_4 ) ;
} This part is ScaleRC, to get a parabolic or other power function scaled value from joystick, including recentering feature, and deadband. It was somewhat hacked up during debug, so I’m pasting it here without full compile check. YMMV
int Scale_RC1 ( unsigned char StickNum, int Deadband, int MinPower, double Exponent )
{ // input^exponent if greater than deadband( 1, 15, 20, 3)
int StickIn; float SIa; int MaxPower;
MaxPower = 127 - MinPower ;
StickIn = GetJoystickAnalog( JOY1 , StickNum ) ;
StickIn = StickIn - StickCenter[StickNum] ; // recenter!!!
if ( Abs(StickIn) <= Deadband ) { return 0 ; }
SIa = Pow ( Fabs(StickIn)/MaxPower , Exponent ) ;
SIa = SIa * MaxPower + MinPower ;
if ( SIa > 127 ) { SIa = 127 ; } // limit check, only positive values at this point
if ( StickIn > 0 ) { return SIa ; } else { return -SIa ; }
} // end Scale_RCI’m using these input parameters to get scaled values to pass to usercoded arcade drive function; arm motor is set directly from ArmSpeed;
// var stick, dead, min, scale
Stick1 = Scale_RC( STK_1, 5, 9, 1.3 ) ; // direction
Stick2 = Scale_RC( STK_2, 2, 15, 1.5 ) ; // speed
ArmSpeed = Scale_RC( STK_3, 5, 30, 1.7 ) ; // Here is an example of Macro/constant Main.h showing use of STK_1=1, to make it easier to understand a long list of numeric parameters.
Also the arraydef for StickCenter; It took me too long to figure out that definition should include [5] to get subscripts [0…4] typical C rookie error.
#define DN 1 //JoystickDigitaltoMotor UP = 2
#define UP 2 //JoystickDigitaltoMotor UP = 2
#define STK_1 1
#define STK_2 2
#define STK_3 3 // these values are used as subscripts to StickCenter]
#define JOY1 1
extern int StickCenter[5] ; // note subscripts are [0]..[4], [0] is unused
There you have it.
thank you!
it seems like it was written in robotC? i’m working with easyC so i wonder if that can be adapted…
This is EasyCv4 for Cortex, just written in text C user library; expert mode flow chart box UserFunctions, add new function; then read Help for “convert to C Code”
You can also use these ideas in EasyC drag-drop flow-chart mode,
you just need to understand the ideas,
then do a bunch of point-clicking between typing each line:
- All the Macros and Constants can be entered in the Globals flow chart box.
- use Joystick menuitem to drag in GetJoystickDigital box into your while(1) loop and fill in the fields to get this line: Bcentered = GetJoystickDigital( JOY1, CHN_5, UP );
- use Program menuitem to get If/then block : IF ( Bcentered < 0) {
- use Joystick menuitem to drag in GetJoystickAnalog; you may have to type directly into the retreive to variable field, to get the array reference right; Otherwise you can also just drag in Program menuitem Assignment, then type what I have shown.
user defined RCscaling function isn’t critical to the Centering feature.
Some parts I didn’t show, like user_arcade_drive, are critical, since they replace Arcade/Holo predefined routines from EasyC. But those algos are described elsewhere, and can be entered in-line (not a subroutine) with Assignment flowchart boxes if you want.
The key idas are :
// change the centering array variable when asked to do so
var = GetJoystickAnalog; // get the joystick value to a variable.
var = var - centering]; // modify/recenter the value of the variable
// limit check on var might be useful here too.
SetMotor N, var]; // use that modified variable to set a motor.
If you just use the built-ins like JoysticktoMotor, or Tank4,
you have no opportunity to modify the joystick value before it gets to the motors.