Strange problem with autonomous

Programming Support VEXcode V5 Tech Support
1

We have several autonomous routines that we have been using all season long without any problems. Our code only does basic commands such as resetRotation, RotateTo, etc. But we have had a strange problem come up a couple of weeks ago with a specific routine and I thought I’d post it here to see if anyone has any suggestions as to what we might try.

The problem is that this one routine we have put together simply stops at the exact same point about 50% of the time. This would be easier to troubleshoot if the problem occurred all the time or not at all . We will try something new and think the problem is fixed after several successful runs, but then the problem starts back again.

Here is the code the routine starts with:

LeftFrontDriveMotor.resetRotation();
RightFrontDriveMotor.resetRotation();
LeftBackDriveMotor.resetRotation();
RightBackDriveMotor.resetRotation();
LeftFrontDriveMotor.rotateTo(200,rotationUnits::deg,25,velocityUnits::pct,false);
LeftBackDriveMotor.rotateTo(200,rotationUnits::deg,25,velocityUnits::pct,false);
RightFrontDriveMotor.rotateTo(200,rotationUnits::deg,25,velocityUnits::pct,false);
RightBackDriveMotor.rotateTo(200,rotationUnits::deg,25,velocityUnits::pct,true);
//Here is where things stop if the problem occurs
LeftFrontDriveMotor.resetRotation();
RightFrontDriveMotor.resetRotation();
LeftBackDriveMotor.resetRotation();
RightBackDriveMotor.resetRotation();
/* Pick up the row of four cubes */
IntakeSpinMotor.rotateTo(2500,rotationUnits::deg,85,velocityUnits::pct,false);
IntakeSpinMotor2.rotateTo(-2500,rotationUnits::deg,85,velocityUnits::pct,false);
RightFrontDriveMotor.rotateTo(630,rotationUnits::deg,15,velocityUnits::pct,false);
LeftFrontDriveMotor.rotateTo(630,rotationUnits::deg,15,velocityUnits::pct,false);
//(much additional code follows after this

This code is during the 1 minute timed skills routine. When we say the program suddenly stops, the countdown doesn’t stop - it’s just that the next statement doesn’t execute. There have been only 2 or 3 times that, after an extended pause (anywhere from 2 to 5 seconds), the program will actually continue and finish. This got us to thinking tonight that maybe we have a bad cable somewhere with an unreliable connection. But if this is the problem, it only happens on this one routine.

We have tried using a different Brain (in case the firmware has somehow been corrupted). We have confirmed that wireless connectivity to the controller is maintained throughout. We have tried pairing to a different controller. We have replaced all of our smart cables with new ones. We have tried putting the program in different slots on the brain. We’ve tried replacing the motors. We’ve tried compiling with both VCS and VexCode. We’ve tried commenting out all other code other than what we posted above. But nothing seems to remedy this problem. It’s hard to understand how the program will work some of the time and simply stop executing others - without any code changes being made. If we literally run the routine 20 times, it will work fine about half of the time. There are no similar problems in any of our other routines or in driver control.

At the moment, we are thinking the problem is just buggy V5 language and that maybe we can fix this by adding in an abundance of brake commands , sleep commands, etc. to make quadruple sure that no previous command is still executing or overlapping. I don’t think we should have to do this, but are lost as to what else to try next. In troubleshooting,/testing, we have been able to change some of the code (i.e. the direction and velocity of the motors) and, after this, the problem sometimes seems to not occur as often. In fact there have been several times that we thought we had eliminated the problem , but on attempt number 7 or 8 the problem would return.

If anyone has also experienced this or has any thoughts on what we might try, we would love to hear any suggestions.

Thanks so much!

2

I’ve have had this exact issue before, and I think it is due to the motors getting hot. not sure how this causes that to happen, but it started up after a long coding session where our drive motors were hot. they weren’t that hot, only like temp level 2, but they would run a blocking command, and just sit there instead of moving on to the next. letting the motors get cool always seemed to fix this issue, but this could just be a coincidence. @jpearman might be able to provide some insight.

3

The motor power for the drive forward at 15% normally works? Seems low . Could it be too low to move against the resistance of 4 cubes?

Did you clip the motor commands for the rear wheels, or are you asking the front wheels to drag the rear? If your brakeType is hold, that could be a problem. The LeftFrontDriveMotor command is non-blocking. Can’t see what you have after, but normally you would have that as blocking.

4

It got to be RightBackDriveMotor.rotateTo(200) call because it is the one that has waitForCompletion argument set to true.

I like @Xenon27 idea that it could be something to do with motor overheating, that inhibits V5 builtin motor PID from reaching the target.

Please, first consider trying changing it from using individual motor statements to drivetrain.
https://api.vexcode.cloud/v5/html/annotated.html

If that fails too then you can change waitForCompletion to false and add timeout. In the event V5 PID gets stuck you will wait an extra second or two and then will keep driving.

If you abandon V5 PID and need check for encoder position and step time then reading this conversation will be useful:

5

As an extra suggestion, put a miniscule wait command between the commands for the motors, so they aren’t continually jerking forward and back. Also, out of curiosity, why is the final motor command on the second to last line set to false? Wouldn’t you want it to finish before you continue? 'Cause if so, the rest of your code could be fighting it. Just speculation, so please correct me if im wrong. I don’t want to accidently give false info.

Clarification: i say “fighting itself” because your code might be telling the motor to do something different before it finishes that command, so it has conflicting instructions.

6

And your code will be easier to read if you put more empty lines between sections of code and put comment explaining each one. (Easier to navigate and reread your own code that way.)

7

This may be confirmation of my previous post…
Is the next statement that actually does execute commanding LeftFrontDriveMotor? If not, then I’ll bet your conflicting commands finished, so the motor is no longer “confused” and the code is free to continue.

More speculation, I ain’t an expert on code, so nothing I said is set in stone, but check it out. :slight_smile:

8

As others have suggested, the call to RightBackDriveMotor.rotateTo will block if the motor never reaches its target position.

A call to rotateTo instructs the motor to move to the requested position. The code then monitors status of the motor until what we call the “zero position flag” is set or a timeout condition is reached. When a motor instance is created the timeout is actually set to disabled, there seemed to be no good value for it and we leave it to your code to call the setTimeout method with a reasonable number. The motor uses its PID algorithm to try and achieve the target position and set the “zero position flag”, for the motor to complete the move it must be within 3 encoder counts of the final position, with the green gear cartridge that is less than 0.01 of a revolution. Depending on the load on the motor that may not be achievable, as @Xenon27 mentions, it could happen if the motor has become hot and power is being limited. It could also be caused by excessive friction and a number of other factors, that’s why we provide both a timeout and the ability for your own code to monitor progress and choose to abort if necessary.

9

Everyone, thanks so much for the detailed responses. These were immensely helpful in leading us to figure out this problem. The problem turned out to be that that last rotateTo command (with the completion switch set to true) was not always completing. It got very close to completing and sometimes did actually complete - which was what was giving us the mixed results in our testing. We changed to a spin command and the problem completely went away.

It’s amazing to me how much you sometimes have to go through to figure out a problem like this! But, we are now more experienced and are better off for it. in fact, we hit a similar situation again just over this past weekend - but we knew exactly what was going on and how to fix it.