|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Make the RoboRIO serve HTML like the NI WebDash
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! |
|
#2
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
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.
|
|
#3
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
So this HTTP server would be in addition or separate from the existing one that serves the NI WebDash?
|
|
#4
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
It would be it's own application running on the RoboRIO. You can't change the NI WebDash.
|
|
#5
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
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 for a project that lets you easily build your own dashboards using HTML/JS.
|
|
#6
|
|||
|
|||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
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
|
|
#8
|
|||
|
|||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
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.
|
|
#9
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
Python also has a simple server built in. Can do python CGI as well.
|
|
#10
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
Quote:
|
|
#11
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
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.
Last edited by teku14 : 03-05-2016 at 10:45. |
|
#12
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
Quote:
Last edited by teku14 : 03-05-2016 at 10:45. |
|
#13
|
||||
|
||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
Quote:
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. Last edited by JesseK : 03-05-2016 at 11:09. |
|
#14
|
|||||
|
|||||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
Check out Spark, you can get a server up and running on an FRC robot in minutes, not hours or days:
http://sparkjava.com/ |
|
#15
|
|||
|
|||
|
Re: Make the RoboRIO serve HTML like the NI WebDash
Quote:
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. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|