Quote:
Originally Posted by emmell
All:
Welcome to another episode of CSI: FTC. Excellent posts and great detective work.
Phil: Listening to the sounds of the movie you posted, it sounds as if you are manipulating your arm at the time of the "File Error". Maybe there is something that is causing a electric surge on the NXT cable from the motor to the controller to the NXT. Are all your cables okay? Any static issues possible? (I know that's an FRC issue this year). The observed behavior is that something is causing the NXT to abnormally terminate your teleop program. This kind of thing needs to get sent to PITSCO and HiTechnic (and maybe even NI) as this appears to be a problem with hardware causing the fault.
Mannie
|
Hi Mannie.
You've got a good ear. Yes in this instance it happened just when the arm was moving. It is possible that this is a common occurance, although it's hard to say because the fault is only really apparent when a motor screws up. The previous sound also indicates that the wheel drive had reached it's endpoint but had not been taken out of "servo" mode, so it sat there humming until the NXT timed it out. So it's likely that the actual problem had occured earlier, and it wasn't until the NXT commanded the next wheel movement (after the arm move) that the File Error occured.
Our wiring is pretty good (all tied in place, and protected from vibration etc) but I know that these motors can surge a lot. One problem with the very strict FTC rules is that there is no opportunity to use good electrical practices to minimize possible problems on a larger robot. For example, is it's required to daisy chain the power through all the controllers. The rules prevent using heavier guage wire, or making any soldered distribution bus to give each controller it's own dedicated power lines. I cringe at the current surge that must be going through the first set of screw terminals. I also wish that I could use a resettable fuse (like FRC) on the motors to prevent that horrible burned wire smell from being set free.
My problem is that the fault is random, and unlikely to be able to be replicated by Pitsco or NI. When doing my earlier encoder tests, I was able to generate some good plots showing the problems, and these were generally addressed by NI, but now they are less reproducable.
As you imply, I do think that the robot structure and code complexity is causing a problem.... just HOW is the question.
One problem with the NI code is that there are lots of places where there is an "error" output from a particular VI. The issue is: what does this mean, and what should we do about it. If a move command generates an error output... is there really any way to recover? probably not. I should probably just abort Auto and wait for teleop.
Both NI and Hitechnic have been helpfull, but both imply the problem lies with the other's equipment. No-one is eager to step up to be the systems integrator and really address the problem. It appears to be falling on the end-user to do this.