2012 Field Comm. Issue Logs

The amount of complaints about field connection issues at events this year has been unusually high. There have been cases of teams getting very slow response times from their robots (like 150ms slow). We should document these along with some information about robot setup in this thread. Maybe with enough eyes on the issue the bug will appear.

If you had communication issues at events (high ping times, non responsive robot, laggy controls), will you take some time to post some information here?

Please also post a short description of your issue as well as an upload of the log file that shows this. Located at : Users\Public\Documents\FRC\Log Files

Also, answers to the following questions should be helpful:

  • Which event?
  • Wireless bridge radio HW revision? (A1, A2, or B1)

The label on the DAP says:
H/W rev A1
H/W rev A2
H/W rev B1

A user can easily tell the difference between the Rev A and Rev B hardware platforms. In addition to being noted on the box and the back of the device on a sticker, the front of the bridge is also visibly different. In the image below, the Rev B is the upper radio, with the Rev A below it.

See http://frc-manual.usfirst.org/TeamUpdates/0 3/6 update for more info

  • Radio firmware rev? (1.21, 1.4, or maybe something else)
  • Programming language?
  • Using a dashboard app? Labview, SmartDashboard, or custom?
  • Using vision with Axis Camera and cRIO processing?
  • Using vision with driver station processing?
  • Did you have the radio mounted near motors/large metal structure?
  • Using classmate (or similarly slow computer) as driver station?
  • 4 or 8 slot cRIO? (FRC-CRIO2 or Old version)
  • CAN Jaguars? What FW version?

I know some people are trying to gather data on their own about events they volunteered at. If you are one of these people, can you post your findings here?

EDIT:
Added some other things from Joe, Kevin, and linuxboy. Thanks!

EDIT 2:
Added 4/8 slot cRIO.

EDIT 3: Can jaguar

Which event? Kansas City
Wireless bridge radio HW revision? (A or B) A
Programming language? Labview
Using a dashboard app? Is it SmartDashboard? No
Using vision with Axis Camera and cRIO processing? Passing image, no processing
Using vision with driver station processing? No
Did you have the radio mounted near motors/large metal structure? Yes
Using classmate (or similarly slow computer) as driver station? Yes

Which event? Los Angeles
Wireless bridge radio HW revision? (A or B) A
Programming language? Labview
Using a dashboard app? Is it SmartDashboard? Modified Labview Dashboard
Using vision with Axis Camera and cRIO processing? Included image processing, but removed at competition due to lag issues. After removal, only passed image to DS
Using vision with driver station processing? No, Classmate computer was slow as well.
Did you have the radio mounted near motors/large metal structure? ~1 foot clearance
Using classmate (or similarly slow computer) as driver station? Yes

The issue wasn’t always related to our bridge/cRio/DS – in some matches the bridge was unable to connect to the FMS. This was a known problem in LA and resulted in MANY 2v3 matches.

Erm. In addition to the answers to Tom’s above questions, you should probably also post the actual issue/symptoms you were experiencing, since that varies from long pings and delays to intermittent or no Comms.

For rev A radios, it would be helpful to have the firmware version (1.21, 1.4, or maybe something else).

It would also be helpful for a description on the problem, and some representative DS log files (in Users\Public\Documents\FRC\Log Files)

Team 846:

Programming language? C++
Using a dashboard app? Is it SmartDashboard? Started with SmartDashboard, but removed all logging during competition (did not solve problem)
Using vision with Axis Camera and cRIO processing? No
Using vision with driver station processing? No
Did you have the radio mounted near motors/large metal structure? No
Using classmate (or similarly slow computer) as driver station? Yes

We’re using a Rev A radio, and tried firmwares 1.21 and 1.4, with the same results in both.

Problem: Intermittent connection on the field, losing comms generally around the end of autonomous, and randomly thereafter. Total time actually connected varies between 10s to 20s; packet losses of 25 / 50 are noted immediately before the communications goes down.

Thanks, can’t believe I forgot those things. Edited the orignal post.

I’ve also edited the original post to include a question about 4 vs. 8 slot cRIO.

Tom I would suggest to also check if CAN-bus communication was used, and if so, what version firmware was loaded on the jaguars.

We have correlated (note, not causation, just a hypothesis) multiple field failures (full connection loss) to the Blue alliance station number 1. At FLR, our robot failed multiple times in that station only, as did our alliance partners. Further supporting this theory is the fact that during the qualification matches, the red alliance won 61% of matches. Considering the randomized aspect of schedules, this seems somewhat outside the 50% norm it should be. The field is going to Buckeye this week, and DC next week. We’ll be at DC, watching it, but I would suggest anyone at Buckeye to keep an eye on that station. It might have just been assembled at Fingerlakes with a wire loose, or it could be a problem in its hardware. Or this whole thing could just be coincidence. Just something to keep in mind.

I don’t understand. It sounds like you’re saying that more than one robot was using the Blue 1 alliance station at the same time. While that’s likely not what you meant, it would certainly mess with their ability to connect!

