Idea: Auton library

[person4268]

I just got an idea for a library that could make the creation of our auton more simple, possibly?

The concept

It's going to center around a JSON file that describes the flow of the entire auton, with the goal of looking similar to this:

{
    actions: [
        {
            // Probably make this optional, just a human readable description 
            "name": "Move back 0.5m to pick up first cargo",
            // This refers to a java class, either registered manually or via reflection, Java-side structure of how this works TBD, might look similar to a command, may or may not actually implement CommandBase, idk
            "class": "MoveRelative",
            "movement": [-1, 0, 0] 
            // Optional, schedules next command while this one is still running
            "async": true 
        },
        {
            "name": "Start picking up cargo",
            "class": "StartCargo"
        },
        {
            "name": "Wait 100ms",
            "class": "Delay",
            "duration": 100
        },
        {
            // Uses PathWeaver
            "name": "Follow get-cargo,
            "class": "FollowPath"
            "path": "get-cargo"
   ],
    // Honestly could be ommitted
    paths: {
       "get-cargo": "auton-get-cargo.json"  // This is a pathweaver file and simply just creates a reference to it for later
    }
}

it might be interesting, or it might be clunky, idk, but it seems kind of like a kludge to implement an auton entirely in java when we can separate out the high level functions with the details like instantiating timers and classes and passing methods in and stuff. We could also use YAML? Or this might be pointless, I don't fully understand exactly how PathWeaver works / is implemented.

[person4268]

Should we use JSON for our paths? If we can convert to, say, into Protobuf since it's well defined, we may be able to incur a speedup, which could possibly help if we want to do something fancy like record our path and have the robot follow the recorded path, plus it already can take more than 20ms to load the JSON (not that it particularly matters?)

[alrazzi]

That sounds like a cool idea. We can make it so that it's generic and reusable for future years.

[person4268]

I really want to to this, but lack the motivation to currently. Either way, I think it'd be fairly simple to implement.

• We can get classes by reflection and prepending a hardcoded package name
• Java has a built in JSON parser since 1.8
• We can pass the configuration object for that specific command to the constructor of the command
• We could extend CommandBase and just manually call the constructor and execute(), initialize(), and end() manually, or we could implement our own class, I don't think it really matters.
• We should pass a class instance to the commands that just contains an instance of all subsystems

[alrazzi]

Here is a good explanation by @person4268 regarding one way of going about the problem:

Most of the logic should be self contained in a command that will be scheduled by the regular command scheduler. It should take in a file path pointing to the json config file to execute. It should preload the specified pathweaver paths as that can take relatively long. One by one, it should execute the commands until each command is finished (unless async is true in the json, look at the example json). Each command should be passed a reference to all of the subsystems (possibly through a class meant for that purpose? since there are multiple), and a reference to the configuration for that specific command. chances are, it'll be simpler to not use the scheduler for this, and just manually call initialize(), execute(), isFinished(), and end() yourself, I believe, as I feel the scheduler is more set and forget (though i guess you could parse the whole thing and compose -every- command together at once into one programatically and schedule it [on second thought this is a better idea imo]) You will want to use java's reflection capabilities to get the class by name and instantiate it. Note that it's a bit different to do than what most examples online say since the constructor takes arguments. See the 2nd example at https://java2blog.com/invoke-constructor-using-reflection-java/, you'll likely want to cast to CommandBase once you're done, also make sure to have at least a tiny bit of error handling in case the class name doesn't exist.

[person4268]

basic functionality completed by me in 91edc95, so i'll close for now i guess

switched from using JSON to just regular code with some functions to make it clean to chain composing commands, was a far simpler architecture.