Just saw someone talking about this in another thread, and without reason the next day, similar things started to happen to our drive.
Taka a look:
I’m not sure why this is happening. Our drive used to be very smooth and responsive just a couple days ago. We’ve isolated the problem to be the motors, as we tried different motor controllers and cortexes. Any solutions?
We are actually also experiencing the same problem, but on our catapult. We know it is not the code because it runs the same exact motor commands as the other 5 motors on the catapult. The strange part about ours is that when we run the drive, it also makes the “problematic” motor twitch, meaning when we drive, it initiates this twitching. It also happens with running the catapult. We’ve tried different motor controllers. Any suggestions?
I’ve talked to some people about this, and @PixelToast says that the new RobotC update could be inducing context switching, meaning that since we have an infinite while loop with no delay, RobotC stops my code to let the CPU handle other tasks. So apparently I need to add a delay at the end of my while loop. This seems like a possible solution that could be tested true if we just initialize motor speed to be 127 in task main and have an endless while loop after it. Still, IDK, I feel like this may not be the right answer, however it seems very plausible since the only variable that’s changed since it was working is the new update.
I initially thought that the code was setting two different values at once. It’s not. In the video, we moved Joystick Ch3 to 127 and not the buttons. Since no button was pressed, motor2 was only updated by vexRT continuously.
It’s actually not redundant. The only thing it can do is make the problem worse.
In the video, you can see that I only use the joystick. With my current code, the vexRT should update a motor and since we don’t press any buttons the code shouldn’t update anything else. But, with your code, (of adding an else statement) the motor will constantly switch from 127 speed to 0 speed. However good idea.
I would’ve used much better code to test it. Code that deosn’t have as many things that can go wrong. The thing is, I won’t be able to test anything until monday. I’m trying to give you guys the most accurate description of the situation possible, so that you are able to debug everything that could’ve gone wrong properly. If I could test new code now, I would do it.
Unpressed buttons constantly send 0, so an else statement would definitely create an issue where motor would be set to the value of Ch2 and whatever the else value is. Given that the motor in the video is constantly receiving a 0 value in addition to the Ch2 value, I’d say that your if statements are causing the problem (even though they should only be true when the button is pressed.)
I am not sure why you want a motor controlled by both buttons and joystick, but you can combine the code to one instruction to eliminate the spaz. This is the same as what (I think) you were trying to write:
I think the gear might be stripped in the motor. The dome shaped teeth are never good they can last for a little while but then they stripped. Always when you buy the motors remember to change the internal gears to the straight teeth.