Robots sharing information

[scca229]

Originally Posted by dave1027

So during competition the robots and driverstations for each team are segregated by individual vlans corresponding to the team number. Is it possible for cross VLAN communication to occur? I an not a network engineer but i work with equipment on several VLANs and as long as there is no firewall between them, i can access information on the other VLANs as long as i know the IP i am looking for.

Specifically: If i have an IMU with its own controller and network interface at say IP 10.10.27.8, connected to my wireless bridge, could a member of team 256 (whos IP is something like 10.02.56.1) go to that IP and determine my location on the field? If so, all six robots could know the position of the other robots on the field.

Or could i go to team 256's onboard IP camera and pull images?

If there is a firewall between the VLANs, what do you think is the possibility of the Field Technical Authorities opening specific IP tunnels to allow this? As long as the IPs do not conflict with the communication path between the roboRIO, Driverstation, and field i would not think it is a problem.

This would only work if routing is allowed between the VLANs on the router that the switch is connected to which houses the VLAN subnets. As far as I know from seeing the router config during a field troubleshooting session 2 years ago, that isn't the case.

[Jared]

It's not possible with the current FMS setup.

The only device that can communicate with your robot is the laptop plugged into the correct slot. Even the enable/disable state and robot stats (battery voltage, dropped packets...) are sent through your driver station laptop. No other robots or laptops can communicate with the robot.

It is also not possible to get driver station laptops to communicate with each other.

[techhelpbb]

Originally Posted by Jared

It is also not possible to get driver station laptops to communicate with each other.

Through the field network you mean.

http://www.chiefdelphi.com/forums/sh...21&postcount=4

Of course to do what I proposed above you should verify by asking in the official Q&A after kick off.
There is no hard and fast rule I have seen that would prevent inter-team electronic communication as long as it honors the field requirements and does not present a safety hazard.

[Jared]

Originally Posted by techhelpbb

Through the field network you mean.

http://www.chiefdelphi.com/forums/sh...21&postcount=4

Of course to do what I proposed above you should verify by asking in the official Q&A after kick off.
There is no hard and fast rule I have seen that would prevent inter-team electronic communication as long as it honors the field requirements and does not present a safety hazard.

Fair point. I saw a cool electronics demo where the audio output of a ipod was amplified to drive a small laser pointer. This laser pointer shined onto a photodiode, which was used to drive a speaker. It worked very well over a distance of about 10 feet.

[techhelpbb]

Originally Posted by Jared

Fair point.

For a few years I've been joking with Team 11 when we split into Team 11/193 that if we split again we can own a whole side of the field.

Then integrate light based communications into all 3 robots and make them electronically cooperative. If it wasn't for some of the rules maybe make them join into a bigger robot after the match started.

The trick is not really finding a way to communicate in a way FIRST might approve and may not even realize you have been doing. The trick is getting everyone involved on the same page to leverage it. Any team with a camera and a light source right now could strobe that light source and read that with the camera off the retro-reflective tape allowing the robots to communicate. FIRST already approves the cameras and the light sources. So really what can they do about this in the absence of a new rule?

You could actually code this at the competition and probably wire it up if you can get all the people involved to cooperate.

[RyanShoff]

What rules would prevent adding a second ethernet port on the driverstation laptops (usb dongle) and setting up a private alliance network?

[techhelpbb]

Originally Posted by RyanShoff

What rules would prevent adding a second ethernet port on the driverstation laptops (usb dongle) and setting up a private alliance network?

I would ask in the official Q&A.

