Field Issues

[Mr MOE]

Originally Posted by JewishDan18

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.

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-

[Vikesrock]

Originally Posted by Mr MOE

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-

Related question:

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

[EricVanWyk]

Originally Posted by Vikesrock

Related question:

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

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.

[dag0620]

Originally Posted by EricVanWyk

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.

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.

[Mark McLeod]

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.

[rsisk]

Originally Posted by Mark McLeod

Radios:

• Radio power NOT coming from the special voltage dip protected Power Distribution Panel connection.

Mark, can you explain this entry in more detail?

[Vikesrock]

Originally Posted by rsisk

Mark, can you explain this entry in more detail?

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.

[trident523]

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...

[tr6scott]

Originally Posted by Mark McLeod

Radios:Driver Station:[list][*]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.

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.

[DonRotolo]

Originally Posted by rsisk

Mark, can you explain this entry in more detail?

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...

[TPNigl]

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

[Mark McLeod]

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.

Originally Posted by tr6scott

At Kettering, even though 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.

[rrossbach]

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

Originally Posted by Mark McLeod

Radios:

• ...
• When setting the WPA, plug in Ethernet before power.
• ...

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.

Originally Posted by Mark McLeod

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.
• ...

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

[Mark McLeod]

Originally Posted by rrossbach

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.

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.

[rrossbach]

Originally Posted by Mark McLeod

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.

-------
Hey Ron,

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

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