There is another interesting thread (Is the FIRST Touch PsoC Board the only option?? ) with references to R50 and suggesting the possibility of using UDP port 1140 to communicate from a custom dashboard directly TO the Robot rather than being strictly limited to a handful of joystick & I/O calls. This R50 UDP 1140 reference, however, is under the cRIO-FRC Ethernet Port and perhaps does not apply broadly. R52 states that all communications must originate from the Operator Console and/or Field management system. If 1140 is not blocked, can we transfer small quantities of data TO the robot from our console on this port ? I can’t find any rule that explicitly prohibits this but can’t be sure the FRC system would enable this either. This would open the dashboard for a number of great driver options where they could interact through dashboard virtual screen objects rather than purely physical USB devices…
Quote from http://www.chiefdelphi.com/forums/showthread.php?t=88758
“If I recall UDP 1130 may be used for traffic from the Dashboard (Driver Station Ethernet network cable) to the Robot and UDP 1140 may used for traffic from the Robot to the Dashboard”
Any toughts on this possiblity would be greatly appreciated.
Well, as far as I can tell from rule 75, you can’t send operator input which bypasses the driver station.
If you wanted to send something else, you can do it from any port, actually, as long as you have something on the robot to receive it. In Java, at least, you’d use Connector.open(“socket://10.xx.yy.5”) and related classes. I’ve not worked with C++, but you could look for the functions “socket”, “recv”, and “send”.
Thanks for the R75 reference, I suppose that makes it a bit unambiguous if the Driver station is the only tool that can collate the operator/driver inputs.
We’ve also thought about the possibility of a simple “pseudo” (virtual) USB HID device that would be used to mimic a physical HID Joystick could encode operator data from the dashboard (operator or automated calculations) through the various Joystick APIs (GetX(), GetY(), GetZ(), GetThrottle(), etc). A touch screen with on-screen buttons and controls would be an interesting construct and would help to better integrate the Dashboard, which is currently display only, with input options as well. Requiring a physical button for any and all operator inputs when we have a laptop with a full keyboard and so many other I/O opportunities is potentially a bit constraining.
This virtual USB approach from the dashboard seem like it would keep us within the literal interpretation of R75 but I wonder whether it would violate the spirit of the rule. Is the rule in place to prohibit PC communications to the robot or is it simply a rule to simplify filed management and avoid additional communications that could cause unexpected dificulity
No, I’m thinking it wouldn’t violate the spirit. The only reason for the existence of rule 75 I can see is to keep the robots from accepting driver input while in disabled mode (although they could theoretically still make the motors run, iirc, but whatever (On second thought, maybe there’s a wrapper which stops this from happening. Either way, however, it is still legal to modify the cRIO’s software so this protection might be nonexistent, therefore rendering this rule pretty much arbitrary.)).
And, actually, there is virtual joystick software out there. I think there’s a related thread in this forum where I reference it, but it might be required to make your own wrapper depending on what you’re sending.
I only know of being able to make such wrappers in Linux, but the virtual joystick software for windows shows it can be done. I do wish they’d not make it platform-specific.
Update #5 (25-Jan-2011) states that UDP 1130 is being made 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 ?
Once plugged in to the Field Management System via the Ethernet cable provided, the ports that the teams will be able to access on the playing field are as follows:
– TCP 1180: This port is typically used for camera data from the cRIO to the DS when the camera is connected to port 2 on the cRIO. This port is bidirectional on the field.
–** UDP 1130: Dashboard-to-Robot control data, direction**al
– UDP 1140: Robot-to-Dashboard status data, directional
– HTTP 80: Camera connected via switch on the robot, bidirectional
– HTTP 443: Camera connected via switch on the robot, bidirectional .
It seems clear that we are permitted to send data to the robot outside the Driver Station communication packets. <R75> makes it less clear what kind of data is allowed. It apparently can’t be driver or operator inputs.
The FPGA onboard the cRIO that does all of the decision making and direct control of the outputs runs on a layer abstracted from us. FIRST/NI makes this code, and the code we control calls into it to actually control the outputs. When the Field Management System, or the Driver Station is broadcasting a DISABLED case, the FPGA in the cRIO drives all of the output lines to a tristate status, thereby stopping all the motor controllers from doing anything. This is why the Jaguars and Victors exhibit a solid yellow on their diagnostic LEDs when they have a zero signal from an enabled controller (essentially telling the user that they HAVE a signal, but they’re being commanded to STOP), but exhibit a flashing yellow both when in the disabled state AND when a PWM cable is simply not connected. Effectively what is happening is the cRIO is disconnecting all of the wires to the speed controllers by setting the pins to a high-impedance state when it receives a DISABLE command.
Tristating is a concept in electronics where a given user-configurable pin on a microcontroller can be configured to output HIGH (using TTL as an example, this would be the 5V state), to output LOW (continuing the TTL example, this would be the 0V state), or to go to a third, high impedance state, where it acts like a disconnected wire. This little quirk of how microcontrollers work allows creative electronics engineers to take advantage of it to create unique circuits that require fewer logic gates.
The ability to send Dashboard user data to the robot was a hopeful interpretation but the Update #7 Rule 75 change makes this very clear. This is a big change allowing much more user & driver interaction possibilities where we are no longer constrained and limited to physical USB HID components.
New R75 from update#7:
<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) to the ROBOT. The Driver Station software must be revision 01.05.11.00 or newer.
The text “collate driver/operator inputs and communicate them” was removed (striken) from the rule…
John, you’re quoting from the Team Update text instead of from the manual. Leaving in the stricken phrase is really going to confuse people. Please fix it.
We would like to move our image processing from the cRIO to our laptop. This would involve putting the camera on the D-Link and then sending a couple of numbers back to the robot via UDP 1130.
Since this would involve no user inputs, and no changing of the robot mode, it would seem to be legal under R75. Am I wrong?
Also, anyone have any idea how to do this in LabVIEW?
Yes, You can send any data to the robot from the dashboard as long as that data is not used to change the mode of the robot(teleop, auto, enabled, disabled)
R75 was updated in one of the rule update to allow sending of human inputs to the robot from the dashboard.
There is a tutorial on ni.com/frc that describes the steps to put the camera on the switch and how to change the dashboard to view that camera. It doesn’t discuss doing the image processing on the laptop, but since LV code is highly portable, you can drag or copy/paste your code into the dashboard to feed from that camera, and then all you have to do is communicate back to the robot.
Doing the communications is much like doing the dashboard in reverse, but I’d suggest TCP instead of UDP, and it will only take about three icons on the laptop and three on the robot. You may benefit from looking at some TCP examples. Or look at the top row of TCP icons in the Connectivity/Protocols/TCP palette. One machine Opens the connections, the other listens. One machine writes and the other reads. Both close. The things you transfer need to be strings. The way that the dashboard does this is use the flatten to string and unflatten from string nodes.
Ask more questions if you are stuck.
Greg McKaskle