Correct me if I’m wrong, but he’s saying that anyone who used Blue 1 had issues.

At our third Elims match at WPI, our bot executed autonomous fine. However, upon entering Teleop, spun in a tight circle, accepting no input from drivers and did not respond to an E-Stop command. What gets me is we were running fine throughout every other match that day. No new code that wasn’t tested was loaded onto the robot, and nothing changed between our second Elim match to our third. (This includes electrical).

I’ll post more details and the wacky logs later.

EDIT: We used the 4-slot cRIO, LabVIEW, and did not use CAN.

Dashboard: Edited version of the FRC Dashboard, did not cause any problems in the past.

Radio: Not mounted near motors. 2012 KOP radio.

Computer: MacBook Pro, 8gb ram, Intel core i3 running Parallels. (Had no problems with the FMS throughout the weekend once we set up the network settings correctly.)

Vision processing: No.

Ave. cRIO CPU usage: 40-60%

Day one is over at St.Louis Regional and as Jspatz posted above we are experiencing the same issues like we did in KC heres Settings again:

Which event? Kansas City
Wireless bridge radio HW revision? (A or B) A
Programming language? Labview
Using a dashboard app? Is it SmartDashboard? No
Using vision with Axis Camera and cRIO processing? Passing image, no processing
Using vision with driver station processing? No
Did you have the radio mounted near motors/large metal structure? Yes
Using classmate (or similarly slow computer) as driver station? Yes

On Thursday there was a ton of robots not being able to connect(Including our team) to the field mostly on blue side this also is the field that was used at bayou, In which one team couldn’t connect the entire day on Thursday. We all had different firmware versions like 1.40,1.20 and 1.30 So they all downgraded the routers at the regional to 1.2 and every robot was able to connect to the field but we still get this “intermittent” com drop when we go to get a ball at a side in the arena.

There are alot of teams here that are or seem to be having the same issue of really high trip times from the FMS even after code is modular and changed.(Shout outs to helping all the teams FTA’S)

What gets me that It only happens on one part of the field closest to the Antenna to the FMS?

Anyone else having this issue? Also if you have trouble at your regional with networking check the version It also makes a really big difference if you are version 2.00 Hardware Revision B which also doesn’t work on the field. One robot with a different one can cause a major drop out for potentially the entire field. (Which happened This goes for RevA also) Really good job FTA’s on figuring this out

I’ll let our CSA from our team chime in later with details.
Apparently, we are the only team with a 1.4 firmware at our regional, including our backup one.

In our only loss in a match today we lost comm (lag issue) for the last 30 seconds in our match.:frowning:
It affected our ability to do the coop bridge also. Not knowing how it could’ve changed the outcome was frustrating.

If that is the field from Bayou, I would be interested in knowing what FW version the Loan Router has. We used it basically all Friday and Saturday.

Can you please get someone to check on this for us?

When you guys say you lost comms with the FMS, do you mean a spike in lost packets, an exceedingly long trip time, or “No communication” displayed in the DS? I’m interested in the fact that so many people - including Team 23 - are having issues with the FMS.

I’ve now heard of another team at WPI where the robot eas only able to spin in circles. Can someone from the drive team give details as to when it started during the match, what you were able to do, what eventually happened, etc?

I looked for footage but couldn’t locate either. I was able to investigate one of these right after it happened, and expected it to be a chain, jammed, a speed controller, etc. I found a missing limit jumper on a jag that would have disabled one motor in one direction, but it wasn’t clear that this was the issue, contributed to it, or was there all season and they were simply driving with a severely imbalanced drivetrain. They had four motors.

Before I explain what I suspect, I’d like to hear about recent issues involving spinning robots that weren’t due to mechanical or speed controller issues.

Greg McKaskle

I’ve just sent our drive team a message asking for further details. As soon as they get back to me, I’ll let you know. Do you need/want any information on our router version and firmware?

If I remember correctly, the limit switch jumper just reverses the motor direction on the Jag?

EDIT: Our operator is telling me that they were able to control it for literally 2 seconds, enough time to step up to the controls and try to drive it. He went on to say that our two camera feeds froze the second we started spinning. He doesn’t remember what the RSL was doing, but since the logs say we were in teleop, I would assume it was flashing the teleop sequence.

I can’t seem to find the Luminary manual that would be definitive, but I think the limit switch is used to enable or disable movement in a particular direction. They are also used for ramping if using the latest FW. If missing, I believe this jumper will stop and either coast or brake the motor and ignore inputs in that particular direction.

As for firmware version info, sure. Give it to me. But honestly, what I want most is a eye-witness account of the behavior or a video of the incident. I didn’t see it, and even the one I saw happened unexpectedly, and I didn’t see it begin. I walked to the side of the field to see if I could see a jammed ball, a chain obviously jumped off the sprocket, etc. After the match people were excited and talking about field faults and whatnot, and I couldn’t get a good explanation of what took place. I don’t want to bias someone into telling me symptoms that support what I think may have taken place, so I would like to have a description first.

Greg McKaskle