Robots sharing information

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

[Chief Hedgehog]

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.

Oh goodness - what a blessing that would be! Or a curse! However, the way I see it working for our current 2014 robot it would allow the driver to abandon the driver functions in order to allow for the most optimal truss pass. And for our 2013 robot it could place us in the most optimal position for interfering with the opponent's FCS or optimal cycler.

[techhelpbb]

Been thinking about this some more...

When it comes to the idea of sharing video between teams which is less complicated?

1. Sharing or worse duplicating the video over the network to the other teams.
2. Offering them to look at your display of that video?

Obviously 2 is far less complicated!

If FIRST really wanted to allow this all they would have to do is allow teams to put an extra monitor on their driver's station which the other alliance members could see. Or they could let users transfer their images to Android devices as mass storage over USB from their driver's station and simply run a slideshow against that storage to the display in the same manner. Put that up against the barrier and the team immediately next to you can see your video with no field network load. Just some additional COTS device and some cables.

Also it occurs to me that when I helped propose an alternative to the cRIO we suggested that we send the FMS packets down a separate slower lower frequency radio link and let the teams use any other WiFi however they like. This would of allowed teams to share as they like as WiFi would be completely irrelevant to the FIRST field operations and it would dramatically remove the spectrum competition for the radio. Course it also would have made it the teams headache to deal with the consequences if it went terribly wrong or was interfered with.

I am personally of the opinion that the field's use of WiFi in this manner is actually more annoying to the people that want to use WiFi and TCP/IP for things like video and sharing than if the field only sent the FMS packets on a lower frequency. It puts FIRST in the position of stifling innovation to protect the field operations for business reasons. It also also gives the students trying to use TCP/IP less opportunity to be exposed to the entire operational aspect because they simply can't control what the current fields impose on them. What the current field does now is not truly analogous to real time video over most of the Internet so that is not a salvageable counterposition.

[Greg McKaskle]

I attend a good number of FIRST events, and I have a few tools that I use to look at the wifi spectrum. I've attached a few screenshots from Michigan State Champs last year.

The first is a bit fuzzy, but shows that on the campus, there were lots of other access points. Venues differ ALOT, and some are wifi-crowded. The field doesn't show up because it doesn't broadcast its SSIDs.

The second photo is the wifi usage on the channel(s) that the field was using. It is shown three ways. The lower one is total packets per second for each 100ms period. The middle one shows bytes transmitted per second. The top shows airtime being used, and is on top because this is the best indication of how much more you can transmit before you hit the ceiling.

The stacked colored bands are the traffic caused by each robot, and the external stuff is gray. There is a white line plotted over the rest that is the retransmissions.

To summarize what this says ... The robots in these matches were typically using 10% of the wifi spectrum. The spikes due to a radio momentarily shifting to slower speeds caused a momentary spike to 25%. If this had hit the ceiling and caused other radios to slow, it would have been a Xmas tree event. I logged the entire weekend and never saw a tree.

Another factoid? There were 1217 unique MAC addresses that showed up on the 5GHz wifi channel on Saturday -- a few of those are even robots. But most of those devices are simply looking to see what wifi networks are available. They build the list and go dormant again.

I have never been at an event where wifi was stressed to its limits. I have heard stories, and I believe it has happened. I do not believe it is common, and FIRST is diligent at using the wifi that is available to run the best matches possible.

By the way, I have also seen matches where individual robots are sending 20Mbps HD video. The sky didn't fall. The team was asked to change camera settings. No big deal. The wouldn't be nearly as simple without usage guidelines.

I'm not claiming that things can't be made better, but before we try to fix the problem, we need to measure quantitatively what is actually going on.

As for the original topic. The field controls whether robots can communicate with each other over its AP. It cannot happen without the field specifically allowing it and coordinating it.

Greg McKaskle

[techhelpbb]

Originally Posted by Greg McKaskle

...
To summarize what this says ... The robots in these matches were typically using 10% of the wifi spectrum. The spikes due to a radio momentarily shifting to slower speeds caused a momentary spike to 25%. If this had hit the ceiling and caused other radios to slow, it would have been a Xmas tree event. I logged the entire weekend and never saw a tree.

Were the robots involved during this sample sending video and if so how?
As CSA we are not usually asked to find this out.
Perhaps the Robot Inspectors know?

I have never been at an event where wifi was stressed to its limits. I have heard stories, and I believe it has happened. I do not believe it is common, and FIRST is diligent at using the wifi that is available to run the best matches possible.

On this I give FIRST credit. They have acknowledged there can be an issue and they do make an effort to limit the potential. It is hard however, as noted, to get everything in the field area to comply with these desires.

By the way, I have also seen matches where individual robots are sending 20Mbps HD video. The sky didn't fall. The team was asked to change camera settings. No big deal. The wouldn't be nearly as simple without usage guidelines.

I agree the presence of the load balancing does restrict the consequences of a robot operating outside of the reasonable expectations FIRST offered.

I'm not claiming that things can't be made better, but before we try to fix the problem, we need to measure quantitatively what is actually going on.

I have long given up on attempting to catch something like this myself because simply put everyone that tries is doing so at a disadvantage. The field venues change. The field settings could change. The robots can change.

