Architecture Ideas

[aidnem]

This discussion post exists so that we can talk about potential ways to organize our code better. E.g. state machine standards.

[aidnem]

@jkleiber thoughts on creating another level of distinction between the subsystem and the IO?
Problem:
Currently high-key's scoring subsystem includes multiple different mechanisms and it has to control all of them. If we don't want to control all of them in the subsystem, we have to control them in the IO, but this is code smell in my opinion because the IO should solely be responsible for converting what we want the mechanism to do into moving the motors (or moving the simulation). It also means that we have to duplicate any mechanism-specific logic across the real IO and the sim IO.
The reason we can't break up the aimer and shooter into separate subsystems entirely is that they need to share a state machine, and passing a state machine back and forth between them with some supplier spaghetti would be pretty gross in my opinion.
In a more general sense, I want us to have our code broken up so that we can have a subsystem with one state machine that controls multiple different isolated mechanisms without having all of that code in one huge file (it's easier to jump to files than to functions in my opinion).

Proposed Solution:
If we added another layer of abstraction (we could call it a mechanism or something similar) that could be commanded by the subsystem and return its state, and would handle the logic (like determining if the aimer was ready to shoot) and control the IOs, and then this data that was returned about its state would be used to allow the ScoringSubsystem to transition states (such as transitioning from prime to shoot once AimerMechanism and ShooterMechanism both reported that they were ready).
This way we could have a best of both worlds between having nice structure with tiny subsystems and cohesive control with an overarching state machine.

[jkleiber]

@aidnem yeah that seems reasonable and it's actually something I wanted to do with 2023's robot last offseason.

We should try to do this with one of the robots and see how it goes. FYI: I think it's likely that we will end up doing most of the work this offseason on Apep due to High Key having the newer swerve modules

The main challenge is in communicating between mechanisms what their constraints are. For example, if two mechanisms within a subsystem can collide we need them to not do that by not allowing the commanded positions to cross each other. That's a problem we'd have regardless though, just something to keep in mind for the future.

[aidnem]

Okay cool, I'll add a ticket for that sometime tomorrow probably. I feel like the idea of a mechanism itself is pretty loose and will basically just define that it needs to have a periodic function, since all of the functionality is robot specific anyway. The periodic will probably just update inputs, call a child periodic to be overridden, and handle outputs.

For handling the constraints I feel like that might be handled in the subsystem itself. Its role could be to orchestrate the mechanisms (it controls them based on its state anyway) and preventing the destruction of the robot could be part of that role. This is just my first impression and I'll keep thinking about it while I write other stuff, I'm fully open to better ideas.

[jkleiber]

Handling the constraints in the subsystem is probably the way to go

It probably would help to make a block diagram of this setup before implementing it just so the design is clear

[aidnem]

Here's a rough idea of what I think should handle what:

[aidnem]

@jkleiber do you have anything you want to tweak about this diagram before I start working on the mechanism?

[avidraccoon]

I think it would be good to make some sort of diagram that shows how we want the architecture to.

[aidnem]

I've created it and attached it above.

[avidraccoon]

@aidnem @jkleiber Do we want to create larger functional interfaces because java allows use to make larger ones?