Inconsistently rotations in base motors before and after adding lift controls in code

Hello! I’m not sure whether I should post this here or in the RobotC section, but here I go

We have a robot that utilizes 5 motors on our lift and 4 for our base. The four base motors are 393 motors. These base motors are not configured for speed and are in high torque and have mecanum wheels on them . The motors are programmed for Tank controls (left and right joysticks individually moving each side) and pressing 7U and 7D allows the wheels to strafe right and left.

Our problems

-When we only include code for base controls (excluding the lift), the base moves forwards and backwards perfectly fine, but shows irregular movement when we press 7U and 7D (Strafing).

-When we include code for both base AND lift controls, the base motors don’t go smoothly forward/backward (with the joysticks) and they stutter a bit (the motor isn’t shaking but stuttering as in the movement of the wheel chokes up often) but they move perfectly when we strafe (with the buttons 7U and 7D)

Help would be greatly appreciated!

It sounds as if you are setting some motors to multiple values in a single loop cycle (perhaps one of those values being 0). Could you post this entire portion of your code so that we can see exactly what you have, and hopefully find where exactly the problem lies?

Going along with what Jordan said try to ensure that the motors don’t receive more than one command per loop cycle. Like this pseudocode

{If(button7u or button7d)
Your strafing code
Your tank code}
That means. While strafing don’t accept tank commands. In particular this would interrupt you driving normally to strafe if both are being used at once.

Thank you, both of you were correct, the motors were assigned to two different values under the same loop

motor[port1] = vexRT[Ch3]; // Tank control

motor[port1] = vexRT[Btn7U] * 127 - vexRT[Btn7D] * 127; // Strafe

When we were using tank control, the buttons would be 0; the motor was told to be 127 and 0 at the same time, you guys were both exactly correct. Again, thank you guys alot!

My teams make this simple mistake quite often!

The way I see Jpearman usually code to avoid this issue is rather then setting the motors in your code set a place holder variable.
something like left_chassis or right_chassis
and then at the end of the loop update the motors to equal these variables. This way your robot will work its way through the entire loop before setting the motor power.

I either do it ^that way or code the logic in a way such that motors either are set by 1 bit of code OR another.

and as an example of that from the “open source robot” code.

/*  Drive control task                                                         */
/*                                                                             */
/*  Uses joystick Ch3, Ch4 and Btn8L, Btn8R                                    */

DriveSystemMecanumDrive( )
    short   forward, turn, right;

    long drive_l_front;
    long drive_l_back;
    long drive_r_front;
    long drive_r_back;

    // Get controller
    if( abs( vexRT Ch3 ] ) > 10 )
        forward = vexRT Ch3 ];
        forward = 0;

    // strafe
    if( abs( vexRT Ch4 ] ) > 10 )
        right = vexRT Ch4 ];
        right = 0;

    // turning on buttons
    if( vexRT Btn8R ] == 1 )
        turn = 64;
    if( vexRT Btn8L ] == 1 )
        turn = -64;
        turn = 0;

    // Set drive
    drive_l_front = forward + turn + right;
    drive_l_back  = forward + turn - right;

    drive_r_front = forward - turn - right;
    drive_r_back  = forward - turn + right;

    // normalize drive so max is 127 if any drive is over 127
    // I removed this code for clarity in this example ..........

    // Send to motors
    // left drive
    motor MotorLF ] = drive_l_front;
    motor MotorLB ] = drive_l_back;

    // right drive
    motor MotorRF ] = drive_r_front;
    motor MotorRB ] = drive_r_back;