For the purpose of sending the tiny amount of data FMS really needs the WiFi is just fine. Unfortunately with so many people sending video to driver's stations FMS is just plain drown out. Hence the increasing issues noticed the more people have sent video to the driver's station since FIRST started using WiFi. The result at the moment is usually an impact on just the team that needs to adjust their vision system and for that I am grateful because I do not believe it was previously the case before the load balance (call it a gut feeling - I can't go back in time - and now it does not change anything).

In the end WiFi is way more bandwidth than is really needed for FMS. So even compromised quality WiFi would work out if it wasn't for the video demands being put in competition. Even more so if the programmers of the robots make their code keep the robot moving in the last instructed direction/speed/operation until new instructions arrive. Then unless enough FMS packets are missed to disable the robot the robots can still maintain control performance even if FMS is missing some packets here and there. I think that example of dropping 5,000 of 7,000 FMS packets for a team with such software is adequate (this is an example from RampRiot 2014 I presented in another topic).

[Greg McKaskle]

The thicker bands in the attached image used video to the DS, the thinner ones didn't use it or used very little. There were matches with lots of cameras.

Greg McKaskle

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

[techhelpbb]

Originally Posted by DareDad

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.

If adjusting their cameras to send less data is reducing the missing packet count the I propose team links are saturated.

The ideal bandwidth of a WiFi network does not apply in a situation where the robots are mobile (actually it doesn't usually apply in a situation where the radios are stationary either). The links actual bandwidth will change based on the ability of the radios to deliver the data.

The only way you can know for sure what the actual bandwidth to your radio is to try it and once you do with TCP you will hit the congestion control of the protocol which in many cases will magnify the saturation because the goal is reliable delivery not worrying about your link's issues. Now where are you going to try from and in what orientation to measure the bandwidth since the robots move around and are all constructed differently?

Order of falsehood: lies, statistics and datasheets.
Just because your Cisco/D-Link box says a bandwidth does not mean you have that bandwidth it's just a 'datasheet'.
It falls on the reader of the data sheet to understand the implications and criteria of that performance.

Also with respect to barely registering a blip. I own a police package Chevy Caprice LT1.
That car has a digital dashboard with three digits and a theoretical maximum display of 999MPH.
At 140MPH if the windows are open the car might catch air (there is a sticker on the dash board from GM).
At 180MPH you are playing with fire and I have been over 150MPH on a track with that car.
Just because the top of the scale is somewhere does not mean the scale represents realistic expectation.

This would be interesting:

Let's take some FIRST robots and drive them around using 2.4GHz like they are not on the field using on D-Link.
However these robots really will be on a field.
Let's put the another D-Link and DC/DC converter on 5GHz and drive these robots on the field.
Don't even worry about the FMS system.
Have a device on each of the 6 robots blast sequentially tagged UDP packets to the driver's stations over 5GHz.
Have a device on each of the 6 driver's stations blast sequentially tagged UDP packets to the robots over 5GHz.
Turn off the load balancing on the field and track to see how many of the packets you sent around you really got.
While all that is going on - drive the robots around.

Now there's no magic. No congestion control. Just raw bandwidth use as long as the devices are each capable of sending packets at a respectable rate and that can be easily tested by wiring them on a switch before hand.
So how many packets do you think will not survive this test?

Now change the packet payload in increments up the MTU for a few tests.
Graph the results and see how the network responds.

Let's make this even easier - start with an application like iperf on Linux (because it can pthread).
It could be a little more custom for this application but it already produces the sequence and the data.
Can probably graph the results with jperf or some VBA.

[Alan Anderson]

Originally Posted by techhelpbb

If adjusting their cameras to send less data is reducing the missing packet count the I propose team links are saturated.

During the past two years, the "saturation" issues I have seen have never been shown to be due to WiFi bandwidth limitations. In every case where I watched a dropped-packet problem being fixed by reducing camera frame rate and/or pixel count, it was because the computer running the Driver Station program was unable to keep up with the incoming packets. The packets themselves were obviously being delivered just fine by the network.

In my experience, the CPU usage of the Driver Station computer is more important to the performance of the robot than the bandwidth usage of the WiFi network.

[techhelpbb]

Originally Posted by Alan Anderson

During the past two years, the "saturation" issues I have seen have never been shown to be due to WiFi bandwidth limitations. In every case where I watched a dropped-packet problem being fixed by reducing camera frame rate and/or pixel count, it was because the computer running the Driver Station program was unable to keep up with the incoming packets. The packets themselves were obviously being delivered just fine by the network.

In my experience, the CPU usage of the Driver Station computer is more important to the performance of the robot than the bandwidth usage of the WiFi network.

I have seen Intel Core I7 laptops have this problem.
In my ISP days such readily available CPU would be considered crazy powerful.
I've had whole ATM backbones running with proper interfaces saturating DS3 with less CPU.

I've had the Windows performance counters on these laptops open before and not seen such an indication but via WMI all of that data can be logged into the DS log viewer if one wants. There are plenty of PowerShell examples around for this and via .NET there are plenty of MSDN examples. I do stuff like that all the time on enterprise networks.

Also if this was the case why do these teams often not experience this issue when tethered or in their private networks?

Then there's the before and after Einstein to consider. Before you could pump data as hard as you pretty much liked till something refused. Now the load balancing will cap you before you can do that and potentially steal opportunity from other teams to use the network. So in theory if teams could use a combined 20Mb/s before over the field why are these laptops so pegged now that they are capped at less?

I think these might be relevant:
DAP-1522 performance test from IEEE
CISCO 1250 performance test from TI

[Nate Laverdure]

Originally Posted by techhelpbb

...light based communications...

Along the same lines