I’ve been recently working on my Toss Up robot and I have been getting some weird problems with my motors…
What’s been happening is that all my motors have been “jumping”
Ill be trying to drive my robot and all the motors get these spontaneous “jumps” or “skips”… Is hard to explain
I don’t know if its my programming or if my motors need to be replaced…
Two requests. Can I see whatever code you’re using, and a video of the robot doing this?
Last time we had a problem like what you described, it was because we had something like 8 “IF” statements in the driver section of the code. Cleaning it up with “If/Else” statements and removing out LCD menu code from Driver Control fixed the problem.
here are some things to look for:
too much friction in the wheels
motors overheating
bad vexnet connection
bad motor connections
bad coding (try a simple code that just runs the motors non stop and see if it still happens)
bad motors (the internal gears are messed up)
bad drivetrain (something is getting caught in a gear perhaps?)
and the second one I took an outside motor to see if it was the motors, the programming, or the brain of the robot. What happened was that the outside motor was skipping as well!
I’m thinking it’s either my programming or the brain because there was no skipping when I shot the last video w/o the mecanum wheels.](http://www.youtube.com/watch?v=q43fvktR5r8)
Okay, I was wrong. I currently see two problems with your code
You have an Else statement which should be an “Else If”. An else statement says “If the “If” condition is not met, do this.” An “Else If” does a check only if the first “If” statement isn’t true, which is what you want. Just change it and you should be fine.
You also have an extraneous semicolon after that Else statement. It’s not causing any harm, though.
That was an interesting bug, two wrongs making a right. Missing out the “if” after the “else” but then adding the semi-colon gave you the following code.
is valid C code so the compiler compiled it. The compiler did not know what to do with the result, it could have been part of a statement like this.
a = (vexRT[Btn8R] == 0) ? 10 : 11;
or this.
a = (vexRT[Btn8R] == 0);
so it compiled what it could and then just threw away the result. It’s not a bug in the compiler, the same thing happens in gcc, it’s just incomplete code.
Sorry for it being upside down but I think you guys can see the problem. It tends to not go in a straight path when straffing. So do I just change the motor values or is there an easier way?
This is the discussion we were having about center of gravity issues with Mechanum wheels in your other topic. If you balance it out correctly, it will strafe in a straight line. Otherwise you have to deal with the arc-strafing.
Changing motor values would probably work, but there is absolutely no point until you have the entire robot built. Additionally, the variations in CoG due to your arm shifting and the posession of game objects will make the programming even more difficult. It could maybe be done with enough conditional statements and sensor inputs, but you’re potentially looking at a huge project.
None of the “If button is not pressed” statements are necessary, and they are in fact causing your problem. You should have something like this instead.
[Code]If(Up == 1)
Drive forward
Else If (Down ==1)
Drive backwards
Else If (Left == 1)
Drive left
Else If (Right == 1)
Drive right
Else
All motors zero
The way your code works now, four conditions are always true. Three of those tell all of the wheels to stop, one tells them to move. Code it like I have above (even the last "ELSE" statement could be removed, I think) and only one condition will be true at any time.
Let me know if that works.
I just deleted two posts out of this thread which were off-topic and distracting from the original request. Other users may be interested in seeing how this problem is resolved, without the topic degenerating into private discussion.
Are you using tank or acrcade for your control? Below is what we used for tank control and it worked well. It takes both joysticks being moved to left or right to scrafe, we had thought about making just the right joystick controll the scrafing so we had proportional control over something else with the left if needed. You may not always want to do a full speed scrafe, and having the left and right on separate joysticks will help compensate for any CG issues that may continue to cause the arcing even after you are done building. Hopefully this will help. We had to change the “+” and “-” on the left side when we put it on our “X” drive to get it to behave they way we wanted.
I am using the facebuttons but just to test the programming and the robot but for competion it probaly will be a good idea to put a tank control on the joysticks as well as when both joysticks are right or left then the robot strafes according to the corresponding joystick action.
So the problem for wheels skipping and jumping are because of too many if and if else statements?
Is that usually the problem?
If you guys want to continue the talk about the robot and not wheels jumping then I will put a link to my summer robot reveals and conflicts. Sbd and Ephemeral already know where the thread is but if anyone else would like to check out the robot we are talking about here is the thread:
The joystick controls won’t require the if/else statements so that is not an issue. I will copy and paste the code we used with Mecanums for a Sack Attack robot. If one of the joysticks is backwards just change the +/- signs around.
Have you tried redoing your code in the way I posted? I explained why what you were doing caused the wheels to jump.
Generally, people don’t control their wheels like this, and therefore don’t have this problem. We did something similar last season, though, and I’m using my experience from that project to help here.