Logging Data in Java

Technical Java
1

Hello everyone!

I have a few questions about logging. Currently, our team uses a simple System.out.println to tell us if a command is running correctly, however; we would like to take it a step further. When looking at different team’s robot code to learn from, I’ve noticed they would use some try and catch instance for logging. Is this restricted to CAN setups because I’ve only seen it as the code here follows, similar in nature for a variety of teams:

       try{
            System.out.println("FL = " + RobotMap.frontRightMotor.getPosition());
         }catch (CANTimeoutException ex) {
            System.out.println("--- Error Printing Encoder ---");
                ex.printStackTrace();
             }

So here are my questions:

  1. Is logging possible without a CAN setup? (I assume yes, but to be sure I want to ask)
  2. What are the benefits of logging?
  3. Does logging use up too many resources on your processor?
  4. What would you log and why?

Sorry if the question seems too trivial; however, I’m stumped on this currently.

2

I’m a little confused as to what you mean by logging in this case. Are you talking about logging exceptions, logging that things happened, or logging things like sensor values at specific times?

  1. In general, sure it’s possible to log other things. For example, let’s say you want to log where an elevator motor is before/after you adjust its position. You could get the value of whatever sensor is attached to the elevator and print it out. You can also write it to a file if you want, you have all of Java IO at your disposal this year.

  2. Some of the benefits of logging are knowing what happened if things go wrong. For example, the roboRIO will let you know if it enters brown-out mode, and it is currently logging the current draw on each of the individual ports on the PDP to the DS log file. The log viewer doesn’t display this currently, but the hope is to have it display for competition season. This will let you know if a motor suddenly starts drawing way more current than it should be, so there could be an issue with the motor or the mechanical system it’s attached to. You might also log conditions internally. You might have some a complicated command or command group that does a whole bunch of things, logging would tell you where in the command you are, and if you experience issues with the command, you know where things started to go wrong.

  3. Depends on how much you log. Generally, if you’re just logging via println, you’re going to overload the human trying to read the log output far faster than you will overload the processor. Too much data can be a bad thing when you’re trying to understand what happened. Even if you’re writing logs to a file with some advanced logging framework, you’ll probably overwhelm yourself much faster than you overwhelm the roboRIO.

  4. I hope that my other answers clarified this one for you.

3

I was referring to logging when something bad happens (brown-out, motor is not functioning properly). You’re answer was extremely helpful and detailed, so I thank you for that :slight_smile: !

I’m going to see if I can instead create a new text file that logs data in a sense of errors and issues so it can be quickly looked upon after a match, and I will leave all the sensor data in the Smart Dashboard. I will also include println in the initialize of all the commands just to make sure they’re properly configured. Again, thank you for the answers to my questions, they were helpful!

4