Add Generics Support to AutoLog

[Gregadeaux]

Is your feature request related to a problem? Please describe.
You cannot currently use generics inside of classes with the @autolog annotation

Describe the solution you'd like
Would like to be able to do something like this

@AutoLog
 public class MotorIOInputs<PosUnit extends Unit, VelUnit extends Unit> {
     public Measure<PosUnit> position;
     public Measure<VelUnit> velocity;
}

Describe alternatives you've considered
Could of course ditch that entirely and just do double's, but I do like the Units API generally.

[blaze-developer]

Feel free to correct me if Im wrong, but couldn't you just log them as unitless Angle and AngularVelocity objects? The point of the units library is to store values in a unitless and liquid form, I don't understand how the generic would ever need to change in this scenario.

[godmar]

AdvantageKit claims support for wpilib units, but (edit: mutable) units such as Angle or MutAngle appear to not be supported from what I can tell. Attempts at using them will fail with a ClassCastException since a GenericMutableMeasureImpl object is returned instead of the actual type.

So I would phrase the problem not as "generics" aren't supported, but as wpilib (edit: mutable) "units" in general aren't supported. I was unable to locate units tests or example code/templates.

Edit:
we are discussing replay here, not logging. The code above is called from the Logtable.get function.

[blaze-developer]

Ive been logging Angle objects all season, are you sure you are logging the correct data type? Something strange must be going on.

[katzuv]

Attempts at using them will fail with a ClassCastException since a GenericMutableMeasureImpl object is returned instead of the actual type.

Do you get an error also with the immutable type?

[aidnem]

AdvantageKit claims support for wpilib units, but units such as Angle or MutAngle appear to not be supported from what I can tell. Attempts at using them will fail with a ClassCastException since a GenericMutableMeasureImpl object is returned instead of the actual type.

To clarify, this happens when attempting to read a MutAngle in replay sim. The error occurs in the fromLog method of the generated autologged inputs object. The class causing issues can be seen here.

The error is thrown in the generated fromLog method here:

// ElevatorInputsAutoLogged.java
  @Override
  public void fromLog(LogTable table) {
    largeEncoderConnected = table.get("LargeEncoderConnected", largeEncoderConnected);
    smallEncoderConnected = table.get("SmallEncoderConnected", smallEncoderConnected);
    largeEncoderPos = table.get("LargeEncoderPos", largeEncoderPos);
    // ^ Error is from this assignment
    largeEncoderVel = table.get("LargeEncoderVel", largeEncoderVel);

Here's the get method that it's calling, which is returning the GenericMutableMeasureImpl:

// LogTable.class
  /** Reads a MutableMeasure value from the table. */
  @SuppressWarnings("unchecked")
  public <U extends Unit, Base extends Measure<U>, M extends MutableMeasure<U, Base, M>> M get(
      String key, M defaultValue) {
    if (data.containsKey(prefix + key)) {
      double baseValue = get(key).getDouble(defaultValue.baseUnitMagnitude());
      double relativeValue = defaultValue.unit().fromBaseUnits(baseValue);
      return (M) new GenericMutableMeasureImpl<>(relativeValue, baseValue, defaultValue.unit());
    } else {
      return defaultValue;
    }
  }

I can set up a test project to see if non-mutable measures work if that would be helpful.

[godmar]

Attempts at using them will fail with a ClassCastException since a GenericMutableMeasureImpl object is returned instead of the actual type.

Do you get an error also with the immutable type?

No, immutable types work because they are returning an object of the same type as the provided default value.

I've prepared a PR with a possible fix. Please comment. (Also, I'm not sure if we've hijacked this issue since the original requester might have been asking for something slightly different. Apologies.)

[godmar]

PS: with #224 we were able to replay the log with MutAngle, etc. as described above