Re: Field Issues
 

Interesting, but that sounds like a "it couldn't hurt" solution, rather than a required one.

At NJ most teams ran with 01.05.11.00.
The 2/27 version is identical, except in how it handles changes to IP settings, only noticeable on a small number of laptops, but maybe you had a lot of those if local teams all purchased the same third-party laptop on sale. :)
At NJ, we did upgrade a few driver stations with the newest edition.

Of course, since it couldn't hurt, upgrading to the 2/27 version is probably a good idea anyway.

Re: Field Issues
 

Yea, I'm seconding the whole 02.27.11.00 thing. 01.05.11.00 was fine on practice day, but they had everyone move to 02.27.11.00 by the first day of comp.

Also, at least for java users, update netbeans so that it matches the new cRIO image. We had a very unofficial way of fixing ours w/o internet (our programming mentor used hacking skills). Try to fix it in a better way though if possible, haha

Re: Field Issues
 

Some additional detail based on my observations at Trenton (thanks Mark for the great list!)

To expand on the situation behind this - the WPA configuration kiosk apparently has sporadic problems and will report a "failure to configure IP, wrong operating system" error (or something like that - can't remember the exact wording, sorry!). Usually the bridge will still be configured OK, but better safe than sorry. Hopefully the word can get out to the other regional volunteers so everyone knows the correct kiosk procedure is to plug in ethernet 1st, then power 2nd.

To expand on this, using DS Rev 01.05.11.00 but having multiple IP addresses configured on the network adapter will also mean your robot will never link to the field. I think this is what jhersh meant when he euphemistically explained that DS rev 02.27.11.00 would "ease proper configuration of the driver station laptop's IP configuration (making you more likely to successfully connect to the field)." Prior to rev 02.27.11.00, setting the team number in the DS config just set the additional IP for your team without getting rid of any additional pre-existing IP addresses that may have been configured.

Several teams at the Trenton regional found this out the hard way when they borrowed Classmates from spare parts - the spare parts classmates all had DS rev 01.05.11.00, and also had an existing IP of 10.0.0.5. - so any team using a spare parts Classmate could not connect to the field initially.

Again, better safe than sorry - probably best not to consider DS rev 02.27.11.00 "optional".

Huge thanks to all the Trenton volunteers but especially Mark, "NI Greg", "NI Ben", and "FTA Pete" for all the hard work!

- Ron
Team #2607 controls mentor

Re: Field Issues
 

It can be an issue for teams who switch their IPs around a lot, or if you borrow a laptop from another team or Spare Parts.
That's why the vast majority of teams won't see this.
It'll only cause a problem the first time you go to use it.
If you connected at least once before by tether in the pits then you're good and it won't crop up later or anything.

The way to tell if this was happening to you is pretty simple.
The symptoms are: the Driver Station can't see the robot on tether.

If you check your IP settings use the Advanced button down at the bottom (1st attached image), and you'll get a list of the IPs associated with that network adaptor. Just delete the extras that shouldn't be there leaving you with one IP address as in the 2nd attached image.

-------
Hey Ron,

Want to report on the CAN bus issues you debugged?
That's useful for teams to know, too.

Re: Field Issues
 

Hey! Yep, will probably take another day or two before the students and I finish pouring over all the runtime data we collected. Preliminarily it looked like stray CANBus exceptions would cause FRC_NetworkCommunication to block, and therefore cause FMS<->DS<->Robot comms issues whenever stray CANBus exceptions would occur - but now looking at all the data we're not sure if this is the case. I told Greg we'd write everything up and send to him and Joe for review.

Quick question on the DS tethering - the students say they were able to tether successfully with the borrowed Classmate and "multiple IP" situation before going on the field......they would have done that to charge the pneumatics since we have an off-board compressor this year. So I'm wondering if the multiple IP problem is a cRIO issue, or an FMS issue?

Anyway, safest procedure is just to check the IP settings!

- Ron
Team #2607 controls mentor

Re: Field Issues
 

I watched Trenton all weekend and tracked who won on which side of the field. This is my third year as an FTAA at Chesapeake and it seems like evey year someone complains that one side of the field is favored. I can tell you this was not the case at Trenton. It was very nearly a 50/50 split. Hopefully that holds up at Chesapeake!

Re: Field Issues
 

The account being named Driver and not being able to change the name to Driver, ton top of a lot of CAN issues caused us much trouble. We are setting up at least 4 computers for Hartford, and hopefully we'll be able to make practice matches to test them.

I did not know that was why the decorator didn't show up around the DS windows. Thats a really useful tidbit of information.

Re: Field Issues
 

Ditto on the Windows account being named exactly Driver with the uppercase D in order to work with the FMS.

Re: Field Issues
 

Don't know if it has been mentioned or changes somewhere in the great update loops of FIRST, but at Kettering the reflective tape used on the field did not match at all what was sent in the KOP sample.

The tape I had purchased and tested with, had reflective properties similar to sample tape provided in the KOP.

Using this tape the Line sensors, when placed approx. 2" above the floor, we had to detune the sensor all the way, and if the sensor got closer than 1.5" the sensors would false trigger.

At Kettering, we had to turn up the sensitivity almost 100%, and the sensors worked over the carpet, but when we had the bot in the pit, the sensors would false trip on whatever they used to cover the pit floor.

I was pretty nervous going into the first match, with no practice matches.

So be warned, if you have tuned your sensors to the KOP sample, you better make a trip to the practice field before your match.

Re: Field Issues
 

Scott,

While this is an excellent warning to any other teams that may have made this mistake, I do feel compelled to point out that this is not really a field issue. The reflective tape provided in the KOP was a sample of the material used for the reflective targets on the scoring grid. No sample of the grey gaffers tape used for the lines was provided in the KOP, but the manufacturer and product description were published by FIRST.

Re: Field Issues
 

True that...

Silly me to think that the KOP unidentified reflective sample of 2" material would be used with line tracking sensors.. Silly me to think that Pro-Graff tape was "generic" (akin to Duct tape) name as opposed to specific manufacture of tape.

The learning curve of a first year mentor. :)

