Quote:
Originally Posted by PhilBot
Hmmm. I had reported that to NI a while back. I found that the "failure to reset" seemed to be related to the speed that you commanded the motors to move afterwards.
If you sent an encoder reset command, and then gave the motor a high power move, it was more likely to ignore the reset state and revert back to the last encoder count. However, if you only gave a low power move, it seemed to keep the reset most times.
It's as if there is some race condition that if the encoder counts before the reset is complete it gets messed up.
I've really been hoping that I could use LabVIEW for both FTC and FRC, but if it's not reliable I'm going to be forced to change.
Any issues to report with RobotC?
|
That sounds very much like what we were trying to do: come down the ramp slow, reset encoders, then go full power.
We've spend very little time and effort on RobotC so far. It blows my mind when it compliles and downloads in about 1/2 second.