Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)
-   -   Dashboard communication ports (http://www.chiefdelphi.com/forums/showthread.php?t=89989)

grandNagus 24-01-2011 19:36

Dashboard communication ports
 
Does anybody know what ports the cRio talks to to communicate with the dashboard?

byteit101 24-01-2011 21:04

Re: Dashboard communication ports
 
the default dashboard packet is UDP on 1165

jhersh 25-01-2011 01:15

Re: Dashboard communication ports
 
Quote:

Originally Posted by byteit101 (Post 1007544)
the default dashboard packet is UDP on 1165

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

-Joe

byteit101 25-01-2011 15:08

Re: Dashboard communication ports
 
Quote:

Originally Posted by jhersh (Post 1007812)
You are referring to the DS -> Dashboard traffic, right?

-Joe

yes

John Heden 28-01-2011 06:42

Re: Dashboard communication ports
 
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 28-01-2011 09:04

Re: Dashboard communication ports
 
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 28-01-2011 09:10

Re: Dashboard communication ports
 
Quote:

Originally Posted by John Heden (Post 1010271)

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 28-01-2011 16:20

Re: Dashboard communication ports
 
Quote:

Originally Posted by John Heden (Post 1010271)
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 29-01-2011 06:54

Re: Dashboard communication ports
 
Quote:

Originally Posted by sjspry (Post 1010547)
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 29-01-2011 15:37

Re: Dashboard communication ports
 
Quote:

Originally Posted by John Heden (Post 1010904)
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 30-01-2011 11:47

Re: Dashboard communication ports
 
Quote:

Originally Posted by sjspry (Post 1011142)
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 30-01-2011 18:06

Re: Dashboard communication ports
 
Quote:

Originally Posted by Alan Anderson (Post 1011644)
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.

Quote:

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 :D

John Heden 31-01-2011 06:53

Re: Dashboard communication ports
 
1 Attachment(s)
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 31-01-2011 19:15

Re: Dashboard communication ports
 
1 Attachment(s)
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 02-02-2011 10:05

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


All times are GMT -5. The time now is 03:52.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi