We’re currently ordering our 2nd system and the two obvious options to us on the Driverstation side were to wire it into the same router as the other Driverstation (which is what we are doing) or buy another router for it.
The only downside I can think of is that it requires the two control boards to be physically wired together during practice.
I had an idea though, and really don’t have near enough savvy with the new system to know if it would work. Could we purchase a gaming adapter like on the robot, and put that on to the 2nd controller to act as a bridge with the router? This would save us some money over buying another router, but still allow the convenience of not having to wire both controllers together.
Please let me know if this possible, or if I’m just being silly.
I haven’t looked over the documentation for the new system entirely yet, but it’s my understanding that the driver station needs a specific IP, which means that the two systems could not be networked together, as they would both be set to the same IP address.
As an aside, I know that somebody mentioned somewhere, for a non-competition system, you could look into using cheaper 802.11b/g hardware, rather than paying the extra for the 11n hardware…
Can’t you just change the last digit of the IP to something that isn’t being used, say 10.XX.YY.9? I think that would work for non-official practices and what not. There’s even a spot in you cRIO to define is as robot “2” if I remember correctly.
The easiest solution would be if the router (OI side of the wireless) supported the 255.0.0.0 subnet mask. If it did you would be able to have a 10.xx.yy.device network and a 10.aa.bb.device network. Unfortunately the router we were supplied with will only support a 255.255.255.0 subnet mask.
The reason this would work is that the subnet mask defines what IP addresses the router routes. For example if your routers IP was 10.99.99.4 (team 9999) with the subnet mask of 255.255.255.0 it will only look for devices with 10.99.99.x IP addresses on the LAN ports. If the subnet mask was 255.0.0.0 the router would look for all IP addresses starting with 10.x.y.z.
If you had a router that you could setup with a 255.0.0.0 subnet mask you would be able to setup 2 separate control systems on the same router as long as each control system had individual “team number” IP address sets. The router would just have to have any 10.x.y.z address.
Let me know if you have any questions on this. I would love to explain it more if needed
Okay, I think I was a little vague and also am having trouble keeping up with some of this.
We will have two control systems and two robots, and a gaming adapter on each robot.
We will have two control board, the comp bot control board has the given router, the 2nd we currently plan on wiring to the same router (and just setting a different team number). This is possible, and this works, correct?
What we were wondering, is could we take that scenario one step farther and eliminate the wire between boards by throwing a gaming adapter on the control board for the practice robot (remember, also a gaming adapter on each robot, each driver station set up with a unique team number). I’m pretty much wondering if we can simulate it being hardwired with that gaming adapter, or, does the driver station expect to be physically wired into a router (regardless of the number of other teams on that router).
We want to keep standardized equipment, we don’t want to delve into using other equipment. We also don’t want to use two routers.
Actually, the IP/subnet of the router interface is irrelevant to this. The router provided is, functionally, a 6 port switch with one port connected to a wireless access point, another connected to a router/NAT device, and four ports exposed for our use.
Since we are only communicating on a LAN, i.e. on a single switch, router device is never involved in the communications between the DS and the cRio.
You can test this by changing the Ip address of the router to something else. It will still work.
So long as each device has its own IP, which happens if you change you team number, and the subnet masks of the devices communicating(DSs and cRios) match, then it will work.
If you don’t read my whole post, if you change the team number on one DS and one cRio, then they will connect and not interfere.
If you have any questions I’ll try to explain it more.
Yes that will work. If you connect a game adapter to the second DS and configure it the same as you would for the robot, except that the IP address has to be something else. The specific address doesn’t matter, but I would set it as 10.xx.yy.254, where xx.yy is your real team number.
If you’re looking to save money you can use a lower price WiFi G adapter, but you would need to enable the 2.4ghz radio on the router.
This would also give you the added advantage of being able to debug/program/view dashboard totally wirelessly from both robots, assuming you have a laptop with wireless G or B. And yes, I have tested this and it does work. If you want more info just ask.
I wouldn’t be quite so quick to declare that this would work without any problems. The networking side of things should all work just fine with one router, a game adapter for each robot, and a game adapter for the spare DS. You shouldn’t have any problem getting everything to communicate if you set up the team numbers and/or IP addresses properly, since it’s all just local network communication.
However, that’s not to say that bandwidth isn’t going to be a problem. FIRST is going to be using a rather high end router set up and will be filtering any packets that aren’t necessary to controlling robots specifically due to bandwidth concerns. If you’re running your practice robots while trying to debug them, look at camera images, etc., then you might start instantaneously saturating the bandwidth of your network and cause your robots to start lagging or responding erratically. So if you’re going to be doing this, I’d recommend only running two robots like this for practice matches, and with the code booting off the flash disk in the cRIO, not running in RAM with your laptop debugging it. Just running the two robots in competition mode shouldn’t cause any bandwidth problems.
Our experience was a bit different during the beta period. I agree that what you say should be the case, but it does not seem to be in the case of the linksys router that we were shipped with. The router appears to do some filtering on the switch that interferes with having multiple subnets.
I’d be happy to hear if any one has an explanation for what we observed.
Case 1) router out of the box - IP address 192.168.0.1, - everything worked fine, using static IP for computers and robot (set to 10.0.0.X or 10.14.25.X depending on where we were in the configuration process).
Case 2) router set to 10.14.25.1 with DHCP enabled, netmask 255.255.255.0.
In this case things work well except if we need to reimage the cRIO using the imaging tool (format, not just retarget C++ - Labview). If the robot was connected directly to the router, the re image would fail due to network failure at the point where the IP address was changed. If the robot was attached wirelessly, the reformat/reimage process would work.
This leads me to belive that the router would not be well behaved if you are trying to use a different team number.