Field Issues
 

What are the week one field issues? Any communication problems?

Re: Field Issues
 

Team 20 has found that even though they say any laptop can be used legally, it needs to be set up very specifically to work.

Re: Field Issues
 

Many teams at the Alamo could not connect with the field system in early matches. Some of these issues were caused by the incorrect version of software on the Driver Station.

TEAMS can fix this by making sure they have the correct version of software on their Driver Station.

INSPECTORS can help resolve this by noting the correct version of software on their inspection list. It currently says to check for the correct version, but doesn't say how or what the version should be.

Re: Field Issues
 

Dan:

What specifically did you have problems with when using a non-Classmate lapop. Any specific advice for set-up for other teams doing the same?

Thanks!

-J-

Re: Field Issues
 

Related question:

Was the laptop(s) in question set up exactly according to this document?

Re: Field Issues
 

I can't speak for Dan, but one recurring gotcha I saw at Alamo is that the Driver account must be named "Driver", exactly. "Driver Station" won't work.

Re: Field Issues
 

In addition to checking your firmware version (10.10.22.0 = bad), make sure that your IP is set correctly. It should be 10.xx.yy.5 with a subnet mask 255.0.0.0, where xx is the first two numbers of your team number and yy is the last two numbers of your team number. So team 229 would be 10.2.29.5. Also check to make sure you only have one IP address assigned to your DS and that your wireless is disabled. Checking all these things on every driver station at FLR helped us resolve the problems the teams were having connecting to FMS.

All of these things can be checked by logging into the Developer account on your Classmate then running ncpa.cpl. From there, right click on the wireless connection and select Disable if that option is available then right click on the wired connection and select Properties. In the pop up that opens click on IPv4 then click the Properties button. The Properties window will display the current IP address which you can edit if necessary. Once your IP is correct, click the advanced button and delete any extra IPs.

It also helps if the venue doesn't have WiFi that interfears with the field as we learned after 10+ hours of trying to get

Re: Field Issues
 

I want to say for the record, that FIRST has been very upfront about making sure you have your non-classmates configured specifically for competition.

When you log onto your Driver Account, If the regular windows bar still show up on the Driver Station and Dashboard, then you have not configured it correctly.

Teams, if you have the opportunity, go ahead and download a copy of FMS 2009 Light on another computer. Plug your FMS computer and DS computer into your old Linksys Router (or any other router/swtich of choice). Make sure the router's IP is set to 10.0.0.4 Then run the FMS and DS in the Driver account. Set one of the team numbers to your team number in the FMS. Set your DS up as your normally would for competition. If all works you'll see your computer say FMS Locked, and the FMS will show your DS connected.

It would be a great idea for all teams to try this before arriving at events to help keep these problems from occurring.

Re: Field Issues
 

Radios:

• Radios mounted between/on-top-of/near the drive CIMs and/or buried deep in the robot metal lose communications when the robot starts to drive. Talk to the FTA before a match to ask him/her to watch the packet round trip time for your robot. Slow times (>20ms) probably mean the radio needs to be repositioned.
• Loose power connections to the radio. Even a momentary power drop from a robot sudden movement or collision loses field connection for at least a full minute.
• Radio power NOT coming from the special voltage dip protected Power Distribution Panel connection.
• When setting the WPA, plug in Ethernet before power.
• DLinks MUST be set to BRIDGE. Some tried AUTO, which eventually works, but only after the match is half over and the FTA had to bypass you to get the match started.

cRIO:

• Loose power connections. Tug gently on the power wires at both the cRIO and PD ends to see if they tug out.
• Image rev MUST be v28
• Sometimes, communications between the cRIO and DLink seemed to hold things up, but it's an easy fix and the FTAs handle that as second nature.

Driver Station:

• Wrong rev. Must be this year. Either 01.05.11.00 or 02.27.11.00 are fine. Older ones mean your robot will never link to the field.
• Check the cRIO rev here too. Image rev MUST be v28.
• Remain wary of misplaced joystick inputs. Check them by pushing a button and seeing them light up blue on the Driver Station Setup tab.
• Remain wary of the joysticks and Cypress appearing, BUT not getting enough power over USB to operate. Cypress should NOT share a USB port with anything else. The same is true for power hungry bells & whistles joysticks.

