[Greg McKaskle]

My text is marked with ***'s.

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.
*** The original post said it was 1.5 min. I measured it at 0.5. I'm sure a 1 second boot would be nice, but it cannot happen. I suspect it could be a few seconds shorter, perhaps as much as ten seconds shorter, but at this point the breakdown in my post was as much info as I have. To modify the image, leave out libraries, or modify the communications task are major undertakings. The other way to look at this is that this affects all teams the same. If the weight limit is changed or the field size changed, it may not be a good compare to prior years, but it is fair because all teams are affected equally. More on this in the micro line below.

1B: My download times appear much greater than you stated, ...
*** If they are different, I'll be happy to help you determine why. My test was with default code and used deploy, not Run As Startup.

1C:The IFI system sent packets every ~26 ms. The RS422 900mhz radios sent exactly the data that was needed ...
*** Personally, I don't think the current protocol sends enough info. The FTC protocol similarly sends about 20 bytes of data, but that has much more to do with transmission speed limits than it being exactly what was needed. I won't claim to be a wifi wizard, but once you start sending framed data, I believe that it is equivalent to send one byte as to send one full frame. I do not think the network speed or the control packet being sent is responsible for the lag you are seeing.

... 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.
*** I can't debug it with this description. With the right camera settings, I can cause video lag. I can roughly pin this on a memory manager issue, and in another thread I gave compression numbers to avoid the issue. Similarly, we found some DS UI code that could cause lag on the DS consumption of the video. The latest DS update resolved the issue. If you are having joystick lag, it would be good to run some performance tools to get some data on what your app is doing.

IIA: We have to reboot Driverstation after every match to get to loose the FMS lock (another annoying feature)
*** As explained in the other post, FIRST sees the exit/open DS as necessary for safety of field staff and team members on the field. I can't explain the exact benefit, but I think we can all agree that safety trumps convenience. But of course we really want both.

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.
*** This is being discussed in another thread, but is not something we've been able to reproduce. If you want to answer questions on the other thread, they may help to pinpoint the issue.

IIC: We come off the field .... 45 seconds is DEATH.
*** Actually, death is what could happen when not enough attention is paid to the safety issues -- death is still probably still a stretch of course. I believe the best approach is to state the case to FIRST. It is their call.

IV: The cRio has a 400mhz processor, ...
*** I would guess the experiences are different in many respects. If/when NASA sends astronauts to the moon again, I highly doubt they'll use 1MHz 2KB computers for the guidance system. Times and capabilities change. The upside includes things like floating point. The downside includes things like boot time.

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.
*** Where are you placing the probe, and when are you probing? I often have a numerous probes set before I even boot the cRIO. I suspect that you've found a timing issue with the RT protocol in LV, but it would certainly be helpful to have more information to narrow it down.


@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.


@Greg again: f1 re-enumerates JS's? Does it find the Cypress board again?
*** The DS doesn't explicitly find the Cypress board in the first place, so no. F1 explicitly closes, enumerates, and reopens joystick HID handles. The DS would do this continuously, but it takes around 100ms to enumerate the USB bus devices. For this reason, it does this once a second when disabled, but only when requested during teleOp.

Greg McKaskle