The communication tides are shifting...

[Kevin Sevcik]

Originally Posted by DominickC

Wasn't the cRIO initially designed to be used in an industrial setting as a data logger?

It's a real time industrial control system. It's plenty hardy enough for what we're doing and the treatment we're giving it. I'm seriously doubting this is a hardware problem with the cRIO. It's possible it's a software problem with the cRIO or FMS, but the most likely answer really seems to revolve around our consumer-grade WiFi radios. The fact that a firmware change on the router causes massive communication problems is pretty troubling, really.

/sarcasm/ Yes, let's get rid of the crio and never again using vision processing or any of the cool advanced things introduced with it. /sarcasm/

The crio isn't the problem. It's the connection with the field.

I'm all for a new piece of equipment that better connects to field, but first we have to find one. Something we implement in our team is "don't shoot down an idea unless you have a better one".

So, get your heads a cracken and those brains a moven. Let's find us a new bridge.

[Chexposito]

Originally Posted by SuperNerd256

/sarcasm/ Yes, let's get rid of the crio and never again using vision processing or any of the cool advanced things introduced with it. /sarcasm/

The crio isn't the problem. It's the connection with the field.

I'm all for a new piece of equipment that better connects to field, but first we have to find one. Something we implement in our team is "don't shoot down an idea unless you have a better one".

So, get your heads a cracken and those brains a moven. Let's find us a new bridge.

Not sure how your team is doing vision processing... Most teams use the laptop for that to not reduce robot performance... Also, there was vision processing before the C-RIO. Look at Rack 'n Roll (2007)...

Anyways, C-RIO needs to stay. The kit needs some updates with more safety protection (built in) for the thousands of dollars in electronics we have. WI-FI will stay. It's secure and quick. The current problems lie within the field system. Also, the paranoia about wireless work in the pits needs to stop. If the system can't handle wireless pit work, then they are doing something wrong...

[Steven Donow]

Originally Posted by Kevin Sevcik

It's a real time industrial control system. It's plenty hardy enough for what we're doing and the treatment we're giving it. I'm seriously doubting this is a hardware problem with the cRIO. It's possible it's a software problem with the cRIO or FMS, but the most likely answer really seems to revolve around our consumer-grade WiFi radios. The fact that a firmware change on the router causes massive communication problems is pretty troubling, really.

Exactly. We're having data processed on an industrial-grade controller with a consumer-grade transmitter. That's the problem I see. I think the best we can hope for right now is that next year in the KOP we get a nice new radio that's much much more powerful than the one we currently have.

[DominickC]

If the issue actually does stem from our radios, why was this issue not uncovered in 2009 when FIRST switched over to TCP/IP?

[shawnz]

Originally Posted by DominickC

If the issue actually does stem from our radios, why was this issue not uncovered in 2009 when FIRST switched over to TCP/IP?

Well, aside from the fact that different wireless bridges were used in 2009, the problem may represent a more complete usage of the platform by teams now than there was then.

[efoote868]

I think we need find a radio supplier that will show up at each of the competitions to help us through our troubles.

Also, there needs to be a better way to diagnose the entire system. Event logging in the radios would help.

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

[MarkoRamius1086]

I do have to say a few small points, for what little it is worth. I worked as a Robot Inspector at both Virginia and North Carolina, and at the latter we had one particular culprit, that while it was a brilliant system, the implimentation to begin with was causing lag.

We were looking at the FMS data in realtime and interfacing with the teams to help solve problems (to my knowledge every issue we had was either related to robot code, low batteries due to the power shutdown during the night, and a few lose connections... no FMS issues). The one team that was initially causing lag had three cameras streaming at an extremely high refresh rate. They toned it down to an acceptable rate as soon as they were informed it was causing lag not only with their bot, but with other robots on the field.

These bandwidth issues seemed to cause lag, not any kind of complete and total interference with a single robot (ie. Red1). Feel free to correct me at any point in time, but those were my observations from behind the Pilot's seat.

[efoote868]

