The communication tides are shifting...

[Deetman]

Originally Posted by 1075guy

If they really want to stick with a TCP/IP based solution, they should run it on the licensed 3GHz band, using gear like the stuff made by Ubiquiti Networks.

The problem with licensed bands is that they are, well, licensed. This adds additional cost and administrative paper work for FIRST. Not to mention the possible inability for teams to use it at their local build site for wireless comms with the robot and the higher cost for radios.

If you want to start pointing fingers, start with the D-Link AP. It is consumer grade hardware not designed for the FIRST application. If the D-Link can be absolved of blame then you start moving to other options.

[Racer26]

Where you see a problem, I see a solution:

The problem: interference from the thousands of 802.11abgn devices we bring into the stadiums with us.

Solution: make sure the robots are on a different band.

The licensed 3GHz band, being licensed, is unlikely to have much, if any interference.

[Deetman]

I don't disagree that being on a licensed band would minimize potential interference. My only concern would be how it would effect teams in their normal build season operation whether it is wireless communications or increased costs. I'm no expert on what we would or wouldn't be allowed to do on a licensed band, but I know there would be a few hurdles to doing it.

[Racer26]

Three ways I can see you handle it.

1) FIRST gets an FCC license at each regional location, and has 3GHz radios for the teams to put on their robots, keep 2.4/5Ghz at home.

2) FIRST gets the fields licensed as mobile transmitters (think TV News Vans), and has 3GHz radios for teams to put on their robots at the events. Use current 2.4/5GHz systems at home.

or

3) Each team gets licensed as a mobile 3GHz transmitter (WAY more paperwork)

[arizonafoxx]

Is it a huge problem to allow teams to build with a D-link but compete with a licensed field supplied router? It wasn't that long ago that we had to share colored flags and give them back to field officials when the match was over. I don't see much difference with the router. The router is basically garbage in garbage out and you would just plug in your cRio and cameras to the field supplied router.

[ratdude747]

Originally Posted by arizonafoxx

The router is basically garbage in garbage out and you would just plug in your cRio and cameras to the field supplied router.

Or better yet, give the teams 5 port switches and a 1 port wifi adapter... that way all that is swapped is the switch.

[Peter Johnson]

While the commercial grade of the robot radio is definitely a concern, I see a major root cause of the comm issues being the simple fact that all of the data passes through a single point of failure: the field itself. If each team had its own DS radio (provided in the KOP), operating on the field would be no different than operating at home (or ideally, in the pits as well..). This would eliminate the "comm works in the pit, but not on the field" issue.

However, the issue is how to implement this, as the FMS still needs a way to talk to each DS, and laptops only have a single Ethernet port. I propose that a custom DS radio be provided to teams (much like the IFI system did). It would have two ethernet ports, labeled "DS" and "FIELD", but not directly bridge at an Ethernet or IP level between the two ports. Instead, firmware on the radio would only pass to/from the field port key control and logging information, ignoring all other traffic (e.g. camera data) on the DS-robot ethernet/wireless connection.

Conceptually this could be implemented with custom firmware on a commercial home router (with the isolated "internet" port being the field port), although I would hope for competition an industrial-grade solution would be provided.

If so desired, this could be combined with an industrial solution on the robot radio side as well. I definitely hope that any future robot radio solution continue to include 4 ethernet ports; this has been a major enabler to doing more advanced things with the control system.

EDIT: seems like other folks are thinking along the same lines.. I just didn't post fast enough!

[EricH]

I see some problems with any setup. However, the big one I see here is this:

The system components may share protocols, but they were never designed to work together.

Before you say, "He doesn't know what he's talking about", hear me out. Protocols are a good way to get stuff talking with each other. However, stuff can easily get lost in translation. Ask someone who did surfacing in CAD some little time ago--it wasn't uncommon for a surface to jump if you changed systems. It's less common now, with standards like IGES and STEP around, but it still crops up occasionally. The cRIO and the router weren't designed to work together--they can both use Ethernet, but that doesn't necessarily mean that stuff won't get lost in translation, especially if a connection shakes loose. See "router wasn't designed for the impact of one 150# robot into another".

Field-supplied communication stuff would be a pain to work with. First, you have to have 3 sets of 6. One on the field, one being removed after a match, and one being loaded before a match. You might need a fourth--being set to work in two matches. With the flags, it wasn't bad because there was a specific interface, and no other connection was needed, just place and play. For a router, you have to have a minimum of three connections. First, a secure mounting for the device. Second, a reliable power supply running to the mounting. Third, a communication line running to the mounting. All three have to be standardized and work. Depending on the setup, the router may need to get a new encryption/IP every match, which takes more time, hence my suggestion of a fourth set.


Personally, I'd like to see a brand-new integrated system designed from the ground up for FRC use. That's what the IFI system was when it came along. By "integrated" I mean that every part is designed to work with every other part it has a direct connection with, interchangeably if possible (see: IFI radios). Oh, and designed to handle the forces that FRC bots take when they hit each other--metal on metal.

[Dtisdale]

On Newton, Team 1717 died once in a qualification match on Red 1, then 3310 and another team died in Red 1 and Red 2 3 matches later. Then in all of the elimination matches Team 1717 played in Red 1, (all but one) they died and weren't allowed any replays. Then in Einstein everyone saw the field fail. And apparently all the other fields had at least one issue or another but were told that it was their robot and not the field. I think that it is time to figure out a better way of communication between the robots and the field, because that is a sad way to finish out the World Championships.

