setServoTarget not working consistently

VEX IQ General Discussion IQ Technical Discussion
1

The setServoTarget command is not working consistently for us. When we start the program it works fine, but after what seems to be a random period of time it stops working. When the command stops working, it stops for all motors. Other motor commands continue to work, but not setServoTarget. Any insight on what might be causing this?
Below is a code snipit. Basically we are getting input from the joystick and using setServoTarget to open or close the claw and raise or lower the arm. The display shows the desired position as well as the current position. When we first start the program the robot responds to the joystick commands and the display is updated as expected. Then after anywhere from a few seconds to a couple minutes later the robot stops responding to the setServoTarget commands. The brain is receiving the requests because the display is showing changes to the desired position. Other joystick commands also continue to work - the drivetrain still moves. All motors stop responding to the setServoTarget commands at exactly the same time.
Thanks for any help,
Jerry

(using Robot C v4.26 or 4.27)

if(getJoystickValue(BtnRDown))
fSetClawPos = 0; // Close Claw
if(getJoystickValue(BtnRUp))
fSetClawPos = -250; // Open Claw
if(getJoystickValue(BtnLDown))
fSetArmPos = 0; // Lower Claw
if(getJoystickValue(BtnLUp))
fSetArmPos = -450; // Raise Claw

setServoTarget(clawMotor,fSetClawPos);
setServoTarget(rightLiftMotor,fSetArmPos);
setServoTarget(leftLiftMotor,fSetArmPos);

displayTextLine(1, “Clw s=%d a=%d”, fSetClawPos, getServoEncoder(clawMotor));
displayTextLine(2, “RLft s=%d r=%d”, fSetArmPos, getServoEncoder(rightLiftMotor));
displayTextLine(3, “LLft s=%d l=%d”, fSetArmPos, getServoEncoder(leftLiftMotor));

2

Hey jrp62,

It looks like this may have been accidentally double posted. I’ve replied in the other thread.

Thanks!

3

Thanks tfriez, I’m not able to reply to the post in the other forum, so I’m switching back to this one. I haven’t had a chance to try out the setMotorTarget command yet, but I did have some interesting observations. Could the issue be related to the motor temperature?

Yesterday when we started practicing the issue was occurring so frequently that we could not get as far as the driver hand off. My first thought was that it must be something that this particular driver was doing; some combination of buttons being pressed, or their order, or the timing. Switching the drivers seemed to improve the problem. Switching to a third driver the problem rarely occured. Later we switched back to the original first driver, but by then we could no longer reproduce the problem.

Prior to practice the robot had been out in a car in below freezing temperatures for a couple hours. Is it possible that as the motors warmed up, but problem went away?

4

Hi tfriez,

The following program can reproduce the problem. We tried substituting setServoTarget with setMotorTarget and the issue persisted. In addition, the motors seemed to move slower when setMotorTarget was used, even if speed was set at 100. I tested the following program on 4 different pairs of brains, controllers, and motors. It was easier to reproduce the problem on this year’s hardware. The issue is more likely to occur when the robot battery is low. Motor temperature didn’t seem to be a factor, what I noticed before was probably a low or cold battery.

Thanks
Jerry


#pragma config(Motor,  motor4,          rightLiftMotor, tmotorVexIQ, PIDControl, reversed, encoder)
#pragma config(Motor,  motor10,         leftLiftMotor, tmotorVexIQ, PIDControl, encoder)
#pragma config(Motor,  motor11,         clawMotor,     tmotorVexIQ, PIDControl, encoder)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//

float fSetClawPos = 0;
float fSetArmPos = 0;

task main()
{
    while(1)
    {

        if(getJoystickValue(BtnRDown))
            fSetClawPos = 0;      // Close Claw
        if(getJoystickValue(BtnRUp))
            fSetClawPos = -450; // Open
        if(getJoystickValue(BtnLDown))
            fSetArmPos = 0;          // Lower Claw
        if(getJoystickValue(BtnLUp))
            fSetArmPos = -250;  // Raise Claw

        setServoTarget(clawMotor,fSetClawPos);
        setServoTarget(leftLiftMotor,fSetArmPos);
        setServoTarget(rightLiftMotor,fSetArmPos);

        //displayTextLine(0, "Drv s=%d l=%d r=%d", 0, getServoEncoder(leftDriveMotor), getServoEncoder(rightDriveMotor));
        displayTextLine(1, "Clw s=%d a=%d", fSetClawPos, getServoEncoder(clawMotor));
        displayTextLine(2, "RLft s=%d r=%d", fSetArmPos, getServoEncoder(rightLiftMotor));
        displayTextLine(3, "LLft s=%d l=%d", fSetArmPos, getServoEncoder(leftLiftMotor));

        //Wait the timing interval
        wait1Msec(25);
    }
}
5

Hey Jerry,

Yeah - I’m pretty stumped to why the motors would be cutting out. Luckily, there’s some status variables we can monitor with the motors using ROBOTC. I’ve thrown together a test program that runs as a separate task (so it won’t interfere with your main code) and will output data to the global variables debugger window.

Just add your program to “task main” and keep the “startTask” command at the top. Then, while your program is running - keep an eye on the Global Debugger window and see if any of the variables (Specifically current limit / motor temp) switch to reporting as “true”.


bool bMotorCurrentLimit[12];
bool bMotorTemp[12];
bool bMotorZeroPosition[12];
bool bMotorZeroVelocity[12];

task monitorMotors()
{
    TVexIQDeviceTypes nDeviceType;
    TDeviceStatus nDeviceStatus;
    short nDeviceVersion = 0;

    while(true)
    {
        for(tMotor theMotor = motor1; theMotor <= motor12; theMotor++)
        {
            getVexIqDeviceInfo(theMotor, nDeviceType, nDeviceStatus, nDeviceVersion);

            if (nDeviceType != vexIQ_SensorMOTOR)
                continue;
        
            bMotorCurrentLimit[theMotor] = getMotorCurrentLimitFlag(theMotor);
            bMotorTemp[theMotor] = getMotorOverTemp(theMotor);
            bMotorZeroPosition[theMotor] = getMotorZeroPosition(theMotor);
            bMotorZeroVelocity[theMotor] = getMotorZeroVelocity(theMotor);
            sleep(5);
        }
    }
}

task main()
{
    startTask(monitorMotors);

    //Add your code here.
}

Let us know if you find anything out using this. Thanks!

6

Hi tfriez,

Keeping the battery above 80% charged seems to resolve this issue. I haven’t had a chance to test the motor monitor thread, and probably won’t need to unless the issue returns.

FYI for other teams - check the battery voltage by going into the “System Information” screen on the brain, rather than just looking at the battery icon. The battery icon looks full even when the battery is only at 70%.

Jerry