Field Issues

[Joe Ross]

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.

[wireties]

Originally Posted by Warlord

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.

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

[colt527]

Hey All,

I was the Control Systems Advisor at the Pittsburgh Regional last week (had an absolute blast there ). 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

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

[Joe Ross]

Originally Posted by colt527

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

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

[bfvaneyck]

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