I have a contact at Quantenna Communications... For my co-op, I did wifi testing with their demo boards. It took quite a bit of distance to stress their product (on the order of 300-400 feet in a commercial building). I'll tell them they might have an opportunity for this niche...

[MarkoRamius1086]

The thing that keeps getting me is the fact that in all of the regionals I have been to, all of the feeds I have seen of champs, all the issues that come forward in the latter parts of the competition are robot issues... our troubleshooting at NC proved that! However, early in the game at any of them there are things that needed working out with the FMS... minor quirks.

We are talking about top notch teams here, NASA supported and more! Teams that won nearly every single match, teams that know what they are doing, enough to make it to Einstien in the first place!

In the hundreds, hundreds of matches that FIRST and this FMS system and the D-Links have gone through for all of FIRST... why was this problem not more common? I am nearly positive from the facts before me (what few they may be) that the D-Link is not to blame here. Something on Einstien's hardware had to be off or not optimized.

The only other thing that occurred to me is the correct setup of the routers. They went from one field to another, the same as going from our workshops to competition, or the practice field. If the routers were not configured correctly we would have the same issue.

What it is, I do not know. I am happy that the D-Link/FMS system works as reliably as I have seen it work in the past year... I saw very few issues at VA and NC... but I am severly dissapointed to hear that the Einstien hardware was never even tested (though I would love to be told otherwise).

Sincerely,
Petrie

[Johnny_5]

Originally Posted by MarkoRamius1086

But I am severly dissapointed to hear that the Einstien hardware was never even tested (though I would love to be told otherwise).

Sincerely,
Petrie

I think the FMS hardware that resides inside the Scorpion Case has been tested along with the PanelView screens that all of the ref's access before the rig was shipped field components and FMS gear. The field components were brand new but the FMS gear is also from last year. As far as I am aware the concept behind the AP controller getting controls from FMS about match information in the pre-start period and then passing it to the AP has remained the same ever since switching to the bridge setup.

This issue has happened on field all across the nation last year and this year. There are 18 trucks plus the one that resides on FedEx HQ and probably all of them have experienced that field issue.

The thing to do now is to go through all of the field data and FTA logs about which field did what under certain circumstances in certain environments. And I am sure FRC Engineering department will be busy all summer preparing a new fix for next year.

[techhelpbb]

Originally Posted by Johnny_5

The thing to do now is to go through all of the field data and FTA logs about which field did what under certain circumstances in certain environments. And I am sure FRC Engineering department will be busy all summer preparing a new fix for next year.

I think this task may not work for some cases. I can easily see with all the possible issues that some cases are in fact robot issues.

Team 11 had such issues and when the field logs were reviewed all that was discovered was that the robot lost communications.

The troubleshooting process entire simply needs to be expanded as well as the monitoring. If the logs were in fact highly detailed I think that the diligent field personel would have spotted faster ways to put a stop to what happened during Einstein.

In any event I agree this problem must, can and will be solved.

[Skinkworks]

My team's robot (3142) has never had connection problems. A lot of you are saying the control system dropped your team's connection multiple times, but did anyone here do FTC last year with Samantha? Rankings in FTC were largely determined by how many times your robot worked, because no one's robot worked more than 80% of the time. You don't realize how well the FRC FCS works.

I think what FRC has to do with the control system next year is give themselves a large amount of headroom on the bandwidth, and allow use of a more expensive, more reliable radio, along with an inexpensive option for all these new Boys and Girls Club teams. FRC could also take a radio and put an alternate firmware on it (dd-wrt), use QoS for FCS messages, and throttle bandwidth on accessory streams. This could also make flashing the radio quicker, since FIRST controls the protocol.

Also, a lot of control problems could be team-related, as impossible as that seems. Going back to FTC (experiencing a similar problem), my team had constant connection issues last year. This year, my team got a new Samantha, a new brick, new code, a new RobotC version, and there was a new FCS. The only shared factor between the two seasons was me, the programmer. My team still had connection issues. It has to be me, somehow, because most other teams had much fewer connection problems. Multiple people looked at my code, and couldn't see a problem. Yes, FTC is not FRC, but parallels can be drawn.