Make the RoboRIO serve HTML like the NI WebDash

[teku14]

Hello everyone,

I was wondering if there was a way that one could create and deploy your own web applications to the RoboRIO like how the NI WebDash application is accessible through the browser at the roboRIO-[teamnumber]-frc.local URL.

Thanks!

[SamCarlberg]

You'd have to roll your own HTTP server and connect it to one of the ports that the FMS keeps open. Looks like ports 5800-5810 are the best ones to use according to the FMS whitepaper (https://wpilib.screenstepslive.com/s/4485/m/24193/l/291972-fms-whitepaper).

[teku14]

So this HTTP server would be in addition or separate from the existing one that serves the NI WebDash?

[SamCarlberg]

It would be it's own application running on the RoboRIO. You can't change the NI WebDash.

[virtuald]

You certainly can put an HTTP server on the roborio, but I would recommend putting the HTTP server on your driver station, and communicate with the robot via networktables. Check out pynetworktables2js (https://github.com/robotpy/pynetworktables2js) for a project that lets you easily build your own dashboards using HTML/JS.

[AustinSchuh]

I've been using seasocks to very good success for a number of projects. Fast, lightweight, and has websocket support. https://github.com/mattgodbolt/seasocks

[connor.worley]

mongoose (https://github.com/cesanta/mongoose) is another option.

[apache8080]

254 also built a web server on the RoboRio in java that serves javascript and html pages for a web based dashboard. Here is the link to their code. (https://github.com/Team254/FRC-2015/tree/master/src/com/team254/frc2015/web)

[nickbrickmaster]

Python also has a simple server built in. Can do python CGI as well.

[ArthurA]

You certainly can put an HTTP server on the roborio, but I would recommend putting the HTTP server on your driver station, and communicate with the robot via networktables. Check out pynetworktables2js (https://github.com/robotpy/pynetworktables2js) for a project that lets you easily build your own dashboards using HTML/JS.

Team 4774 used this for our dashboard this year, and we found it really simple, useful, and great for making modifications for the drivers during comp. You can find our code here (https://github.com/thedropbears/stronghold-dashboard).

[teku14]

We're a labview team. I know the poofs have done this but that's written in Java and they are able to import libraries and such. So I assume it requires the JRE installed to run? Also, I believe there some VIs for running a web service that I saw built into the default labview palette. They're also available to run on RT targets such as the Rio. I'm just exploring options here. I did find virtuald's suggestion interesting.

[teku14]

Team 4774 used this for our dashboard this year, and we found it really simple, useful, and great for making modifications for the drivers during comp. You can find our code here (https://github.com/thedropbears/stronghold-dashboard).

I took a look at the code through my phone and it seems really cool. One question however. Did you guys have a camera feed on this dashboard?

[JesseK]

254 also built a web server on the RoboRio in java that serves javascript and html pages for a web based dashboard. Here is the link to their code. (https://github.com/Team254/FRC-2015/tree/master/src/com/team254/frc2015/web)

Unfortunately, they never got this working on an official field (http://www.chiefdelphi.com/forums/showthread.php?p=1571135&highlight=web+server+254#post1571135). We couldn't get the robot to connect to our Node server on the driver's station laptop while on the field either, even with static IP's.

In drilling down into what happens with FIRST HQ's guys, the match pre-start stuff completely re-configures the network at the router when a the field goes from one match to the next. If a team plugs their laptop into the driver's station before field pre-start, they have connected to the network of the prior team. With static IP's and a proper netmask this is solved in theory, but we couldn't get it working. So NetworkTables it was.

I'm going to work on a direct Java implementation for NetworkTables. There is absolutely no need for JNI to be involved, and a direct Java implementation would resolve some of the shared resource issues that it looks like ntcore specifically designs for. The better reason though, is that I want runtime control over the data rate for certain sensors so we can collect better telemetry from a match.

[TheOtherGuy]

Check out Spark, you can get a server up and running on an FRC robot in minutes, not hours or days:

http://sparkjava.com/

[Peter Johnson]

I'm going to work on a direct Java implementation for NetworkTables. There is absolutely no need for JNI to be involved, and a direct Java implementation would resolve some of the shared resource issues that it looks like ntcore specifically designs for. The better reason though, is that I want runtime control over the data rate for certain sensors so we can collect better telemetry from a match.

I would be careful in rolling your own implementation. Generally speaking, network stuff is easy to get wrong and may either not work or use large amounts of wifi airtime in the various network environments used in FIRST (and our friend Murphy says this will happen at the worst possible time). Part of the goal of ntcore was to get as many languages as possible using the same tested and proven network code. I'm not sure what "shared resource issues" you're talking about with ntcore, but bug reports are happily accepted.

The runtime control of update frequency for certain sensors is something I'll be working on adding to ntcore this summer; do you really want different sensors individually updating at different rates, or would a "fast/slow" (e.g. only 2 levels) be sufficient? Would a "pull" (vs the current "push") methodology for updating values be preferred? This is possible to implement on top of ntcore, as there's flush functionality available to synchronize updates to a timed loop. Currently the flush is rate-limited to 10 Hz, but we will also be looking at changing the rate limits based on team feedback from this season, and perhaps provide a UDP option for higher-rate updates (with the tradeoff of accepting the possibility some of these updates will be dropped).

NTcore is an open source project; feel free to file a bug report on GitHub for any of these concerns and we can have a more detailed discussion in that environment.