[The Lucas]

Originally Posted by FRC4ME

This right here is an indication that FIRST does not fully understand the FMS they are dealing with. Correct me if I'm wrong, but the order in which you connect devices to a WiFi network should have no affect on how the system works. We have found a solution that seems to make things work, but I doubt anyone understands why it "works," and whether it leaves behind any residual problems. One of the first steps toward solving the FMS bugs, IMO, would be to determine why the boot order matters. This could possibly shed light into the root cause of other problems.

The gaming adaptor problem is a tough one and not entirely FMS's fault. I thought the WGA600N worked well last year. Unfortunately, it was discontinued for the WET610N. Now you have lots of teams with the old adaptors, and many teams with the new ones since they cant get the old ones (and we have an unavoidable mix).

Before I say this next part, let me preface it by saying that Cisco/Linksys makes great products and I thank them for their sponsorship of FIRST. Linksys products are my preferred brand and what I usually tell family and friends to buy when they ask for advise. I use the old adaptor on the comp bot and the new one on the practice bot. The 2 adaptors are noticeably different. WET610N takes much longer to even connect to the Linksys router, independent of any other FIRST equipment. What is it doing during this time? Looking at the Cisco site it seems to be focused on Streaming video to HDTV and has 3 antennas as opposed to 2 . Of course more features for increased boot time is a great trade-off to make in a product that doesn't need to boot often in its intended use (once a month maybe?) Keep in mind we are not using these products for their intended use (see the power adaptor which is even harder to keep in on the new one). For our use, boot time is critical.

Now the big problem (as I have heard from web casts I'm not an FTA) is that the new ones tend to interfere with established connections of the old ones. This would seem to point to an FMS bug but it could be a problem with the 2 adaptors. Has anyone tried to use both at once in their lab? If I was using both adaptors at home and setting up the new one temporarily knocked the old one off the network, I probably wouldn't even notice because it would reconnect in a few secs. Unfortunately in our use this is a big deal. It would be nice if Cicso could provide some sort of WGA600N compatibility firmware for WET610N. Maybe there is a set of settings that can achieve this? (I dont know)

Originally Posted by Tom Ore

Our programming mentor thinks he may have found the issue. Sorry I can't be too specific, but he changed the location in code when the camera is launched. We'll find out in Minneapolis.

We get the first instance of the camera in the constructor (for the robot class in C++) after a 10 sec wait. I have tried other places that have not work (however updates may have fixed this). Keep in mind that you are not just connecting to the camera, you are connecting the PCVideoServer to the Classmate. I wish that they would decouple the Camera and the PCVideoServer feed like last year. Yes I know it is easier to use, but you don't have the ability to control the feed anymore and start it at a different time.

Originally Posted by Pat Roche

The code was a simple drive forward for x seconds then do nothing for x number seconds (sorry I cannot recall the exact number of seconds but it was approximately 19). There was nothing executing beyond that. We tested this during our system check field side. It worked 50 matches in a row successfully. It was the only autonomous code we had in our robot. It makes no sense that after match 50+X all of a sudden a timing issue like that would begin occurring without changing something in the software.

In Baltimore, one team was having issues transitioning in teleop from auto using LV. they had timer waits at the end of auto. I advised them to get rid of the end of auto timer and disable the user watchdog. They seemed to run fine after that when I saw them and they didn't ask for any more help.

Any waiting (over a tenth of a sec) in auto is just a bad idea to me. I know it is easier to program but it is important that you get out of autonomous and into teleop ASAP after the teleop bit is set no matter when that happens or what your robot was doing. Instead of waiting on timers, check them periodically and if auto period ends before your timer reaches its value, go to teleop.