Web interface

[Ari423]

Just wondering, what is the advantage of using a web interface over a Java, LabVIEW, or C++ (or other) NetworkTables dashboard? I have heard of a few teams using a web interface but I have never heard a good reason why.

[JesseK]

Originally Posted by Ari423

Just wondering, what is the advantage of using a web interface over a Java, LabVIEW, or C++ (or other) NetworkTables dashboard? I have heard of a few teams using a web interface but I have never heard a good reason why.

Different skillset - different languages and approach to end-to-end programming. Static/traditional programmers are (usually) bad at designing aesthetically-pleasing displays, whereas web people have to focus on style as part of their layouts. Web programmers are also usually looking for something to do towards the end of build season.

On the flip side, web technologies are pretty finicky when it comes to things like touch, external UIs (HUDs like Oculus Rift, e.g.) or other ways of interacting with the robot (Cheezy Vision, e.g.).

If vision is performed on the display laptop, it's often simpler to simply put the vision output on a display that's directly attached to the process which performs the vision processing. Vision, afaik, has absolutely terrible, rotten performance in web languages (except for perhaps Go) so Java/C++ is preferred.

It would be nice if the robot 'came' with a reliable webserver that had all of this data rather than having to use NetworkTables. That way any programmer, whether they're learning web, mobile or embedded, could do something with the robot data. We could also publish calls to the robot. We had on-field connection issues with our stuff in 2015, but we didn't in 2014.

[virtuald]

Originally Posted by Ari423

Just wondering, what is the advantage of using a web interface over a Java, LabVIEW, or C++ (or other) NetworkTables dashboard? I have heard of a few teams using a web interface but I have never heard a good reason why.

One of the biggest advantages is that "anyone" can create a webpage, and it makes it easier to have less technical students involved with the design/etc of the dashboard interface. There's a lot of good real world experience to be had working with HTML/Javascript too (not that there aren't in other languages, but this is a great opportunity for students to branch out).

[x86_4819]

Another benefit web interfaces have is their ability to run remotely on almost any device. The webdash I built last season (mentioned by OP) was designed to be run on a roborio and provide convenient debugging information. If our robot started acting funny while someone else was driving I could just pop on the dashboard from my phone to read the logs, check/modify networktables data, or download a complete logfile from the current run to view later. This dashboard was eventually installed and set to run on startup on each of our controllers, and is my first place to check for any robot problem.

Gameplay dashboards are different. Running it on the robot seems to have more drawbacks than benefits, since you can't run pre-match configuration without it. By the way (this goes to virtuald and any who ran web-based gameplay dashboards) how did you manage your webserver so that non-programmers could easily access it?

[JesseK]

Originally Posted by x86_4819

By the way (this goes to virtuald and any who ran web-based gameplay dashboards) how did you manage your webserver so that non-programmers could easily access it?

The intent is via web calls - start a browser, point to a URL. We plan to have a 'raw data' page which gives an auto-refreshing view of 'all' data in a simple table format.

If non-programmers want more than that, I'm sure we could hook something like Tableau up to the MongoDB backend.

[virtuald]

I made a shortcut on the desktop of our driver station machine that would start chrome with the correct resolution and the correct page.