[PayneTrain]

While the NI equipment was designed for heavy lifting (except the Sidecar, which I compare to being as strong as a wet piece of newspaper in a hurricane) the routers have always been mucking it up. Every single part in the KOP except for the computer and router are things you can't find under the "home and small business" tab at Best Buy (obvious exaggeration, but you get it). In a building full of techies, there will be smartphones and hotspots you cannot stop, and they will be causing interference that is utterly unpredictable and can cause a whole host of errors.

I can't provide you with a grand solution at 1am, but I do know that we have gotten all kinds of positive feedback from NI; I feel like they are working to make the best products for our robots. In the case of the routers, it feels like FIRST struck a deal with a mediocre product and moved on with it. I hope and imagine that isn't the case, but it feels like it. I don't think D-Link feels pressured in the slightest to generate a solution.

[arizonafoxx]

Here's the deal. You are running a 1200 dollar robot controller with a 1000 dollar software (labview). You have a field being run by a several hundred dollar PLC with 1000 dollar software. The thing the interfaces between the two cost 100 bucks. I think that says it all.

[mathking]

I have a plea to make to FIRST and the teams hosting off season events. Let's try to scrupulously document and analyze the problems and see if we can find out what is actually going on to cause all of the dead robots.

I was not at the Championships, but I was watching online when I could and getting constant updates from my team. And I saw some of the same issues happen at Buckeye and Queen City. It happened to us twice at Queen City, both times our driver rebooted the cRIO to restore control of the robot. Looking at what is happening, it seems to me that the most likely culprits are the Dashboard and the FMS software. I am not saying that it could not be something else, but my CCNA training says look for the most likely culprits.

Number one would be physical layer problems. Pre-2011, this was obviously the power supply. Without the voltage regulator a gaming adapter or router could easily be induced to go offline and reset, making robots lose communications for significant fraction of a match. With the voltage regulator that is much less likely.

The next most likely physical layer culprit would be interference. This could be (when we do demos at places with lots of WiFi we have noticed a tendency for robot control lag) a significant factor. But it would seem more likely to be expressed as control lagging rather than lost comms, except that the FMS might see the lag and automatically disable the robot for safety reasons. But I am assuming if this were the case the FTAs would be able to see that this was done. (Maybe this is not warranted, but in helping get the field set up for our off-season event the last two years it seemed to be the case.)

While it is true, as some have said on CD, that TCP/IP is an off-the-shelf technology not designed for FRC, it is an amazingly robust technology that passes quite a bit of data around the world. (Remember what it was originally created for.) It is versatile and powerful. Even those little D-Links on a robot can process an amazing amount of information. And when configured correctly they have no trouble ignoring what they need to ignore and recognizing what they need to recognize.

My CCNA training says to look next for the biggest bandwidth hogs, which are probably camera streams. Here I have an observation. When practicing with a robot at home, with the router in access point mode with the camera stream not being processed by the cRIO, you can view the stream on another computer than the one running the DS software with no lag. But through the DS there can be a decent amount of choppiness and lag in the video stream. If a team is processing images on the driver's station computer, rather than just viewing them, then perhaps the lag might be causing the dashboard software to do something that results in the robot losing comms. This might well be a/the culprit.

We could go on and on speculating, but I think the best hope for a solution is to get lots of eyes to start analyzing. This is where the off-season events come in. There will likely be a lot of bright, experienced people helping at all of the off-season events. Some of them FTAs and some of them not. Which may mean some fresh eyes on the problem. My gut may be wrong, but it telling me that the problem is most likely in the FMS software or the driver's station software.

[steelerborn]

I don't know much about the communications part and the FMS, I am just a CAD and Strategy mentor, but FIRST team 1671 The Buchanan Bird Brains have ran 3 years using the C-rio and not having 1 single dead match in 67 matches (not including Thursday where we probably played 10 matches there and also had no Comm issues), through 4 regionals and a national event. So it is hard for me to believe that this comes down to the field and does not have anything to do with the bot itself. Something on the bot must be causing this as well.

[RyanN]

I'm interested in the outcome in all of this. The way it is all described appears to be the same issues we had in Bayou. Connectivity issues without any reason that is simply blamed on the robot.

[Kevin Sevcik]

Originally Posted by steelerborn

I don't know much about the communications part and the FMS, I am just a CAD and Strategy mentor, but FIRST team 1671 The Buchanan Bird Brains have ran 3 years using the C-rio and not having 1 single dead match in 67 matches (not including Thursday where we probably played 10 matches there and also had no Comm issues), through 4 regionals and a national event. So it is hard for me to believe that this comes down to the field and does not have anything to do with the bot itself. Something on the bot must be causing this as well.

It's obvious that something about the robot is causing this. 118 and its alliance mates worked on Newton. 118 was the only Newton team that didn't work on Einstein. Obviously there's something different about 118. Telling a team WHY their robot is having a problem is helpful. Telling a team that their robot is having a problem isn't. The whole problem here is that FTAs are basically saying "Huh, your robot doesn't seem to work on this field." And then dusting their hands and walking off.

No, it's not quite that bad. Yes, there's a large list of suggestions to go through first, but 364, 118, and others have certainly done all those things. Once you're through that list, you're left with a broken robot and zero help or ideas.