Our team this year is working on a more-advanced, on-RIO logging system to record robot data during matches. We want to use this to help validate some of our controls algorithms, benchmark drivetrain performance, and help diagnose any issues which show up during a match.
As part of this, we’d like to be able to log things like the roboRIO’s processor load, available RAM, network load, etc. Anything we can get our hands on, really. Anyone have any experience getting this information in Java at runtime?
It doesn’t look like WPILIB supports it directly, and the handful of Java examples I’ve found on line seem to cause runtime errors as soon as the code is loaded on (I presume this is because the functionality isn’t implemented in the real-time system). I would suspect this info is somewhere since it shows up in the driver station, I’m just not sure how to get at it.
Much of what you desire can already be obtained in the Driver Station…
Above the log console in the driver station, click the gear and hit “View Log File”. These log files should have everything you asked for. If not, than you’ll need to post the code you’re working with to record data and the console output.
Understood, pulling driver station logs is always an option.
As to what had been attempted, I had tried to work with java.lang.management.ManagementFactory and java.lang.management.OperatingSystemMXBean per the suggestions on this stack overflow post. The actual permutations of code I tried got lost between commits (bad programmer!). No worries if this isn’t enough, just curious if anyone else has had success yanking these numbers in software on the RIO itself.
This has been on my todo list to figure out for a while. Since the FRCNetworkComms task knows the values because it sends to the driver station, you could file a feature request to have those accessible to the robot program also. However, if FIRST did decide to implement that, it wouldn’t be until next season
Thanks for the info! Pending what we find this season, I may enter that request.
FYI, the background on this is we have had some very hard-to-diagnoses failures in the past where we lose control of the robot briefly. What I’m hoping to do is to track fine-grained data every run about voltages, current draw, drive commands, network status, processor load, etc. - all in the hope that if/when we have a failure, we’ll have enough info to know where to go start debugging (even on a non-reproducible problem).
Additionally, some of the algorithms suggested this year would need to be tuned and evaluated on real hardware. Not sure if we’ll be successful in implementing and using them, but I figured the logging infrastructure would be needed anyway to properly evaluate these algorithms performance.
I had forgotten about this thread till last night, and figured I’d give an update:
We did find a solution for the 2017 year, which seemed to work fairly well. As most linux buffs will know (and as I learned), there are some magical files you can open and read a string out of… properly parsing that string will return lots of information about your processor, memory, and other runtime info. We created a java library to extract total processor load and memory usage inside robot code at runtime:
We found it useful for creating unified logs where we could correlate various pieces of software activating or deactivating with changes in processor load.