Feedback Thread: Driver Station and Dashboard

[Greg McKaskle]

Spurred on by feedback scattered in other threads, I'd like to request detailed feedback on the control system. To help organize things, I've created three feedback threads, one for the HW elements that are used on the robot, one for the Dashboard and Driver Station, and one for WPILib.


Feedback Topic:
-----------------
Driver Station and Dashboard


Tips on giving feedback:
---------------------------
Please be specific as to which elements are being commented on.

Not all teams use elements in the same way, so there is no need to argue that your value judgement for a component is the right one. Explain or justify your judgement so the expectations and context of use is clear.

While comparisons are a fine way to provide feedback, be sure to capture the context that is in your head. What did you expect it to do? Where did it fail and succeed? And then, tell how that compared to the other experience.

Please include tips on best-practices -- a good tool used poorly doesn't lead to a good experience, and the knowledge you can share may make a huge difference to someone else.

Once you've given the context please give your thoughts on improvements.

Greg McKaskle

[apalrd]

As for the Dashboard, my experience was good.

It was very easy to use (with LabVIEW on both ends), and it was painless to create a packet definition ctl file and use it on both ends. I like the way you just feed it text and it spits the text out at the other end - that makes things nice and simple, as opposed to writing the TCP or UDP comm code. I expected it to give me the data I set at the other end, which it did, and I then wrote a tabbed interface (with a color scheme of black, yellow, and purple) around that. After I found how to change the background color of the VI, it made everything so much nicer. Only one problem I noticed: I had a hard time telling if I had lost comm with the robot, something that was valuable to me. If it lost comm, I could tell fairly quickly because the image would go away, but an indicator I created to check the error state of the get data VI would never go away (it seems that the get data VI is blocking and has not timeout, or if it did it was very long.). But everything else was fine, I was able to send a ton of data (all the analog sensors inputs, motor outputs for PID controlled devices, setpoints, shift states for the drive, kicker, and arm, drive ft/sec, highest speed since boot (ft/sec), and more without overloading anything. I also had a feature to save the first image of Autonomous to my flashdrive, and it didn't complain when my flashdrive wasn't plugged in, which was good.

As for the Driver Station, you already know my complaints. On the good side, it gave you feedback on the joystick buttons and Cypress inputs, something the 2009 DS never did (the 2008 and previous did through the Dashboard port), which was very helpful when debugging Cypress IO problems or checking for problems in the control box without booting up the robot. Although I never checked to see if there was a 1-line status like last year (although we just said "Woman Drivers") or a single indicator like the previous OI's, the Dashboard provided that functionality just as well.

[Radical Pi]

Originally Posted by apalrd

If it lost comm, I could tell fairly quickly because the image would go away

do you mean no more new images would be incoming? On our Dashboard the image just froze on the last one before comms were lost (same with targeting data)

Liked:

• Soft Reboot button (small bug - it throws an error if you try to use it while E-Stopped but still reboots)
• Status of DS side I/O - used it many times in debugging
• Live camera images
• Enable/Disable hotkeys
• Dashboard programming - As a C++ programmer that knows a bit of LabVIEW the dashboard packer was fairly easy to figure out, however a bit more documentation on this would have been nice.

Would have been nice:

• NetConsole built in - I wish there was an easy way to run it on the driver account (I had to remove the task manager block and run it from there). Perhaps the text box on the Diagnostics window could be a smaller window version of it that could pop out to the current netconsole window
• Fix for updater troubles - minor enough not to put into "Didn't like", but a small annoyance. Would have liked to see a quick fix once it was reported.
• When in the Driver account, the wireless and ethernet enable/disable hotkeys don't work. It would be nice to be able to switch between wireless and wired on the fly without having to switch accounts

Didn't like:

• Cypress board problems - I feel like this was a bit of negligence in testing. I don't see how with all of the beta teams running it the bug never popped up and got fixed.
• FMS Lock - I didn't even know this existed until we got to competition. Also an FTA at one of our completions claimed we wouldn't be able to connect while FMS lock was on, however we had done fine in matches before with it still on (hotkeys worked even though the lock was on, so I only was clearing it when we needed to run autonomous).
• USB e-stop button - In cases of control lag the e-stop was ALWAYS slower to react than the hotkey disable (spacebar), so our e-stop was never really touched.
• E-Stop bypass delay - is the 20 second wait to bypass the USB e-stop button really necessary?

Other notes:

• I saw a bug at philly during practice rounds where a team on our alliance had to e-stop during the first match. The e-stop crashed their DS and forced a reboot of the classmate (had to run the match without them)
  
• If we are getting new DS computers next year, please send one with a better ethernet port. Us (and many other teams) had a broken tab on the port that prevented the cable from completely latching in to the port. Our solutions was to duct tape an "extension cord" to the classmate.
  
• When connecting the classmate to the team router wirelessly, the enet link light will stay red even though everything is working and all the other lights are normal. Just a small cosmetic fix

EDIT: added a few more things

[Jared Russell]

^ what he said.

[theprgramerdude]

Originally Posted by Jared341

^ what he said.

Same, as well as personally believing, that the WPIlib needs to be less, obfuscated. Reading it at higher levels, its fairly simple to interpret, but once you started going up the heirarchys to look at the base classes, it actually gets more complex and confusing.

[apalrd]

Originally Posted by Radical Pi

do you mean no more new images would be incoming? On our Dashboard the image just froze on the last one before comms were lost...

I modified the dashboard heavily. We use the camera exclusively for Dashboard feedback and run no vision processing on it, so there is no tracking data. I had a check on the error state of the Get Data and Get Image From Controller VI's. If the Get Image From Controller returned an error, I would use an error image instead. I also had a check on the error state of the get data, and that was fed to an indicator. The indicator stayed on all the time. I could unplug the ethernet cable and wait for it to go off, I would see the image go away, but I still see the comm light.

[kamocat]

I would prefer that User Messages was just a string indicator, and not treated like an LCD display.

[Bryan Herbst]

I would like a bit more documentation for the dashboard application (and honestly the default robot code as a whole).

We didn't have very much time to experiment with modifying our dashboard, but the few times we looked at it, we had troubles tracing the code and determining what we could/couldn't modify. We also never figured out how to display our own data from our robot code on the dashboard.

Again, we didn't have too much time to mess with it, but it still seemed pretty undocumented. Of course we also used C++ this year and thus didn't have much hands on time with labview. Accessibility will be key in whether or not we modify the dashboard in the future.

[biojae]

Originally Posted by Tanis

I would like a bit more documentation for the dashboard application (and honestly the default robot code as a whole).

We didn't have very much time to experiment with modifying our dashboard, but the few times we looked at it, we had troubles tracing the code and determining what we could/couldn't modify. We also never figured out how to display our own data from our robot code on the dashboard.

Again, we didn't have too much time to mess with it, but it still seemed pretty undocumented. Of course we also used C++ this year and thus didn't have much hands on time with labview. Accessibility will be key in whether or not we modify the dashboard in the future.

If you are unfamiliar (or don't want to use) labview then there are alternatives.
For example: With C# the ZomB dashboard http://www.chiefdelphi.com/forums/sh...d.php?p=962203

[kamocat]

I realize it's a tall order, but could you reduce packet loss between the Driver station and the cRIO, and eliminate those spontaneous system watchdog timeouts? Perhaps the packet transmission rate could be scaled according to the connection quality?

[andreboos]

As suggested by Radical Pi, I think a NetConsole client should have been built into the Driver Station. However, I think it would be better placed as a second tab on the dashboard rather than on the lower bar, which is itself already quite crowded with four tabs. In the 2010 season we used LabVIEW so printing to the console wasn't practical. I'm now learning the WPI libraries and using printf's constantly for debugging, so NetConsole as a Driver Station built-in seems to me a missing feature.

As has also been suggested above by kamocat, the "User Messages" display was difficult to use. I propose either using it as a smaller version of the NetConsole client, or simply treating it as a string as he suggested.