![]() |
Problem with Motor direction
Our programing / electronics team was trying our bench top test and we found that one of our motors was traveling backwards. The jaguar is receiving a backwards signal as denoted by the LED's color being 'orange-ish'.
We set up the bench top test stock from the KOP. Our cables were hooked up correctly. The motors did drive. We are using the WPI library (unmodified). Any insight if its just the WPI library? Is there a physical fix (reversing cables???) other than reversing the motors in the library coding. |
Re: Problem with Motor direction
Basically your choices include anything that complies with the rules...
For now you could switch the wires on the jaguars, on the motors, or just switch it in the programming like you said. Get it to work now and you will have more time to work on it later. Thats something thats good to remember. Dont spend a lot of time trying to solve a problem that can be quick fixed and worked on later... |
Re: Problem with Motor direction
Before you do this I have a question for you. Is the "backwards" motor you observed just form looking at the two motors not hooked up to anything and seeing that they were spinning opposite directions? If so I recommend orienting the motors as they will be oriented in your robot drivetrain (usually facing opposite ways) and see if they are now both spinning "forwards" or "backwards". In a typical FRC setup the motors must be driven in opposite directions to drive straight unless the wiring is reversed on one.
The physical solution is reverse the cables running from the Motor to the Jaguar. Take the cable currently attached to the negative side of the Jaguar motor output (probably black) and attach it to the positive side of the motor output. |
Re: Problem with Motor direction
The jaguar is receiving a backwards signal. The jaguars LED is representative of backwards signal. The LED is 'orange-ish'. Sorry for no saying that above.
Moving your attention to the WPI library where can we switch the motor direction? We also have an issue with reuploading / recompiling the library. |
Re: Problem with Motor direction
This is pretty tricky, we had the same problem our first year, you will want to put encoders on the motors for sure. they don't have the same power going forward and backwards, i am assuming that you are not orientating them the same way. If you don't put encoders on, one side will turn faster than the other, and inevitably cause you to turn.
|
Re: Problem with Motor direction
Quote:
- Austin |
Re: Problem with Motor direction
WinRiver: C++. I'm sorry if i misspelled that.
|
Re: Problem with Motor direction
Oh, ok. I'm sorry, I can't really help then. :( I don't really know much C++. Hopefully someone who knows it better will pick up on your thread.
Good luck! - Austin |
Re: Problem with Motor direction
The WPILib "RobotDrive" class includes the ability to easily reverse motors in software. Normally this would be configured using a call to SetInvertedMotor().
WPILib code a docs: Code:
/*EDIT: After looking at the Default code and WPILib code, I found where it happens. For the right side, reversed is considered forward. So, if you want the right side to rotate the same direction as the left you need to call SetInvertedMotor for the right drive motor(s) and set them to inverted. You can see this in the function RobotDrive::SetLeftRightMotorSpeeds. Bold comments mine Code:
/** Set the speed of the right and left motors. |
Re: Problem with Motor direction
Quote:
|
| All times are GMT -5. The time now is 05:07. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi