Dashboard communication ports

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

[John Heden]

Thanks! The ability to send Dashboard user data to the robot was our (hopeful) interpretation but the Update #7 Rule 75 change makes this possibility very clear. This is a big change allowing much more user & driver interaction possibilities where we are no longer constrained/limited to physical USB HID components.

<R75> The Driver Station software provided on the FRC website (www.usfirst.org/frc/kitofparts) is the only tool permitted to specify and communicate the operating mode (i.e. Auto/Teleop) and operating state (enable/disable) and collate driver/operator inputs and communicate them to the ROBOT. The Driver Station software must be revision 01.05.11.00 or newer.

[basicxman]

Any word from the official Q&A forum on this yet?

[Alan Anderson]

Originally Posted by basicxman

Any word from the official Q&A forum on this yet?

The GDC has spoken.

Team Update #7 amends the rules such that the Driver Station program is no longer the only permitted conduit for driver inputs to reach the robot. (John misquoted the new <R75> by failing to either mark or delete the stricken text that was identified in the update. Read the manual.)