Field:

• The minibot tower's can give false positives when robots hit them hard in the endgame, so refs are scoring them by hand. FTAs are playing with the sensitivity.

General:

• Plugged in and charged batteries are always welcome.
• Powered up robots work well.
• Being in the correct player station works better.

I'll have to go through my notes to see what else.
The FTAs have their own more complete list of course. I was mostly in the pits and infrequently on the field watching a particular team with problems until the end.

Re: Field Issues
 

Mark, can you explain this entry in more detail?

Re: Field Issues
 

One of the more interesting problems we had was when the field unexpectedly reset. We set up for a re-match, and the match starts. Our robot arch wildly hitting almost every field element and crushing our manipulator against the field wall. A programming post-mortem found that because we chose to send values directly to our speed controllers, that was the last value they were set to. Our driver was holding up and right, and during autonomous, it continued to move only up and right, instead of setting back to zero.

Be prepared for unexpected events like that during qualifying matches. If a re-match is called, I would try to remember to reset your robot, or account for this in autonomous (setting all motors to zero before continuing with code.)

Or, you could have used watchdog...

Re: Field Issues
 

The 12V Robot radio connector on the end of the PDB uses a buck/boost converter to maintain 12V down to a very low battery input voltage (4 or 5V if I recall correctly).

Because of this protection (and because the rules require it), the 12V-5V converter for the robot radio should be plugged into this connector and not one of the generic 20A/30A Wago terminals.

Re: Field Issues
 

At Kettering, eventhough 1.05.11 was supposed to be fine, it was found only 2.27.11 worked with field.

all classmates had to be flashed to 2.27.11, there was one flashdrive with the firmware in the building and no open wifi to the internet.

There was many factors to the 3-4 hour delay we experienced on Friday, this was one of them.

Robot inspection was passed on Thursday with 1.05.11 firmware, shown to not work on Friday.

Re: Field Issues
 

What he means is: The 12 Volt WAGO output at the end of the PDB supplies the 12-5V converter, which then powers the radio.

At NJ we saw many teams powering the 5V converter from regular 12 V breakered connections, and several powering their radio from the 5V PDB output. All bad.

As for week 1 problems, as a spectator I can say there were FAR fewer problems than in recent memory. FIRST seems to have done their homework this year. :) Of course it helps to have Pete K as the FTA...

Re: Field Issues
 

That was happening over at the granite states regionals too. They had to redo some matches because the whole red alliance side was not working. Then at the begining of friday we go to our first match and it is not working and the told us it was because we had the wrong firmware on the drive station but no one ever told us it had to be switched and it was working fine on thursday.

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.

Re: Field Issues
 

Here's a list of issues that caused teams to not work on the field at San Diego. Many of these were already mentioned, but I wanted to reiterate them.

Communications, Robot Side:

• cRIO lost power after a very hard hit. It looks like it was probably the fuse within the cRIO. cRIO was replaced.
• Radio not configured through kiosk.
• Radio powered through breaker not through dedicated 12v radio supply on PDB
• Loose wires on the on the battery, breaker, or PDB, which either came out, or caused excess current which dropped the battery voltage low enough to cause problems. Fixed by tightening all power connections.
• Radio located next to lots of metal, motor, or speed controller. Fixed by relocating radio
• Power cable has loose connection with radio. Fixed by securing radio power cable or replacing it.

Communications, DS side:

• Driver station account needs to be "Driver" (case sensitive) if you're using your own laptop.
• Make sure you set up your DS in the correct position. It won't connect to the field if you aren't.
• Make sure that ethernet cables positively latch on the classmate's ethernet port. If yours is broken (ours is), you can use a USB ethernet adapter, or another laptop.
• Do not set up a bridged connection that uses the ethernet port that FMS uses. It will not connect to the field.

Joysticks don't work:

• USB hub was unplugged, so joysticks not detected. Double check, especially if you have a multi-part control station, or the usb hub is mounted in an unsafe location
• There were at least 3 cases where joysticks did not work on the field. If the team went to the setup tab and pressed the buttons on the joysticks, the joysticks did not change color like they should. This may have some interaction with waking up from sleep mode. It was fixed by unplugging the hub and plugging it back in. Check that your joysticks work (eg light up on the setup tab when you press a button on the joystick) when you're setting up prior to the match.

