Week one regional control system showstoppers

[DtD]

Originally Posted by apalrd

Lots of field problems at Kettering. We notices the same GIANT delay on the field, blamed it on the camera, removed the camera, and were fine. We have had several instances where BOOT TIMES and CODE DOWNLOAD TIMES have caused us giant problems, but those existed last year. Our biggest issue by far is that if you power on the Classmate with the FMS and Cypress board connected, it will go into FMS Lock before detecting the Cypress board and not detect the Cypress board at all. The fix is even worse. You must reboot your Classmate two times without FMS connection to get the IO board back. We are no longer shutting down our laptop ever again. We played two matches out of 7 (and won them both, btw) with only our driver, since our operators box was completely dead. What is also annoying is there is no way to detect this loss, as the Classmate sends the last good data packet to the cRio even if the Cypress board is unplugged, so we can't pull an input high and wait for it to go low. We had so many FMS problems today that matches went 1/2 hour late, and they're still around 10 matches behind.

^^This. Our team (Which uses C++) could never get the camera to work, we also found out after our first match that the camera randomly decided to either cause huge robot reaction delays or constant robot resetting (Which causes even larger delays - about 5 seconds)

As for joysticks and the io board not working, it might be a power draw issue. We never had the issue but we are not using the io board.

~David

[sparrowkc]

Originally Posted by whytheheckme

...Also, with regard to the First Problem, what type of compression/frame size are you using? It could be a bandwidth issue on the field, or just simply a different throughput of field equipment vs your kit router? (simply un-based thoughts, btw)

Jacob

320x240 compression=30 fps=10

We used these settings because they were a reasonable margin below the settings that caused >1sec lag on the classmate. I doubt bandwidth was the problem. Chrisisme's answer makes the most sense to me right now, we need to look into that some more. We ended up scrapping all of our camera code and physically unplugging the camera. The lag never came back, but who knows if it was the camera's fault or not...

On day two of the KC regional, we switched to a different usb hub and never saw the joystick problem again. We had been using the kit hub plugged into both ports-- the new one only plugs into one port so we pluged the joystick straight into the other port. At our next regional we probably won't be using a hub at all since we were told how to run without the USB Estop (Double click the stop button indicator light in the diagnostics tab of the DS software).

[whytheheckme]

Originally Posted by sparrowkc

320x240 compression=30 fps=10

We used these settings because they were a reasonable margin below the settings that caused >1sec lag on the classmate. I doubt bandwidth was the problem. Chrisisme's answer makes the most sense to me right now, we need to look into that some more. We ended up scrapping all of our camera code and physically unplugging the camera. The lag never came back, but who knows if it was the camera's fault or not...

You should try 320x240 with a compression of 40. Shouldn't be a significant difference in quality, and that will use significantly less bandwidth. Just a thought though, no basis for this other than some simple experimentation. Do you also have the updated dashboard code without the graphs etc. that were really slowing down with the camera running?

Jacob

[UCGL_Guy]

We also had major communication problems in KC this weekend. This FMS / Control system is NOT ready for prime time. I posted a rather lengthy post in another thread about this. For me I am frustrated to no end over the overall poor quality of the complete control system. Too many bugs and tweaks with no real answer from one owner.

[Daniel_LaFleur]

We had issues on Thursday connecting to FMS. Issues so bad that they loaned us another classmate (which promptly messed up our controls ... not sure why).

We fixed our connection issues by moving our radio, uninstalling the driver station, reinstalling the driver station (from a different source than our own), and reinstalling the updates (again a different source than our origional).

No issues after that.

[jspatz1]

As I mentioned in the Kansas City thread, we learned that our problem during at least one match was an IP address conflict with another team. This was evidently confirmed after the fact by reviewing field data. I would refer everyone to our post in the thread link below regarding the proper timing and sequence for logging into your DS and powering up your robot on the field.

http://www.chiefdelphi.com/forums/sh...ad.php?t=83813

