VEX V5 TEXT Task Scheduler seems to have an issue

Programming Support VEXcode Pro V5 Text Tech Support
#1

I have come across a problem in task scheduling in the V5 Text code. I found out that I do not have to use tasks to do driving while doing other things so I took it out. I finally realized what is going wrong and want to confirm my thoughts.

It turns out that when I use the DriveRobot function shown below within a spawned task, it never gets control back after doing the wait(xx,msec) and the motors keep running forever.

The autonomous code spawns the drive task to drive for 2500 msec and does other things, then waits for the drive to be complete by using the bool AutoDriveDone = true to signify completion which never happens since the drive robot function never gets control back to stop the motors.

I am using the code “while(!AutoDriveDone){}” to wait for completion. Nothing in this loop causes a wait so that the only way the AutoDrive task can get control is for the time slice interruption to occur an have the task scheduler make the AutoDrive task active which never seems to happen. It seems that the time slice interruption is not happening or the task scheduler is not selecting the proper task to run after the interruption and goes back to the while loop rather than the wait in the DriveRobot function.

I could probably get around this by putting a short wait inside the while braces and hope that the task scheduler switches tasks correctly. I may try this after State unless I get some time to play before that.

Right now I do not need this to work as I have gotten autonomous routines to run in less than 15 seconds but would like to report this to someone as I believe that this uncovers an error in the task scheduler code inside the V5 Text program. It may not be scheduling correctly the tasks in other situations.

Any ideas on who to report this to? I will try to use their feedback procedure and see if anything turns up.

Dennis Team VEX 1102X

Here is a snapshot of the code I am using:

bool AutoDriveDone = true;

int AutoDrive1(void){ AutoDriveDone = false; DriveRobot(80,0,2500.0);return 1;}

////
// Drive robot using the data passed to it //
////
void DriveRobot(int Forward, int Turn, double DriveTime) {
int RightPower = Forward - Turn; //* Right Drive //
int LeftPower = Forward + Turn; // Left Drive //
// Now go set the motors as desired *//
LeftDrive.setVelocity(LeftPower, percent);
RightDrive.setVelocity(RightPower, percent);
LeftDrive.setMaxTorque(100, percent);
RightDrive.setMaxTorque(100, percent);
LeftDrive.spin(forward);
RightDrive.spin(forward);
if (DriveTime == 0.0) { AutoDriveDone = true; return; }
// wait before stopping the motors
wait(DriveTime, msec);
LeftDrive.stop(brake);
RightDrive.stop(brake);
AutoDriveDone = true;
}

void AutonomousBlueLeft(){
MoveCubeAway();
AwakenStepOne();
StartIntake(100);
task AutoDrive11(AutoDrive1); //* Go Forward 40 inches NEVER STOPS DRIVING***
AwakenStepTwo();
while (!AutoDriveDone) {}
StopIntake();
…More Code
}

1 Like
#2

you can’t do that. It’s a cooperative scheduler not a preemptive scheduler. You must use yield, sleep or an API call inside a blocking loop.

That would be me, I wrote it.

2 Likes
#3

Off topic, but you can wrap code in [code] //Code here [/code]

#4

Thanks, so what I hear is that there is no time slice interruptions to be able to reschedule tasks and that there has to be some kind of call that allows the scheduler to get control. Is adding a wait(20,msec); inside the braces sufficient to allow the scheduler to work?

Dennis VEX 1102X

#5

that would work.
or you could just call task::yield()
or block on a mutex (which is pretty much what you are trying to do by using a global variable)

The scheduler does use a type of time slicing, it will only allow a task to run for (usually) 2mS if no calls to yield or sleep are made, but to be able to do this something in the vex API has to be called so necessary checks can be made.

3 Likes
#6

Thanks James,

I guess I am used to preemptive scheduling and never thought about this until our robot would not stop driving . After thinking about it I came to the same conclusion when it did not work. I was not sure if it was supposed to work or not but decided to report it, just in case. Sorry to have stirred the pot. :wink:

#7

no worries. Cooperative schedulers get a bad rap, but there are many advantages when used by novice programmers.

2 Likes