Quote:
Originally Posted by Greg McKaskle
At this point it seems like the dropout of USB devices may be related to connecting the devices through the hub in a way that draws more power than USB can supply. I thought the documentation recommended that the Cypress FT board be plugged directly into one USB port and the hub and other devices into the other...
There are also reports of the Cypress board not working after a suspend or when booted on the field. This is probably the next highest priority issue. Data on the driver being used as well as the steps to reproduce would be very helpful as I personally have not been able to reproduce this.
|
During competition matches, we have two USB devides (Cypress board and Logitech gamepad) connected to the KOP USB hub which recieves power from both USB ports. At home and on the practice field, we also have the Stop button plugged into the hub. We are not using the Cypress board to drive any outputs, so all of its power consumption is from powering the chip. We had no problems at all when at home or on the practice field. We found that if the Classmate is sleeping (but not off) when we bring it to the field, and it has found the Cypress board, and connect the Classmate to the FMS at any time, it is fine. If the Classmate is actually off, and we connect to the FMS before it has finished opening Driverstation, it will not find the Cypress board but it will find our gamepad. Rebooting once without the FMS does not always fix this, but rebooting twice always does. As a side note, if this ever happens to us, even if we re-launch Driverstation without rebooting, we will still not find the Cypress board. Everything points to a dead Cypress board, but rebooting twice will fix the problem. We had many teams come to us at Kettering and ask is if we had a spare Cypress board, since theirs magically died while on the field. As I have said in previous posts, what would you think if you had an IFI control system and some of the ports magically didn't work, you would call IFI support right then and there and tell them their products were not reliable enough for competition use and need more beta testing. The same problem is happening with the Cypress board, and I hope a fix is released soon. I cannot see you not being able to reproduce the problem, many teams at Kettering saw it while on the field, including us twice.
As for the analog module, the NI analog input module actually flew out of the cRio, with the analog breakout board firmly screwed in. The cRio is located deep in our chassis, and we didn't see it until the robot was attempting suicide. We probed all of the sensors with a multimeter, and all of them returned valid voltages aprox. where they should be. Everything pointed to a software problem or a dead analog module, until we saw that the analog module had actually come out of the cRio. We glued in all of our modules, but are hoping a more permanent solution is released. Would it be possible to bolt the modules in? Or make a FIRST analog input module that is powered by the cRio, has the 3-pin headers, and secures in a better way then the sprung clips?
As for timing, I will measure download and bootup times on our practice robot next time I am working with it. I am using "Run As Startup", not "Deploy". Your 30s time sounds about right if I were to click the run button in Robot Main.vi.
And for the lag, we noticed an aprox. 3s delay between when the driver sent a command and when the robot acted on it at Kettering. We had recently put the camera on, so we removed it and the delay went away in our next match. Everything points to not enough bandwidth for the camera.
As for the FMS lock, I am aware that FIRST wants it but please make it easier to reset it. Logging off and on in Windows is not a quick thing, and doing that after every match is really annoying. In past years this has not been an issue, as the OI was rebooted every time it was tethered or plugged into the Competition. Power cycling took a few seconds, a few more with that blue OI from last year, but was done all the time. Now that the classmate is never rebooted, issues that are/have been previously fixed with power cycles are now much more tedious and annoying processes, and often unnecessary. Would it be possible to restart Driverstation without looging off and back on again?
@Chris: I have a labview scripting system I really like, but before writing that I actually considered a Python interpreter to allow me to write the autonomous routines separately. Jim Zondag immediately said it was unnecessary and all development would be done in one language, and the project was canceled. I am still looking to do that for next year, but test it in the off-season.