ZomB Dashboard 0.6: Beta testers wanted

[apalrd]

From a programming perspective, you are right that it is comparatively very slow (although Victors update at 10ms, and we use Victors).

I guess speed would matter a lot when using the dashboard for datalogging

I assumed the dashboard would be used on the Classmate during competition. I would always use LabVIEW front panels for IO when debugging, as I just drop the control and set the input on the block diagram of the VI. When deploying (e.g. not doing a full build download reboot cycle) I can see and edit the front panel of the VI in like real time, and even have graphs of data to see. Really helpful when the dashboard data is not enough or when tuning PID loops (I can just type in a new gain, hit enter, and try it again without rebuilding and redownloading)

[byteit101]

Originally Posted by apalrd

I would always use LabVIEW front panels for IO when debugging, as I just drop the control and set the input on the block diagram of the VI. When deploying (e.g. not doing a full build download reboot cycle) I can see and edit the front panel of the VI in like real time, and even have graphs of data to see. Really helpful when the dashboard data is not enough or when tuning PID loops (I can just type in a new gain, hit enter, and try it again without rebuilding and redownloading)

that's because you use labview, ZomB can be used to debug similar to what you said for C++ and Java teams (Updating to the robot is planned though)

[slavik262]

If you're talking about using the dashboard computer to do some processing and send data back to the robot, you can't, or at least not in competition. Like with all things cool and involving networking this year, the GDC said no. The best part was when they didn't even comprehend the question.

[byteit101]

Originally Posted by slavik262

If you're talking about using the dashboard computer to do some processing and send data back to the robot, you can't, or at least not in competition. Like with all things cool and involving networking this year, the GDC said no. The best part was when they didn't even comprehend the question.

I know about this, It will be meant to be only a debugging tool, not used in competition (and i'll probabbly do some "safety switch" that only enables it when the FMS is not connected (brilliant idea self))

[byteit101]

Judging from the 275 downloads, and no bugs reported, it would appear there are no bugs in this beta. Has anyone tested the TCP or the new experimental bindings? If you have, please tell me how well they worked (and java or C++). If they have been tested, I'm aiming for a release around the 14th.

Also, If you would like to help me write a bit of help documentation, please contact me.

[byteit101]

Has anyone tested the new experimental bindings? The sooner I get responses about them, the sooner this is not beta anymore.

[jhersh]

Originally Posted by slavik262

If you're talking about using the dashboard computer to do some processing and send data back to the robot, you can't, or at least not in competition. Like with all things cool and involving networking this year, the GDC said no.

That's not true (from what I understand). You have the ability to establish a TCP stream to be used for your own purposes. TCP is bidirectional. You can send custom data from your dashboard to the robot in competition using TCP. It's not prohibited by the rules either.

You may notice that the example dashboards for CANJaguar use the TCP connection to send PID tuning parameters to the robot. They work with the LabVIEW, Java, and C++ closed loop examples.

-Joe

[slavik262]

I'm quite aware that you have the ability to do this, but given:

Originally Posted by GDC

While it is true that a user can create a socket connection between their dashboard and the robot and send whatever they want, this will only be available during development. The FMS network is configured such that only the specific ports defined by the FRC Communications Protocol are open to transmit/receive data from the Driver Station. This is the done to prevent the robots from overrunning the available bandwidth.

I don't know how to interpret that any other way besides "a dashboard is not allowed to communicate with the robot during a competition match."

[Joe Ross]

Originally Posted by slavik262

I don't know how to interpret that any other way besides "a dashboard is not allowed to communicate with the robot during a competition match."

That answer contradicts their answer a week earlier which said UDP was blocked but TCP was not. http://forums.usfirst.org/showthread.php?t=14284

Maybe the GDC needs another technical member (Remember the question in 2009 where they didn't even know what a port was?). Or, they can just provide more documentation about the robot/field/fms communication.

[jhersh]

Originally Posted by Joe Ross

That answer contradicts their answer a week earlier which said UDP was blocked but TCP was not. http://forums.usfirst.org/showthread.php?t=14284

I don't see this as contradictory. You are allowed to use any UDP ports you like during development, but not during competition. This is also true of TCP... you may use any TCP ports you like during development, but during competition, you may only use the video TCP port.

-Joe

[jhersh]

Originally Posted by slavik262

I don't know how to interpret that any other way besides "a dashboard is not allowed to communicate with the robot during a competition match."

I don't understand how you come to that conclusion. It says you may use ports that are configured for your use. One of those is the TCP port allocated for video on the dashboard. This TCP connection is inherently bidirectional. Therefore you can send data to the robot during a competition.

-Joe