[FTC]: Robot problems with motor movment

[135FusionTom]

Hello everyone, our team has been having a problem with one of our drive motors lately. The motor first moves in the opposite direction that we want it to, and then after about half a second it moves in the correct direction. We have heard that switching the polarity of the wires connected from the motor controllers to the motors is a way to fix this, but all of the teams who we have talked to that were having this problem had had the problem with shooter motors rather than the drive. Any ideas on how to fix this would be much appreciated.

Thanks,

Tom and Michael, 135 Fusion.

[Monty Python]

Can you post the code that you're using?

[Al Skierkiewicz]

Tom and Mike,
Are you using the feedback from the motor? It is possible that the code is written in such a way that it runs that way.

[Mike Betts]

Tom and Mike,

Assuming that you are using the competition templates, this could be a problem with your initialization (running in one direction) versus your main loop (reversing direction).

Exact cause could be different depending on your programming language choice.

I agree that posting your code is the fastest way for people to help.

You should also be sure that you have the correct firmware installed in your NXT brick and that the latest templates were used.

Regards,

Mike

[Mike Betts]

It will also be helpful to note exactly when this occurs. At the beginning of Autonomous, at the beginning of Teleop after Auto or in Teleop only mode?

[Michael Coleman]

Are encoders mounted on the motors?

If yes, are they wired correctly? Are they coded correctly? If using ROBOTC, are the encoders correctly setup in the Motor Controller settings?

If no, and using ROBOTC, verify that the encoders are not selected in the Motor Controller settings.

[135FusionTom]

Thanks everyone, your input is much appreciated. I'm not one of the programmers on the team, but I think that I can get in touch with Michael to ask him about your questions. I do know that we are using Robot C, and that we don't use motor encoders. The problem occurs during Teleop and autonomous. Anyways, as I said, Michael would know more about the code, so I'll contact him and ask about all of these questions and for the code.

Thanks,

Tom.

[135FusionTom]

TeleOp Program.c

Here's the code. Thanks again for helping us out.

Tom.

[Mike Betts]

Tom & Mike,

First of all. Please be absolutely sure that you have the very latest RobotC (v2.01) installed on your computer and that you have downloaded the very latest firmware version (v7.88) to your brick.

Next, open a new program in RobotC using the Teleop template that comes with RobotC. You will notice that it has an empty initializeRobot() routine that is called from the main task just before the waitForStart() statement.

Please add this back into your code and then put the following statements into initializeRobot():

    motor(leftMotor) = 0;
    motor(rightMotor) = 0;
    motor[beltMotor] = 0;
    motor[feederMotor] = 0;
    motor(shooterMotor) = 0;

If neither of these actions solves your problem, you may have to find someone smarter than me to help you.

Please let me know how you make out.

Regards,

Mike

[l0jec]

You issue is likely with floating the motors in ROBOTC:

    else
    {
      motor(shooterMotor) = 0;
      bFloatDuringInactiveMotorPWM = true;
    }

I've notice some erratic behavior if you set a motor, change the bFloatDuringInactiveMotorPWM flag and then set the motor again. Remember that the flag affects all your motors and it seems to only affect motors when you actually set a motor (if you set a motor and then flip the flag, ROBOTC will not apply the coast/float flag until you set the motor again).
You may want to just always float or change the flag back and forth every time before you set any of your motor outputs.