Hello CD!
Team 4004 is looking into being able to have all of our robots be able to run at the same time for demos, driver training, and so on. Naturally we did find that we can do this by re imaging the CRIo with a new team number so that the bridges to not conflict, but we were wondering if anyone new of a better way to accomplish this task?
Thank you in advance!
Team 4004: MARS Rovers
With the way the current control system works, the IP convention of 10.te.am.x means that the “correct”, best supported, and most easily troubleshooted way to do it is to image each cRIO and router with a different team number and configure the driver station/IDE to that team number.
We are also interested in people’s experience with this. We tried this solution at a demo a few weeks ago where we wanted to play 2 on 2 matches on our practice field. We found that 2 robots running simultaneously was the maximum before all the robots started getting huge amounts of control lag. Switching off the extra robots fixed the problem. But, that’s not a useful solution.
Technically of course there’s no need to reimage cRIO’s so that the robots use different team numbers.
It’s a matter of keeping the networks separate and distinct.
It’s all in the DLink settings and the Driver Stations connecting to them.
The DLinks each must have different different SSIDs so you can tell them apart (we usually name them for the robot), and you probably want Security on them enabled just to avoid any unintended automatic connections being made (especially between Driver Stations and DLinks). Use a browser to login to the DLink and look under the Wireless settings.
Don’t allow any of the Driver Stations to automatically connect (unless they are exclusively used with that one particular robot).
Then manually connect each driver station to the DLink wireless of their choice through a Developer-type user account, then start the Driver Station app or login to a Driver-type account.
If it’s a noisy wireless environment and you get too many packet collisions then you can force each DLink to avoid conflicts by using different sets of channels.
We’ve run two simultaneously before by just changing the SSIDs in the radios as suggested. We run the radios in AP mode, configure them using our team number, then log in and change the SSID manually.
We routinely run 6 robots (different team numbers) thru one Dlink. So that by itself is not the issue. Possible issues could be multiple radios with the same SSID set to AP mode rather than bridge mode. There can be only one. Robots sending a lot data from cameras, etc. This is limited by the hardware on the First fields. A noisy environment. 5 gHz seems to be a cleaner than the 2.4 gHz band.
Other than that, use separate a SSID as Mark suggested.
This is the method we use without a problem. We name our robot by year - 1718-2010, 1718-2011, etc.
You definitely want to enable security, otherwise large amounts of lag can be generated by people randomly connecting to the dlinks when they see open networks (from experience).
Thanks for all the answers. I think we will try the unique SSID setting on the DLinks. That seems the easiest to implement and to keep straight. We’ll assign the robot name to the robot’s DLink and then link to only that one from it’s particular DS.
My limited knowledge with WiFi tells me that we should probably set the DLinks to different channels too so that they do not interfere with one another, correct?
I’d first start with letting the DLinks find their own channels. They do their own search for unoccupied channels and they are generally better at it.
Then examine the DS logs for lost or delayed packets. The logs highlight problems very nicely. If you see much of anything, then try setting your own DLink channels.
Things to watch out for include other APs and non-robot network traffic in the area where you are running. Letting the DLinks search on their own may avoid some of this.
There are several alternative network topologies (Robot IP Network Variations ) you can consider using from running just one or two robots, multiple robots in large group demos, or for off-season events. Just keep in mind that what may work at home may not work for a demo at a local shopping mall, so be prepared with alternatives.
The control system is especially susceptible to wireless channel congestion. What seems like a fine connection for loading web pages or even streaming videos may not be good for the robots (as they just disable themselves when they haven’t heard from the DS computer in a while.)
If you are in your own facility, try disconnecting other Wifi access points and turning off wifi on unneeded devices. If you are in public, try to configure your radios to use less busy channels somewhere in the 5GHz band.
We had a similar issue with lag when using a different router on our robot that we solved by setting the router to “hidden network mode”, which made it so the router didn’t broadcast its SSID, so you could only connect if you knew the name. I don’t see how hiding the name caused other network traffic to not effect our robot, but it did. When we switched back, the problem continued.
We have a permanent configured router at IP 10.0.0.4
It is a dual band N router, broadcasting two unique SSID’s. They are KELL2 and KELL5 for the 2.4 and 5GHz bands respectively.
All the robot bridges are configured to latch onto SSID KELL5 ( which solve a lot of problems in noisy environment when you are doing demos )
The robots are configured using the 10.xx.yy.zz scheme where xx.yy is the team number split, and the zz is the preassigned addresses, 1 for the bridge, 2 for the cRio, camera at 11, ds typically at 5
Our robots are
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
And it works perfectly great.
All the driver stations are hardwired into the router.
Development laptops connect to the router at 2.4 or 5 GHZ, doesn’t matter. The only thing about this scheme is developers have to manually set an ip address on their pc in order to get on the right network ( but now that I think about that, it could be fixable. )
Another thing is you can get a WiFi analyzer app for your phone that can scan WiFi channels and help you figure out what channel the bridges should all be on. At a pre-season scrimmage I found that 2 bridges on the same channel don’t interfere but any more, and/or any networks on channels within plus or minus 2 channels can begin to cause interference.
One trick that I have found to reduce lag in WiFi heavy areas is to encrypt and hide the robot’s network. Go into the DLink’s settings and enable encryption and check the box that says “hide SSID” or something similar on the wireless settings page. This will hide the SSID from devices that might try to connect to it. To connect to the network, you will have to search for the SSID. See this tutorial for details on how to connect in Windows 7. I have used this method at the Detroit Maker Faire with multiple robots and other WiFi networks many times with success.