ZomB Dashboard 0.6: Beta testers wanted

[byteit101]

ZomB Dashboard System 0.6b
ZomB Dashboard System version 0.6 will be released soon, but I need beta testers to help me make sure there are no bugs in it. There are two main parts that need to be tested: dashboard components/controls and a new robot side interface. Since I won’t have access to a cRIO until July 6th (in part due to a vacation), I need you to help me test ZomB.

If you find a bug, reply to this thread, email me, or post on the Testing Feedback FirstForge discussion forum. It would also be nice if you took the time to see why it is doing what it is (and maybe make a patch) so I can fix it easily. I'll try to answer them as soon as I can and get it fixed.

Major parts to test
If it works for you
Default dashboard "Idiot Proofing"
DashboardDataHubPanel
Video sources and CameraView
Design time and run time support of StatusLabel and ValueMeter
TCP support (DashboardDataHub source)
RobotStatusEventMonitor (changes in enabled, auton, etc...)
DataSaver & DataPlayerSource (recording of matches)

The new robot side interface is new and untested (though should work in theory ), and is on FirstForge as New Experimental C++/Java Bindings. Instructions for it are in the ZomB Guide.

Downloads
Download it all: http://firstforge.wpi.edu/sf/frs/do/...e.v0_6_b1?dl=1
Pick and choose: http://firstforge.wpi.edu/sf/frs/do/...stable.v0_6_b1

Complete ZomB Guide (Draft): http://firstforge.wpi.edu/sf/docman/...n.root/doc1047

FirstForge Project: http://firstforge.wpi.edu/sf/projects/zombdashboard

If you are interested in becoming a contributor to ZomB (code, website, permanent tester, etc...), PM or email me.

[slavik262]

May I ask why you'd use TCP for a real-time system where the newest packets are far more important than any garbled ones that would need to be resent?

[byteit101]

Originally Posted by slavik262

May I ask why you'd use TCP for a real-time system where the newest packets are far more important than any garbled ones that would need to be resent?

To overcome the 50 hz limit of the dashboard packets (since it was TCP or DB packets this year, no udp) I did put a config option in that sends them in smaller groups rather than larger ones, though that need testing. And the TCP stream can also update each control as it comes in, instead of all at once after the data has come in, been processed, etc, so (minor) improvement in that regard. And I don't think under most field circumstances, a group of data on the tcp wire will be resent so many times it is slower than 20ms. (And, transmission errors on udp are fairly low from what i've seen)

[slavik262]

Originally Posted by byteit101

To overcome the 50 hz limit of the dashboard packets (since it was TCP or DB packets this year, no udp)

Err... Firstly, isn't 50 Hz fast enough? You know the average monitor displays at a max of 60 Hz and that cinema movies are 24 Hz? If 50 Hz is fast enough to sample input to the robot, one would think it would be fast enough to sample output as well, especially since anything faster than 50 Hz isn't very useful to a human reading the display. Also, you know the DB packets are UDP, yes? The bit in the parens confuses me.

Originally Posted by byteit101

And the TCP stream can also update each control as it comes in, instead of all at once after the data has come in, been processed, etc, so (minor) improvement in that regard

Processing a group of controls all passed in as a single packet is faster than each control at once coming through a TCP stream since you spend less time waiting (if only for a very short time) for data to filter through the network stack before you do something with it - a single blocking receive call would obviously be faster than multiple ones. You're still ignoring the importance of using UDP - it allows you to just ignore bad data, not wait for it to be resent. Even if there are few transmission errors, you still have to wait on those in TCP.

There's a reason WPI chose UDP and implemented the dashboard data packets in the manner they did. Besides, even if using TCP did increase performance a small bit, 50 Hz is a more than ample refresh rate for a human.

[byteit101]

Originally Posted by slavik262

Err... Firstly, isn't 50 Hz fast enough?

not if you have lots of data, enough to fill up the ~900 bytes of space, and overflow to a new one or two(although I would only be expecting this in debugging situation)

Originally Posted by slavik262

Also, you know the DB packets are UDP, yes? The bit in the parens confuses me.

this year, you could use their fixed rate, fixed size UDP packets, or use a custom TCP protocol, you couldn't use a custom UDP protocol.

And TCP vs DBPacket is your choice, it favors DBPackets, you have to do some work to use TCP instead of DBPackets (the default)

[apalrd]

1. What are you trying to do with your Dashboard where you filled the 900byte packet?

2.Why isn't 25hz fast enough if you do manage to fill the packet and use two?

I ran a dashboard this year that used the Dashboard packet, and I filled it with:

1 uint8 kick distance
2 doubles gyro data
camera image (separate from DB packet)
1 uint8 chassis mode enum
3 booleans for suckifier system
2 doubles for kicker (recoil position and pot position)
1 uint8 kicker mode enum
3 doubles for arm (setpoint, shoulder pot, chassis string pot)
1 uint8 arm mode
2 booleans for arm (shift state and swap sensor state)
2 doubles for drivetrain speed (ft/sec actual, ft/sec highest since boot)
1 uint robot mode (I think its 16 bit since thats LV default for enums)

And then I wrote a LabVIEW dashboard to arrange all of the data. I ran out of room to show it all,so I created a system of 6 tabs ("Prematch","Autonomous","Teleop","Pit-Debug Kicker","Pit-Debug Arm","Pit-Debug Drivetrain"), 3 of which automatically switched. If in pre-match, auto. or teleop, it would automatically switch tabs based on auto/teleop or disabled state. If in the pit tabs, it would stay. Really helpful, provided a ton of data, and allowed us to look at sensor variables without deploying code - helpful to see if problems are in hardware or software.

I did not fill up one packet.

So 900 bytes is a LOT of data.

[byteit101]

1) The only thing I can think of would be an oscilloscope of some sort
2) It wouldn't from most peoples perspective, but from a programmers perspective, the cRIO is grinding away, updating motors every 5ms, but you have to wait for 4x that amount to update the dashboard.

You could also use it to do lots of data processing, and stream it all across in (near) real time. It doesn't have to be of any particular purpose, ZomB could be used for anything, which is why it has so many features that may not seem useful at first. Like Bluetooth file transfer, webcam support, video saving, video playing, save and play, and TCP.

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

[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