Quote:
Originally Posted by ptan
Testing on RobotC:
So far I have not yet been able to recreate Phil's FMS problem, nor have I seen the File Error problem to date. We are using RobotC, so that may be a factor in the system. I have experienced bluetooth problems when the NXTs auto power down.
Paul Tan.
|
That's good news because it probably means that my "fault" is not systemic. It may be localized just to complex LabVIEW code.
With only my "gut" to go on, I'm leaning towards the conclusion that the NXT Firmware that's required for LabVIEW has some sort of memory leak or other error that causes the program to terminate if it's been run multiple times without being re-booted.
It also seems that downloading a new program can cause simmilar issues unless the NXT is rebooted before running. I've seen this a few times.
It's quite possible that this problem is agravated by the complexity of our code in general, but my experience from testing today, is that if the NXT is rebooted EVERY TIME before a match, I never see the Program Abort (which seems to be due to the "File Error" problem).
My only concern is that if we have to wait too long before actually beginning Auto, the same problem may materialize. I only hope that the memory loss (or whatever) is due to something like memory not being freed up when the program ends..... Thus the first run should always be safe.
.. Some other stuff I've determined... that may only apply to LabVIEW
It seems llike the generic driving "Glitches" that we've been experiencing may come from incomplete motor commands reaching the controller. The Hitechnic motor controller is not able to tell when a full message has been received, so if only some of the bytes arrive, the controller acts on them anyway. If these bytes are part of a "Specify Position" type command, then the command is only sent once and consequently if it's incomplete, the robot will go to an incorrect encoder destination.
Instead, by continually resending the desired command, I've been able to completely eliminate any erratic drive actions. I split the "Specify Position" VI into two parts. One part to set the destination, and the other part to check if it's reached it yet. I can now call them in a loop without "blocking", to reinforce any incomplete command transfers. By intermixing both Wheel and Arm commands I can command both systems to move simultaniously, with them both stopping automatically when they reach their target position.
A sidebar to this discovery is that anyone who has been doing their own "drive and check encoder" loop probably hasn't seen quite as many driving glitches, because they have been overwriting any partial commands.
With these latest code changes, and some other timeout tweaking, we're feeling a LOT better about our BOT's Auto performance. We did several tests of each of our 8 Auto modes (red/blue, floor/ramp, score/spoil), and never saw a single glitch.
Phew..... Things are looking up
