Add JSONSync to 2025-robot-code

[linglejack06]

Purpose
The purpose of this addition is to add json based constants for faster testing of constants (no rebuild required)

Project Scope

• Add JSONSync
• migrate drive constants java to json

Note: Check out the high-key-2024 repo and its json branch for help on migrating drive constants, requires a bit of manipulation of constants and creating objects in a java file

[avidraccoon]

Just a little note I believe there is a maybe cleaner way. If it is cleaner or not may depend on what people think.

[avidraccoon]

I remember talking to @aidnem about it.

[aidnem]

Is the custom loaders method implemented yet @avidraccoon ?

[avidraccoon]

Not yet, working on it but ran into a problem. Java annotations are done at compile so we can't use Lambdas, so I am looking into how to do it differently.

[aidnem]

Could we not annotate it with a generic type that's like <Double, Rotation2d> or something, so the annotation knows it will take a lambda that consumes a Double to return a Rotation2d or something similar? Then, the type signature would be known at compile time.

[avidraccoon]

I think we will have to make the methods defined when we create the JSON sync or just make the constant in coppercore.

But we could definitely use reflection for the annotation.

What do you think @aidnem

[linglejack06]

@avidraccoon i might just go ahead and implement json constants like done in high-key until this gets worked out. how long is the custom loader method away from being finished?

[aidnem]

@linglejack06 I've already added it to my elevator constants if you want/need to reference that for anything.

@avidraccoon Sorry I need to read the underlying code to really understand how it works under the hood so I'm not sure I fully understand why we have to make the method when we create the JSON sync.
In my ideal world, the code would look like this:

@JSONConvert<Double, Angle>((angle) -> Rotations.of(angle)) /* JSONConvert could be named something else, I just picked a name for example's sake */
public static final Angle maxWristAngleRotations; /* Name the variable with ...Rotations even though we're using Units library to make it clear in the JSON file that the unit is rotations */

Do you think this would be possible? I'll be reading the JSON sync code to see if I can answer this for myself but I figured you might know already.

[jkleiber]

I don't think we should block development on conversion functions. Please proceed by coming up with a workaround and work the conversion functions in parallel. We need to get JSON constants in now so we aren't waiting around for code to deploy during integration

[avidraccoon]

I believe this feature is one that can be an upgrade easily added to existing code. So any development now should not go to waste. @jkleiber

[avidraccoon]

@linglejack06 I've already added it to my elevator constants if you want/need to reference that for anything.

@avidraccoon Sorry I need to read the underlying code to really understand how it works under the hood so I'm not sure I fully understand why we have to make the method when we create the JSON sync.
In my ideal world, the code would look like this:

@JSONConvert<Double, Angle>((angle) -> Rotations.of(angle)) /* JSONConvert could be named something else, I just picked a name for example's sake */
public static final Angle maxWristAngleRotations; /* Name the variable with ...Rotations even though we're using Units library to make it clear in the JSON file that the unit is rotations */

Do you think this would be possible? I'll be reading the JSON sync code to see if I can answer this for myself but I figured you might know already.

It is not possible because how java annotations work but we could register a conversion method with the json sync object and then use the types to reference that method in the annotation.

[linglejack06]

@jkleiber ill get started on this then by branching off of drivetrain code and following file structure aiden defined in elevator branch