The larger issues I see is that such a device would appear in your local network routing table. This could cause you some grief if your default route goes to the wrong place (though the field should see that as a lost connection to your driver's station).

This would also result in a wire not related to the field going from one or more of the teams to others. That might be considered an issue but that is not for me to say.

[cgmv123]

Reminder that 2014 rules are not 2015 rules and the FMS is undergoing revisions for the new control system.

Originally Posted by RyanShoff

What rules would prevent adding a second ethernet port on the driverstation laptops (usb dongle) and setting up a private alliance network?

T22Ei says any special equipment can't connect or attach to the OPERATOR CONSOLE(s). The laptop is part of the operator console, but I'd have a hard time believing cabling that links multiple consoles is.

R94 could also come into play, since the cables would extend beyond the 60" x 14" footprint and aren't worn/held by drivers.

[Alan Anderson]

Originally Posted by techhelpbb

Any team with a camera and a light source right now could strobe that light source and read that with the camera off the retro-reflective tape allowing the robots to communicate. FIRST already approves the cameras and the light sources. So really what can they do about this in the absence of a new rule?

First, I don't see how using retroreflective tape would do anything special to allow communication. You could blink your light at the tape and see that you did it, but other robots wouldn't notice anything. They'd have to be looking at your light directly.

Second, the existing rules already disallow active robot-to-robot communication:

Originally Posted by <R55>

One (1) D-Link Wireless Bridge (P/N: DAP-1522), hardware revision B, is the only permitted device for communicating to and from the ROBOT during the MATCH.

They also prohibit any signalling between operator consoles:

Originally Posted by <R95>

Other than the system provided by the ARENA, no other form of wireless communications shall be used to communicate to, from, or within the OPERATOR CONSOLE.

However, <R95> was judged not to apply to waving at cameras, so the blinking light option might still be viable there.

[techhelpbb]

Originally Posted by Alan Anderson

First, I don't see how using retroreflective tape would do anything special to allow communication. You could blink your light at the tape and see that you did it, but other robots wouldn't notice anything. They'd have to be looking at your light directly.

Line of sight or reflected line of sight.
It's just a bank shot and the focus of the goals is usually where the tape is.
Cooperative targeting.

Even without the retro-reflective tape a laser spot in a predictable spot could send a signal other robots, drivers or driver's stations could collect (speaking practically - not saying the rules allow that).

Second, the existing rules already disallow active robot-to-robot communication:

You mean other than pushing each other out of the way, assisting a partner via contact or tossing a game element cooperatively?
FIRST has a lot of full contact robot to robot communications going on every match.
We have sensors that could detect objects on the field that the robot might interact with and with that information one could determine the proximity of other robots which would communicate position information between robots.
There is no rule I see that says that we can't build a sensor package that locates other robots or react to that information.

If this rule applies then this is a poorly enforced rule.

Also between the robot and the driver's station there's the FIRST supplied RSL light.
That's a visual indicator that can instruct the driver's to change the state of their driver's station.
There have also been several visual examples over the years of teams visually signaling their operators from the robot both to the field (in the form of a spot light) and indicators.

So this is also questionably enforced.

They also prohibit any signalling between operator consoles:

However, <R95> was judged not to apply to waving at cameras, so the blinking light option might still be viable there.

I will look up later where the official Q/A question I asked previously is.
Basically I wanted to put lights in the driver's station window that the robot could visually lock onto to locate itself on the field. It was effectively one time passive communication and these lights could have been seen by all the robots on the field looking at that end.

Obviously visual targets like this are plentiful on the game fields but I liked the idea of simply controlling the target ourselves. This ends up being communication between control systems if 2 or more teams choose to use it. The robots will react and the information to control the robots will come from each driver's station indirectly.

Originally Posted by cgmv123

T22Ei says any special equipment can't connect or attach to the OPERATOR CONSOLE(s). The laptop is part of the operator console, but I'd have a hard time believing cabling that links multiple consoles is.

Perhaps but there have been several boards floating around that could be connected to the driver's station.
Though I have never actually done this so maybe there is a rule against it somewhere?


If someone is really serious about using this they really should propose it and ask in the official Q/A.
By the time that can happen the game will be set, the rules will be there and the consequences will be more clear.

[FrankJ]

The rules say the FMS ethernet cord most connect directly to the driver station computer. (IE not via a team supplied switch) The robot enable commands most originate from the approved driver station software. Other than that, what you can physically attach to the driver station is pretty open as long as it doesn't violate other robot rules. The cypress board is an example of a board connecting to the driver station.

[techhelpbb]

Originally Posted by FrankJ

The rules say the FMS ethernet cord most connect directly to the driver station computer. (IE not via a team supplied switch) The robot enable commands most originate from the approved driver station software. Other than that, what you can physically attach to the driver station is pretty open as long as it doesn't violate other robot rules. The cypress board is an example of a board connecting to the driver station.

So then I guess the question is why can't one Cypress board blink an LED and the other monitor that LED through the barrier with a photo-transistor? Again FIRST could cry foul over this but why? It leads to cooperation? If it is a safety concern I would like to understand that concern. Right now teams can easily communicate themselves within hearing distance of those driver's stations. We can't really stop them from verbalizing to each other.

Am trying to figure out when this question about using lights in the driver's station was answered by FIRST.
Anybody have the 2011 Q&A? The link in the archive seems to be broken.
I have e-mails from 2011 and 2012 pondering this so somewhere in that range.

[dave1027]

A side from the vague reference to rules that disallow robot to robot communication, does anyone know the actual rule that does not allow this? I am pretty good with rules and regs and do not remember it specifically being against the rules. Infact in the spirit of co-opertition I would think this would be encouraged.

I am proposing an open hardware/software solution for a standardized protocol for sharing information between robots,

While light based applications could technically function the bad part is that they require line of sight to work, the nice thing about the field based network is that it already exists and would require very little effort to make it work.

[techhelpbb]

Originally Posted by dave1027

While light based applications could technically function the bad part is that they require line of sight to work, the nice thing about the field based network is that it already exists and would require very little effort to make it work.

Personally I am of the opinion that the field network is already stressed to the max by multiple teams using TCP based real time video back to the driver's stations.

These TCP flows can be so large that the video actually starves the UDP FMS packets to the robots and can often end up with your robot disabled and your control performance compromised. These show as missing packets on the field display and in the driver's station DS logs. FIRST made a serious investment in load balancing for the fields to keep this problem bottled up.

I would be concerned that opening the door to bi-directional inter-team communication on a network that can be so heavily saturated could lead to headaches where one team could inadvertently swamp their own alliance.

In this regard reducing that protection might not improve things for your alliance.

The other solutions (though line of sight) at least move this extra load off the field making the proof of concept a little less likely to result in unpleasant surprises. So in this regard I think the amount of effort for FIRST to actually QA this on their field network is way bigger than anyone realizes.

This also, in my mind, falls back into the idea that such communications should be simple and short lived.
The alternatives to the field are slower and will encourage brevity and simplicity.
Why send full video to your alliance peers when you can send messages like 'ready to shoot'?
TCP/IP is too often used like a hammer and every communications problem becomes a vastly more complicated nail.
(Ironic I wrote this because I have been writing Ruby HTTP functions all day that can do Windows Authentication without using the existing work which tends to mask exceptions I need to see for security reasons. So I make this post and then get back to my POST / HTTP/1.1).

[Doug Frisk]

Originally Posted by techhelpbb

Personally I am of the opinion that the field network is already stressed to the max by multiple teams using TCP based real time video back to the driver's stations.

I worked as scorekeeper last year which meant that I was watching the bandwidth during matches. Last year, the stated limit was 7 megabits/sec. Very few teams reached that but there were several who went over 8 and one or two teams I saw that could suck down 20 Mbits/sec.

All other things being equal, even with 6 teams each consuming 20 Mbits/sec that shouldn't saturate the WiFi network. That much traffic would barely register as a blip at the Cisco box that's managing the routing. In all cases when I brought up excessive network usage, simply asking the team to adjust their camera settings brought the usage down. Just because your camera can transmit at 1080p 60fps doesn't mean that your display can even manage to show you that.