Quote:
Originally Posted by Arhowk
The reason SSHing to the RIO is done is because the file will be some small config file which will take ~1 second to edit or ~30 seconds to redeploy. Good if your tuning a PID loop or something.
If I had to guess (the robot is currently being worked on... and is written in Python now...)
Right click on your project in Eclipse and go to Properties -> Java Build Path -> Source and add the "yourProjectName/resources" folder
|
Do you know if i can add the SSHing as something that can be done on every deploy, but also when i just need to update the file (for tuning, as you mentioned).
I have tried setting the resources folder as a source (as well as just putting the json in alongside the source files) but it doesn't end up in the jar and my program can't find it.
Quote:
Originally Posted by Joe Ross
What is the advantage of including a JSON file in the jar, as opposed to a java class with constants?
|
So last year, when our team switched to java, we used a single java class with constants. However, that file (along with the file structure) was a mess to parse as the only way to sort the variables was by prefixing their name with their subsystem or whatever (
example)
This year I worked on revamping the file system to enable code reuse by creating self-sufficient subsystem that could theoretically simply be added to a new robot project that has those subsystems, and only some configuration would have to be made.
The problem now is that
each subsystem has its
own map. Now our configuration is all over the place.
To solve this problem I created a program that
parses the maps to create a single
json file skeleton, that
once trimmed and filled in (eventually automatically) will contain all of the configurations in one place, and ultimately would make finding conflicting ports or wrong values significantly easier.
TL;DR the json should, in the end, make configuration significantly easier and allow for code reuse structure in code.