Last week at at the Worlds, my son’s team had bizarre problems (including a motor that used to move to a stop using setMotorTarget(armMotor, 475, 100) and when that motor had to be replaced, the new motor would stop 10 deg short - how could changing a motor affect the encoder degrees ??)
In any case, the problem that caused them to lose major points was that command executing randomly. We had taught the kids to use waitUntilMotorStop after setting the drive motors to zero and then raise the claw, but when that worked randomly, they changed it to waiting (upto 1 sec) after setting the speed to 0, then issuing the above command and waiting again instead of checking for motor stop. Very bad practice, but they were desperate and this is what they used to do in ModKit to get it to behave. With time running out they tried it on the practice field and it worked so they rushed off to the skills area.
Sure enough, they waited in line at skills, when they were up they started the Robot - and it grabbed the blocks, dragged it over to the green base not having raised the arm and proceeded to collide with the green base. End of story.
This was an absolutely basic, brute force, method of raising the arm and it still responded un-predictably. We had spent a lot of time getting the kids on a learning curve on RobotC starting with graphical mode, converting to text and supervising edits for the ‘better’ way to do things, only to have to fall back on this and still not have it work.
I cannot imagine what could be happening here. The only other process was a task that read the gyro and timer 1 and applied a correction for drift - because the VEX gyro drifts an insane amount.
Any feedback would be appreciated. I am thinking about investigation Python or something as a better solution. Really thought that RobotC with its Carnegie-Mellon pedigree would be gold …