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
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?)
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.
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)
Else If (Down ==1)
Else If (Left == 1)
Else If (Right == 1)
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.