Java programs can be debugged remotely. Once a JVM is started with the proper flags, other programs on the network can hook into it and do interesting things.
Here's the thought - the website data plotter is good for pieces of info known needed all the time. However, we could reduce code overhead if we were to use the debugger to read any value at runtime. We would still have plotting available, but not need to add extra code to make a variable "plottable".
Here's the thought - write a standalone java application to run on a development PC. This application should connect to a remote JVM (the roboRIO), querey for all available objects (class instances). Filter down to only things under IterativeRobot to be just the user-code things we care about. Allow the user to select a subset of the variables. Implement a stop/start functionality which will periodically querey the remote JVM for the user-selected set of values, and display them on the development PC. Add functionality to draw plots of integer or floating point values.
Here's some comparison to the website-based approach
1) Units
-- The website methodology forces the user to define units, min/max, scaling, and the like for each variable. This makes presenting multiple variables on graphs easy. This debugger methodology would require some extra input file to define these, if at all.
2) Arbitrary access
-- The debugger method allows access for any variable at runtime without changing code. The website requires that the user define exactly what is available to view at build time
3) Cross-platform
-- The debugger method would potentially have to be different for Mac/Android/PC. Lots of code could be shared since it's all java.... but it's not guaranteed to work (especially mobile vs. non-mobile... I feel like android might not support this level of access to the JVM very well). - the website method is inherently cross-platform.
The more i'm thinking of this, it seems like a "rainy day, let's see what we can do" project. However, if we could crank it out, it could be a good help to development (and commonly usable for all FRC teams, unlike our website)
An idea has occurrend to me:
Java programs can be debugged remotely. Once a JVM is started with the proper flags, other programs on the network can hook into it and do interesting things.
Java itself has its own debugger protocol exposed via an API: https://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/index.html
Here's the thought - the website data plotter is good for pieces of info known needed all the time. However, we could reduce code overhead if we were to use the debugger to read any value at runtime. We would still have plotting available, but not need to add extra code to make a variable "plottable".
Here's the thought - write a standalone java application to run on a development PC. This application should connect to a remote JVM (the roboRIO), querey for all available objects (class instances). Filter down to only things under IterativeRobot to be just the user-code things we care about. Allow the user to select a subset of the variables. Implement a stop/start functionality which will periodically querey the remote JVM for the user-selected set of values, and display them on the development PC. Add functionality to draw plots of integer or floating point values.
Here's some comparison to the website-based approach 1) Units -- The website methodology forces the user to define units, min/max, scaling, and the like for each variable. This makes presenting multiple variables on graphs easy. This debugger methodology would require some extra input file to define these, if at all. 2) Arbitrary access -- The debugger method allows access for any variable at runtime without changing code. The website requires that the user define exactly what is available to view at build time 3) Cross-platform -- The debugger method would potentially have to be different for Mac/Android/PC. Lots of code could be shared since it's all java.... but it's not guaranteed to work (especially mobile vs. non-mobile... I feel like android might not support this level of access to the JVM very well). - the website method is inherently cross-platform.
The more i'm thinking of this, it seems like a "rainy day, let's see what we can do" project. However, if we could crank it out, it could be a good help to development (and commonly usable for all FRC teams, unlike our website)