Just an idea...regarding the recent Control problems

[Timz3082]

So, when thinking about all of the problems that the FMS experiences that are of unknown origin. (Could be robot, connection, or FMS, or a combination that can't be tracked)
My idea is to have two separate connections to the robot,
One using a form of RF similar to the IFI control system to provide connection for mission critical tasks and connection to FMS.
A separate one nearly identical to today's 802.11 network that only is for external data and processing for camera tracking etc.
I am probably going to get a lot of flak as this would ad another level of unnecessary complexity to our bots, but if the two networks could be combined in one device, it could be better. DISCLAIMER: I am a mechanical dude, and though I am good with computers, electrical and software aren't my specialty.

[popnbrown]

There's a few issues with that. You would be basically looking at two separate configurations (to an extent) on your robot. You would have to manage a second network, and while it may not be hard, I don't think technology is not that good enough (correct me if im wrong) or cheap enough or not as complex to do that reliably, and quickly.

One of the issues with the field (possible issue) was the amount of 3G traffic going on and other potential Wireless Networks, if you have those networks right on the field, you could add quite a bit more issue to the mixing and messing up of the wi-fi networks.

Also, all suggestions are welcome, only way you or I will ever learn. You should be proud to just even think about this being a mechanical "dude". It shows that you're interested in finding solutions and not doing your "job". Good for you!

[Kevin Sevcik]

Originally Posted by popnbrown

One of the issues with the field (possible issue) was the amount of 3G traffic going on and other potential Wireless Networks, if you have those networks right on the field, you could add quite a bit more issue to the mixing and messing up of the wi-fi networks.

I figured I'd fact check your claim for you. According to wikipedia's Celluar Frequencies page, none of the cell frequencies come close to the 5GHz band that we're using for communications. So it's extraordinarily unlikely that 3G, 4G, or any other cell phone data usage were what affected robots on the field.

[vhcook]

I had a similar idea last night.

I do not agree that managing two networks would be too difficult. It's done in the wireless industry today as the normal mode of operation. Almost all of the smartphones in the arena yesterday will have had multiple transmission chipsets and internal antennae, to be able to do WiFi in addition to GSM or CDMA. Some of them would also have a third chipset and antenna for LTE or WiMax. In the phone context, the main problems are handset real estate and battery life, which would be substantially eased for us by the fact that an FRC robot doesn't have to fit in your pocket and run all day with a tiny battery.

I suspect getting a single device that does WiFi and whatever the other wireless communication would be might be difficult to find in an off-the-shelf product, since most dual mode devices I'm aware of are GSM or CDMA for their second mode.

I suspect that FIRST would rather fix the problem in the existing system than go to a more complex setup, which would require device selection and a lot of new software testing. I find myself wondering if the sheer volume of WiFi-capable phones, tablets, and laptops intermittently scanning for networks (if their WiFi wasn't off) might have contributed to the problem, although we should have seen it last year if that were the case. I doubt 3G and 4G services would have been a problem, given that they are indeed in very different frequency bands from the robots' 5 GHz WiFi.

[techhelpbb]

If you have problems troubleshooting one system.
So you create a second system with all the same constraints.

Now you potentially have two systems you have problems troubleshooting.

So far as I know FIRST has a backup WiFi system at the events. They can offer you a different set of D-Link APs that they have tested as more 'robust' against intereference.

I can only presume, as I can't recall hearing they were deployed, that they haven't seen a reason to use that hardware.

[Kevin Sevcik]

Code Bonde was used at FLR this year. There weren't any reports on it success, failure, annoyance, etc. in the FLR thread. FWIW, the super-duper bulletproof router used for Code Bonde is the D-Link DIR-825, which is currently available from Newegg for the astronomical price of $99. This compared to the KoP Bridge which you can have for the mere pittance of $75.

[JesseK]

Originally Posted by Kevin Sevcik

Code Bonde was used at FLR this year. There weren't any reports on it success, failure, annoyance, etc. in the FLR thread. FWIW, the super-duper bulletproof router used for Code Bonde is the D-Link DIR-825, which is currently available from Newegg for the astronomical price of $99. This compared to the KoP Bridge which you can have for the mere pittance of $75.

In all fairness, there's no telling how many Newegg has in stock at the $99 price, nor is there any indication on when the $51 price drop occurred. Does Newegg have 2,400 of those routers in stock? I doubt it.

[rjbarra]

Bring in Cisco to setup this network. Stop guessing and bring in people that do this for a living.

[Timz3082]

Originally Posted by rjbarra

Bring in Cisco to setup this network. Stop guessing and bring in people that do this for a living.

THIS I am sure Ciscon, depending on their current company health would love to once again donate and support robotics, as they had done for the 2009 and 2010 seasons. If not them, another networking company. I know Dlink has a cheap device, but we want one that WORKS no matter what, even if we have to pay more.

[DonRotolo]

Originally Posted by vhcook

I do not agree that managing two networks would be too difficult. It's done in the wireless industry today as the normal mode of operation.

Ja, but the endpoints aren't cRios. They may be slightly (slightly) more difficult to have handle a dual communications path

Originally Posted by rjbarra

Stop guessing and bring in people that do this for a living.

I'm wondering just what you think the people who DID set this system up actually do for a living instead? Sheep farmers?

Like we learned from Kevin Sevcik's post above, let's try to avoid speculation or uninformed assertions. We are gracious, but we need to stay professional too.

[vhcook]

Originally Posted by DonRotolo

Ja, but the endpoints aren't cRios. They may be slightly (slightly) more difficult to have handle a dual communications path.

Certainly, particularly given the port constraints of the cRIO and the fact that the wireless gear is custom designed for the purpose, while we're integrating existing devices. I'm just saying it's technically possible in the general case. There are probably easier ways to accomplish traffic segregation within the IP protocol anyway.

I'm also going to admit to a cognitive bias toward this kind of setup because I spend most of my time working on systems where control messages and user data are logically (and often physically) segregated to protect the control signals.

And on that note I'm going to let this go, since we don't even know if this solution matches up with the actual problem at all. Waiting on the troubleshooters without the ability to help is always the hardest part.

[mjcoss]

As I've said in other threads. To me there a several issues all intertwined, and it would be nice if we could decouple them.

First, all the robot are sharing the same wide channel @ 5Ghz. So they will compete for whatever bandwidth is available. How they behave will be dependent on the configuration of the various robots on the field. At best, you're looking at 150 Mbits for 6 robots, and even that is probably a stretch. Stream cameras, smart dashboards, custom dashboard, out of band messaging, and driver station traffic, and for those of us using 2CAN CAN bus traffic within the robot. It's a mess.

Second, the DLINKs seem to have a pretty high failure rate. Some have been known to work only when mounted vertically. Others intermittently fail. Is it power to the unit? Is it the barrel connector? Is it the PCB inside the DLINk? Is it firmware issues on the DLINK itself? What about the voltage regulator?

I set up a hardware capture during the MAR championship, and saw a number of teams stuck in a request to connect loop with their DLINKs and the field. Why some teams had this issue and others did not is unclear. The DLINKs are clearly not designed to be used on robots, powered as they are, and manhandled as only a FRC competition can. Also, I saw a lot of corrupted packets.

I have heard but cant confirm that there is an issue with the DLINKs and the number of SSIDs that they observe. If the number exceeds some threshold, they fail. It's certainly possible that this could be an issue.

I'd like to setup the network with 1 channel per robot. It would mean that they'd need 6 access points for the field, but it would increase the available bandwidth for all robots on the field, and each would be isolated from the other robots. There is enough spectrum that you can run 6 independent 5Ghz wide channels on the field. It would eliminate one variable from the equation.

Replacing the DLINK with a rugged AP would be a good thing as well.

And finally real time monitoring of the power to the DLINK or what ever AP is used would give a picture of what is happening as robots connect, and run during a match.

I work for BL research, and I offered to MAR to have some of our network researchers take a look at this problem, as I believe it is a real problem with the field, and not *just* a robot issue. The response was that they are looking into the problems. At the end of the day, someone will say that the problem is "fixed", and we will revisit the issues next year with a new set of parts and robots and we will never know the root causes.

Just my thoughts.

[Jon236]

We're not the only ones with problems:

http://news.blogs.cnn.com/2012/05/01...ved/?hpt=hp_t2

Our field issues are a real-world engineering problem, one that we need to not only solve, but learn from. That is what FIRST is all about. I think that after the folks at HQ work out a solution, that the process be transparent to the community.

[FrankJ]

To be fair the Dlink is intended to sit on somebodies desk. Not to be crashed around on a 150lb robot surrounded by PWM motor controllers & Brushed DC motors.

[Johnny_5]

Feel free to disagree but from the research I have done and speaking to knowledgeable FTA's and network engineers, the field setup they have right now is fine (note that is just the field, not robots).

There is nothing wrong with the current PLC system used for field IO and even the Cisco AP that is used to create the 7 WLAN's with the respective SSID's for each robot, 6 out of the 7 WLANs have a VLAN. The 7th WLAN is used for the pit monitor and the FTA monitor can be put on a tablet or laptop and used wirelessly.

The problem exists with the DLINK bridge system. We are using this unit for a different purpose than it was intended. Some may argue that it only happened to certain teams so that isn't the issue but it truly depends on the unit you have and where it was mounted. I personally think that FRC should switch to Cisco Aironet 1300's. These are a rugged wireless system that is meant to be abused. The only problem with these is the price is about $700 per unit. But maybe they can mitigate by moving some more components over to FIRST Choice and instead of buying as many components they buy the 1300's. And maybe dependent on Cisco's corporate health they can assist in funding as well.