Dashboard communication ports

[byteit101]

the default dashboard packet is UDP on 1165

[jhersh]

Originally Posted by byteit101

the default dashboard packet is UDP on 1165

You are referring to the DS -> Dashboard traffic, right?

-Joe

[byteit101]

Originally Posted by jhersh

You are referring to the DS -> Dashboard traffic, right?

-Joe

yes

[John Heden]

With respect to communications in the other direction, Update #5 (25-Jan-2011) states that UDP 1130 is being available for “Dashboard-to-Robot” Communications which is highly suggestive that we are now allowed to communicate to the Robot from our own dashboard and overrides Rule 75 where the Driver Station is the only tool allowed to collate driver/operator inputs and send them to the robot.

This is a big change opening many opportunities for enhanced leveraging of the PC facilities (screen, keyboard, touch screen, ANY USB device, etc) at the console.

Does anyone disagree with this interpretation that we ARE now allowed to directly send data from our dashboard to the Robot ?

[Mark McLeod]

The question needs to be asked directly in Q&A before we start deciding for ourselves what rule takes precedence over what other rules.

"During competition are we allowed to control the robot from Dashboard controls rather than purely Driver Station controls?"

[BEEKMAN]

Originally Posted by John Heden

Does anyone disagree with this interpretation that we ARE now allowed to directly send data from our dashboard to the Robot ?

I posted this question on the Q&A two nights ago and have not heard a response yet

[sjspry]

Originally Posted by John Heden

With respect to communications in the other direction, Update #5 (25-Jan-2011) states that UDP 1130 is being available for “Dashboard-to-Robot” Communications which is highly suggestive that we are now allowed to communicate to the Robot from our own dashboard and overrides Rule 75 where the Driver Station is the only tool allowed to collate driver/operator inputs and send them to the robot.

This is a big change opening many opportunities for enhanced leveraging of the PC facilities (screen, keyboard, touch screen, ANY USB device, etc) at the console.

Does anyone disagree with this interpretation that we ARE now allowed to directly send data from our dashboard to the Robot ?

No, this doesn't override rule 75. The dashboard is separate from the driver station. So no, all that great stuff you talked about isn't possible.

But yes, you can communicate however you want as long as all teleop goes through the driver station. I'd suggest, however, to not reverse-engineer the current protocol and just make your own (like I did).

[John Heden]

Originally Posted by sjspry

No, this doesn't override rule 75. The dashboard is separate from the driver station. So no, all that great stuff you talked about isn't possible.

But yes, you can communicate however you want as long as all teleop goes through the driver station. I'd suggest, however, to not reverse-engineer the current protocol and just make your own (like I did).

A literal interpretation of R75 where the driver is the only tool to collated driver/operator inputs seems to preclude ANY such dashboard user interaction (setup, teleoperated, etc.) but could allow for automated control from algorithms in the driver station as long as the data did not derive from the operator/driver inputs. Allowing a powerful laptop to do the vision processing and returning the results via this dashboard UDP port seems like a valid rule interpretation but not the likely intention. I’m still very curious as to some further rule info detailing on this UDP 1130 reference and some further specifics on what is/is not allowed. This “dashboard to robot” communications remains a tad ambiguous until we have a official response. It was very easy to get the basic UDP receiver operational on both the dashboard and the robot and would happily share this. If only we knew what we could do with it….

[sjspry]

Originally Posted by John Heden

A literal interpretation of R75 where the driver is the only tool to collated driver/operator inputs seems to preclude ANY such dashboard user interaction (setup, teleoperated, etc.) but could allow for automated control from algorithms in the driver station as long as the data did not derive from the operator/driver inputs. Allowing a powerful laptop to do the vision processing and returning the results via this dashboard UDP port seems like a valid rule interpretation but not the likely intention. I’m still very curious as to some further rule info detailing on this UDP 1130 reference and some further specifics on what is/is not allowed. This “dashboard to robot” communications remains a tad ambiguous until we have a official response. It was very easy to get the basic UDP receiver operational on both the dashboard and the robot and would happily share this. If only we knew what we could do with it….

You're reading too far into this. From what I remember (I can't look up the rules right now), the mention of those port numbers sounds like (and was likely intended to be) a preventative measure, as in, "don't use these as they're being used already". They probably don't intend for you to reverse engineer the dashboard protocol or send your own information on these ports.

Regardless, this rule has nothing to do with the driver station. I myself am rather confused as to why they insist on all human-driven input going through their software, as it would already be possible under the rules to modify the cRIO to negate any "safety" benefits from this.

And I noticed the computer-driven control exception myself. I moved image processing to my driver station as I wished to write my own, and I believe someone else was going to do much the same thing so they could use OpenCV, something more featured than the NIVision on the cRIO.


Remember the Dashboard and the Driver Station are completely separate. The Dashboard NEVER sends back information, while the Driver Station is the one to initiate everything as far as rounds/teleop/autonomous goes, therefore the interpretation of "all human input must go through the Driver Station" is by far the most valid interpretation.

[Alan Anderson]

Originally Posted by sjspry

From what I remember (I can't look up the rules right now),...

Most of your post seems based on a faulty memory of what the rules say. Please read the description of what ports are available in section 2.2.8 (as amended in Team Update #5).

[sjspry]

Originally Posted by Alan Anderson

Most of your post seems based on a faulty memory of what the rules say. Please read the description of what ports are available in section 2.2.8 (as amended in Team Update #5).

Oh, I didn't see the update that said what the ports were actually for.

Originally Posted by Rules Update #5

All these ports are open on the playing field, so a team can use them as they wish if they do not
employ them as outlined above (i.e. TCP 1180 can be used to pass data back and forth between the
robot and the DS if the team chooses not to use the camera on port 2).

Then I guess it's a contradiction. Since it's the newer rule, I'm glad they're allowing bypass of the driver station software

[John Heden]

Greetings,

We are moving forward with our "Dashboard to Robot” communications approach which appears to be legal (our current interpretation) with update #5 where UDP port 1130 is available for “Dashboard-to-Robot control data”. The update #5 statement that these ports “are open on the playing field, so a team can use them as they wish” is fairly unambiguous although we recognize the <R75> inconsistency where it is stated that the DriverStation is the only tool allowed to collate driver/operator data to the robot.

While we are moving forward with our Dashboard plans to allow user interaction with the robot, we’ll continue to monitor the FIRST site for any further clarification on this subject and will graciously remove this capability should our interpretation later be shown to be incorrect. I’m attaching a C++ example function where we have successfully received UDP packets from our dashboard.

John

[John Heden]

I'm attaching an example code fragment in C# that we used to send UDP dashboard data to the CRIO example given in the previous post. I could not attach an additional file so I'm adding another reply. The system would not take a .cs file so this is a .txt file.

[BEEKMAN]

We got this working several nights ago, and according to Team Update 7, looks like its a go!