Re: Field Issues
 

Formatted printing (using printf or cout or similar functions) is one of the slowest functions in the C/C++/Java libraries. It should be avoided at all costs in the production or competition environment. If it is buffered things get worse because the functions will block waiting for room in the buffers. This can cause huge problems with timing, even professional programmers (new to programming in a embedded real-time environment) make this mistake. Memory allocation functions are also problematic in critical code sections.

FYI, there is a simple function provided by the operating system on the cRIO called 'logMsg'. It sends a message to a task that does the printing for you and the priority of that task can be adjusted so it does not affect your application. There is not much you can do about the memory allocation functions except organize your code so the allocations are done during startup sequences and not when the robot is responding to DS inputs, running PID code etc.

HTH

Re: Field Issues
 

Hey All,

I was the Control Systems Advisor at the Pittsburgh Regional last week (had an absolute blast there :D). Our volunteer team there carefully monitored every issue that came up with the robots in all the matches. If a robot stopped moving (or never started moving), we made sure we and the team knew why it happened.

Throughout the whole competition we did not experience a single field related issue (except for a rouge tube knocking down a tower's lights). I have had teams approach me after they see the "communication" light drop off the dashboard saying that there must be a field problem. While nothing is impossible, it is much more likely that something else was the cause. For example, if a robots battery falls out, that will also cause the "communication" light go red for obvious reasons :P

Mark and Joe have given excellent summaries of the common problems that were encountered in getting teams up and running. I will just add some of my own observations.

On the issue of using version DS 2.17 and 1.05. At Pittsburgh we saw both work fine, but I encouraged everyone to update their software if for no other reason than consistency on the field. And again, "couldn't hurt".

Non classmate laptops were the cause of a few weird problems throughout the weekend. We had one team using a non-classmate laptop who always had to log out and log back in to successfully connect to FMS. They would get all greens on the dashboard the first time, but FMS wouldn't see them, so we always had them just log off and log back in and it would fix it.

We also had some interesting problems with a few teams updating their cRIO firmware using non-classmate laptops. I think a few of those problems were just caused by buggy computers, but there was one case where a brand new computer running Windows 7 just could not successfully download the cRIO image. My best guess was some kind of firewall issue. We just had that team download the version using their classmate and it was fine. At least 3 teams needed to use different laptops after unsuccessfully using theirs to download the latest image.

The DLINK radios take about 1-2 minutes to connect after power on. In order to keep up 6 minute match cycles we had everyone power on their robots as soon as they hit the field (unless they had a gyro). We kept track of which robots got powered on last so we knew which ones to wait for while the radios connected and not accidentally bypass them while they were still connecting.

Thats pretty much all I can remember right now. If anyone had an issue that went unexplained or was thought to be a field problem, please PM me and I would be happy to try and investigate it. Always looking for potential problems :)

Re: Field Issues
 

A best practice for using the gyro is to have the software do a gyro reset at the very beginning of autonomous. That way the team can line up the robot with it on, but the final position will be the 0 angle for autonomous. Even if a team can't implement that software fix, they can reboot the robot with the reset switch on the cRIO, which will sync much faster then a full power cycle of everything (they may also be able to use the reboot robot button on the DS).

Re: Field Issues
 

- As the FTAA for the Wisconsin And Minnesota North Star Regionals, I, too noticed that the driver station software v1.05 seemed to cause FMS linkup failures. I just told the teams to upgrade to the latest version just to keep that out of the equation.
- And STILL the teams don't seem to understand that having the Developer account logged in (in the background) is a bad thing!!
- Although the FIRST instructions for setting up a non-classmate laptop are very specific, some teams failed to get the memo and came onto the field with various incorrect driver accounts. I'd think that this should be a line item for the robot inspectors to check.
- YES, these new robot radios take FOREVER to link up! I can't remember how long both the FTA and I just stared at them in order to make them connect (it was an aura thing I suspect). Although, some teams had the switch set to AUTO rather than "bridge", which took even longer to link, it was probably just an inadvertent change of the switch during the competition.
- And I've noticed that there's not any type of training provided for the FTAAs on the FIRST site. You'd think that a position like this would merit at least a one page summary of what the FTAAs are responsible for.

Maybe this is the start.....