When using encoders the motors tend to get “locked” they won’t move. I feel that it’s because they’re not resetting, but I’m not sure. I’m programming on VCS c++pro, if that helps. I’m still new to encoders and having a bit of difficulty understanding them, and revolutions
are the motors physically locked, or does something in the code make them move incorrectly
Are you using rotateTo when you mean to use rotateFor?
Would it be possible to post your code?
When I try to move the bot physically it’s like it’s just stuck, it could also be the code I’m sure it is but I’m not sure what part
Yeah I’ve been using rotateTo since someone explained that would work but I’m not sure
When rotateTo or rotateFor finishes, it stops the motor in a hold position mode. Tell it to stop with a coast mode to release the hold.
[quote="[TVA, post:4, topic:52046"]
Connor]Would it be possible to post your code?
[/quote]
At the beginning of the code I would use a Motor.setStopping(vex::brakeType::hold);
Does it matter if you use rotateFor or rotateTo?
do the motors stick when the robot is off?
No it actually resets or if I disconnect the port it resets the motor, that could be the issue it not resetting
I’m not seeing it immediately. My worry about rotateTo was that sometimes people try to use it as rotateFor and don’t understand why it doesn’t work properly after the first one. That’s because it tries to rotate to a certain spot instead of a certain amount. So I had thought maybe you had rotated to a value and then tried that again, which would do nothing the second time.
I do see a few things to clean up. You seem to be using pct when you want rpm. You can’t get to 200% of the maximum speed. So drop those 200s to 100, or change pct to rpm. Also, I worry about that first vex::task::sleep(1500); because it may or may not allow the code before it to finish. You really don’t need it. Change your second rotateTo’s boolean to true and the code will wait for those two lines to finish before moving on to the next part, guaranteeing you the right amount of time. If you then want a small delay between stopping and the next part, you can put that in and know it will be the amount of delay you expect.
rotateFor and rotateTo ignore the default stopping mode set by setStopping and always hold. To have the motor do anything but hold after either rotateFor or rotateTo, you must call stop with coast or brake, or stop with no arguments after having set the default stopping mode to coast or brake.
With the default stopping mode as hold, it will also hold the motors if you call setVelocity with 0 velocity or spin with 0 velocity. That is, setting zero velocity will use the default stopping mode.