I was messing around with Strongback today and decided to also look into the Spark framework: http://sparkjava.com/
It wasn’t terribly difficult to get it integrated and running. I used Maven Ant tasks (https://maven.apache.org/ant-tasks/) to incorporate Maven dependencies into the standard build, then tried some basic things like serving static pages, simple routes, and (most importantly) websockets.
Since it was very simple and added little size or performance overhead to the program, we’re probably going to develop some kind of web based interface to replace smart dashboard.
I’m curious how many other teams have created web interfaces and what they’ve used them for? I noticed the one for robotpy (http://www.chiefdelphi.com/forums/showthread.php?t=134301&highlight=web+server), but otherwise there is very little activity here, especially for Java or C++. That, or I’m terrible at searching! With the explosion in web technologies, this seems like an untapped resource.
I made a simple WebUI last season. I mostly used it to monitor motor current, power status and other things, as well as serving as a remote console. I’ll be rewriting it for the newer season with some more details, and it will be publicly available when I do
It worked well in the lab, but it failed to connect a few times on the field. I was never able to debug why this failed, and we were seemingly using approved ports. Anyway, good luck!
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.
Interesting, did you try multiple ports or stick with 5800? I wonder if this is an FMS problem or an issue with Jetty.
You have complete control over how you customize and deliver information and control of the robot, using technologies that are installed and work on nearly every device. You can also do some clean visualization with very little code (for example, graphing values with Epoch https://fastly.github.io/epoch/real-time/). You could use it to easily fetch & view log files, control the robot from a phone or tablet, visualize 3d data, adjust autonomous routines, etc.
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.
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).
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?
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.