While I am on this exposing my sins, although off topic here, can someone tell me why we get autocad for free and publish all the area drawings in .pdf forms?
I don't know how many times I had to scale a .pdf printout to set up the "Y" line on our school floor.

Live and learn.

Re: Field Issues
 

By no means was I suggesting that FIRST made it clear which tape was which or easy to understand, merely pointing out that the information was there.

You are not the first team I have heard with this confusion (there are many posts here on CD with/about it) and I'm fairly sure you won't be the last.

Regarding the field drawings, many of us have been wondering for the last few years why FIRST won't just publish the CAD in some standard format, ocassionally aloud to the GDC or other FIRST officials. With Autodesk, PTC and Solidworks all sponsoring FIRST, it seems like it would make a lot of sense to publish CAD in addition to the drawings.

Re: Field Issues
 

This has long been one of my pet peaves with FIRST. I am a Tool Designer for a major aerospace company. Every drawing I produce contains the following General Note: "Analyze <your CAD system here> model for all non-critical dimensions and information not shown" I have never gotten a good explanation for why the models of the field are not released. It would surely help with finding those dimensions FIRST did not think were critical enough to add to the drawing. The alternative I have used for severl years is to get the .pdfs and build my own models based on the drawings.

ChrisH

Re: Field Issues
 

We were having extreme communication issues for basically all of Thursday and we couldn't figure out what it was. After a ton of other things we stopped printing things to the display and that seemed to fix some of our problems.

Re: Field Issues
 

(Week two)
At Lake Superior regional it started with the laptops having to be updated to communicate. Then a minibot tower was knocked over, like literally leaning on the side of the field. The problems subsided after a tube hit the antennas to send info back to Manchester meaning we could not send score data to Manchester until it was fixed a few minutes later.