Comments/Complaints on NI control system

[apalrd]

@Greg:

1A: 30s is death in the pits. The IFI system could be up and running in under a second on tether, 5s on radios. 30s or more is waaaay too much time.

1B: My download times appear much greater than you stated, although I could attribute that to the 5 people standing behind me saying "WHEN CAN WE TEST THE ROBOT!!!! GET IT DOWNLOADED NOWWWWW!!!!! GET IT THERED AND MOVE THE ARM NOWWWWW!!!!" while waiting for my code to download.

1C:The IFI system sent packets every ~26 ms. The RS422 900mhz radios sent exactly the data that was needed in one fairly small packet to and from the robot. Data to the robot was 26 bytes in one packet, data back was 2 26 byte packets (most of the data back was exclusively used by the Dashboard). I do not know the latency on it, but it wasn't much. As for the new radios, we had noticeable control lag when using the camera on the Dashboard, but only on the field. This lag was aprox. 3 seconds. I can't say for sure what the cause is, but I can say it appeared when we added the camera and was fixed after we removed the camera, leading me to believe it was the camera.

IIA: We have to reboot Driverstation after every match to get to loose the FMS lock (another annoying feature) but sometimes we do reboot it. If it goes on to the field shut down, it will not find the Cypress board and we are dead.

IIB: This is why we are looking for a solution to the Cypress board, and this almost cost us 2 matches.

IIC: We come off the field with back-to-back matches and have to change all four bumpers, tether the robot to move the arm, change the battery, and get it ready to play again in 5 minutes. 45 seconds is DEATH.

III: Our radio had a loose terminal during one match (duck tape fixed this) and after loosing comm once it had no possibility of ever gaining it again during that match. We tied that match after playing 18 seconds.

IV: The cRio has a 400mhz processor, and while it has aprox. 30% free space (shown during Deploy) it is still not using nearly the power it has unless doing vision processing. We had a crab-drive last year using this system. We needed to do some trig calculations. Even with the IFI processor back when we built a crab drive in 2005, we had plenty of power to do trig calculations with lookup tables and it worked great. That was an 8-bit PIC with far less power or code space then the cRio, but it performed the same task just as well.

IVB and IVC: See IIC

V. If I place a probe on a VI before the "Robot Code" light on the Classmate comes up, LV will crash on my PC. Guaranteed. Always.


@Dave: I would like to see it reset to Teleop after comm or code loss, but not after disable. I often set controls on my VI's for commonly changed parameters (e.g. distance or kick force) and change them while the code is running. I often run autonomous for many times in a row when debugging it, without ever changing to Teleop or downloading new code.
Spacebar disables the robot without e-stopping it. The e-stop button killing code annoys me too, but I have actually used it before (the Toyota bug) so I wouldn't get rid of it.

On the Stop button acting as an E-Stop: Sometimes if the robot spontaneously acts wierd and needs to be stopped, it is nice to be able to probe everything to see what it is trying to do and find your problem. We have an arm on our robot with 800:1 off a CIM, and it has enough torque to cause damage to many parts of our robot. If it starts destroying something, we want to be able to probe it to see where our problem is. We had this exact issue, and found that the analog module on the cRio actually ejected from the cRio.

@Greg again: f1 re-enumerates JS's? Does it find the Cypress board again?

@Everyone: Did anyone notice how nobody EVER debugged comm or firmware things EVER with the IFI system, and how it just always worked? I do not see the cRio or the entire control system as designed to handle the rigorous environment that is FIRST, nor see it as better than the IFI system. Everything, except vision, that we are doing now could be done just as well on the IFI processor. Vision could be done too, using the CMUcam. Now, we are doing vision and other complex processing using many times more code space on many times more expensive equipment, yet achieve the same result, sometimes worse. I am not against using the cRio as a robot controller, most of the cRio based things except for download and bootup times are quite nice to work with. The whole system is not designed to work together; it is a bunch of off-the-shelf stuff that people are trying to make work together. None of it is designed for competition robotics, and can't handle the demands we place on it like the dedicated robot control system provided by IFI could. This all leads to another problem: Since the control system is not made by any one company, it is hard to lay blame for failure on any company.