[aoberste]

We had our stop button die on use during the competition. It had happened once or twice during testing, but went away after a reboot so we figured it was a code issue.

After some probing with the multimeter, it turns out that we had a busted connector on the end of the stop button USB cable. The ground connector was losing contact intermittently. A quick run to Wal-Mart Friday night (snuck past the manager 5 minutes after closing ), and some soldering Saturday morning, and we had spliced in a new connector on. That solved the problem for the weekend.

If you open up the stop button, they are very cheaply made. There is a piece of kite string in the cable that serves to give it tensile strength. Our had solder balls and burned bits on the board. I think I'll open it up tonight and clean it out now that I'm home and have a good soldering station.

[Mageofdancingdr]

For all those having trouble with the KoP stop button, it is possible to run in the pits without it. On the driver station navigate to the tab called diagnostics, and a list of items plugged in should appear with red and green gots beside them. double click on the (presumably) red dot next to the "Stop Button" label and choose the option "Yes, I'll be careful". A dialog box will then coundown 20 seconds and then the robot should be enableable without a stop button plugged in. We had our button die on us as well in the pits after travel, but due to errors in packing had not the solder materials needed to fix it we'll learn for LA regional I guess.

[Kingofl337]

We saw the Classmate pegged at 100% cpu usage running the dashboard. We offloaded the dashboard to another PC and found out that FIRST did not provide a second Ethernet cable for a Dashboard PC. They do not allow a hub/switch to be connected between the classmate and the field. We were told that we needed to use a USB-To-Ethernet adapter (slow), we bridged the network cards together and it worked fine in the pits and on the field but the FMS refused to let us connect to it. So we had to remove the network bridge and do without for the weekend. Whats really sad is the field switch still has a couple empty Ethernet ports and a cable would be so simple.

[Bandgeek80001]

Originally Posted by sparrowkc

Second problem
During some matches, our joystick simply did not work. Inputs on the IO board did work, and the joystick was listed in the setup tab of the DS. I know of at least one other team that had this problem. I remember it happening on and off the field. It seemed to persist across power cycles and then fix itself. Ours was a logitech 3-axis joystick. It was going through the hub, and I couldn't reproduce it after I connected it straight to the classmate.

In the pre-season, we've figured out an annoying, yet seemingly foolproof way to fix the joystick thing in a pinch.

If you go into the DS, under the setup tab, you can see all the joysticks that the computer detects. If you reorder the malfunctioning one to a different position, and then move it back, this seems to fix the problem.

Ultimately I wish we knew a better fix, but this has worked in the several times we've experienced this problem.

And our Targus hub went out, too. We're planning to bring a few spares

[heydowns]

Originally Posted by Joe Ross

I believe there is another RSL flash pattern (possibly undocumented) when it's attached to the FMS that indicates that there is a SW version mismatch. It may be a fast flash, I don't remember. Someone found it during the beta when they tried to use this year's controller with last year's FMS.

That was me. The blink code for cRIO image version mismatch is unfortunately largely indistinguishable from "no comms". The "mismatch" here is between what the actual cRIO image version is and what FMS wants it to be.
You shouldn't see any of this after practice day, as this is an inspection item.

[Radical Pi]

For the first problem, during my testing of our bot I found the lag in control to be caused by an enormous number of printf's in WPILib code under certain error circumstances (camera code looking for non-existent camera, throwing an error on every loop of the camera task, CAN bus not communicating with a jag that should be there for some reason such as breaker out or ID reset). I've written my share of lengthy complaint posts about it.

One time we lost communications with the cypress board right before a match that was hugely delayed, causing the computer to sleep and (as far as I could tell) crash the service for the cypress. A simple reboot fixed everything.

I've found the cypress board to have caused a variety of issues this year, one of which caused our 2 alliance partners to completely fail in eliminations. With all of these young, energetic programmers around, you'd think FIRST could create a more resilient system