Ideas for code organization improvements

[VMFortress]

I've heard some mentions before of how some would change the way our code is laid out and I have some ideas of my own as well. However, I don't want to bias any opinions and would like to hear from the team what should maybe be changed.

Something to maybe keep in mind is our plans for quickly getting from nothing to base code with AdvantageKit, SysID, robot preferences, etc all ready to be built on top of.

Something else Coach mentioned was he wished we'd be able to share code easier between different bots like kitbot and competition bot. I explained this wasn't completely possible but there may be someways to improve the shareability between them and between bots each year.

Let me hear your thoughts on what you'd like to see!

[VMFortress]

@InfinityJuice I'd especially love to hear from you now that you've run through so much commenting: Was there anything that felt stupid or silly or could just be done better with the layout from your perspective?

[InfinityJuice]

I honestly felt like everything was relatively well organized because for example in mechanisms, you have the abstract IO class (not supposed to have specific motor types, but sometimes they were there, which hinders transferability), there's the specific hardware IO that implements the abstract IO, and then you have the actual subsystem class. I feel like for transferability, the abstract IO class and parts of the subsystem class can be transferred, but the specific hardware IO has to be changed depending on the hardware available. As long as we name the methods the same, then the subsystem class will work.

Regarding advantagekit, as long as we use the same abstract IO (it has autolog in there), and we make sure to updateInputs in the subsystem periodic() and define what updateInputs does in the hardware specific IO, it should be good.

I didn't really see sysID except for the drivetrain, so I can't really talk too much about it, the only part that needs to be done is making sure that there is some way to run using voltage, which we would have to change depending on the hardware.

I also didn't base the branch off the one that had preferences, unfortunately.

[VMFortress]

Never really thought about the fact we're having the motor type in the higher level abstractions but you're completely right. Maybe that's something we need to evaluate whether that's how we want it to be or if we want actual hardware out of the <mechanism>IO.java. Though, off the top of my head, I'm not entirely sure what that change would look like without duplicating code.

[InfinityJuice]

Currently, the IO.java has configurations, autolog creation, and some abstract methods. I personally feel like the configuration stuff should be put in IO.java because I want IO.java to be copy-pastable. This will make the IO.java a little bit more cluttered, but that's my proposal. I'm not completely sure if it's the best option though.

[Advay17]

@InfinityJuice do you mean that you would prefer config stuff to be in the hardware IO files?

[Advay17]

The main reason why the IO classes have hardware stuff in them was to make it so that I wouldn't have to duplicate the config stuff for both sim and irl code. I didn't make the sim classes extend the hardware classes because the sim classes already extend SimMechanism, which needs to be a class for it to automatically have a constructor that adds sim mechanisms to the list of mechanisms it tracks for simming the battery voltage. However, given that that's just one line of code, I'm probably going to make SimMechanism an interface and just have the sim ios extend the irl classes, which keeps the io files clean

It does irk me that we would then have io interfaces that are only overriden once, which defeats the purpose of an io interface in the first place. Plus, I also hate that every method of an interface is a default method. I think we should rework the IO files to be regular classes. That way, we aren't really breaking any java standards with how they work, as they are being instantiated as they are and as a subclass(the hardware or sim io).

[VMFortress]

In relation to what Coach mentioned about sharing code more, I've been trying to think more on that. I was wondering if it would maybe be advantageous to create our own base template project out of something like the AdvantageKit skeleton template but with all our additional features setup (robot preferences, layout changes, etc). Then, each robot's code can be a fork of that and any code that's edited from the actual base template can be upstreamed for the other robots to be take back downstream.

There could also be multiple layers (e.g. top level skeleten, forks of talon and spark, then each robot based on the respective bases) so that even more can be shared between similar robots.

[VMFortress]

This could also help with keeping robots working on the most modern codebases by updating the top level repos. However, it sounds like 2027 will be a hard cutoff anyways as the libraries may be too different to share. But it'll at least get everything older up-to-date to 2026 by the end and then for future years of 2027 and beyond we'll have it be the same.

[VMFortress]

Something I'm noticing that we could maybe consider: You can't really debug a function in simulation that only exists in a command. It gets loaded in on the creation of the command the one time. So the only parts you can debug are non-command function calls within that.

It may be a good idea to keep as much actual code out of a command and just have it call a function for easier debugging.

[Advay17]

Could you not just wrap it in a DeferredCommand?

[VMFortress]

I wasn't aware of that but looks like it would. Though I guess that does bring the concern of performance overhead of having everything done at runtime. Perhaps there's someway to have it be different in sim vs not without making the codebase too complicated.

[Advay17]

Then could we not just remove the deferred command creation once we are done with debugging(except in cases such as autoalign, where there is another command being called, forcing the command to have to be deferred)?

[VMFortress]

That's true. Not difficult to do so not a bad option. Then it's just a matter of everyone being aware of that.

[VMFortress]

Relating back to my comment about our base projects, what are some things that we'd ideally want available in every project we have as a template project? This is assuming no specific mechanisms or even drive base motors, something completely generic. Off the top of my head, I would think:

• A basic, top-level README
• Our preferred code organization laid out
• AdvantageKit integration
• Robot Preferences or AdvantageKit Tunables integration
• 3D simulation template
  • Including maple-sim
  • Including the 3D state management of the robot
• Unit tests
• SysID
• Test-mode systems check template
• State-machine setup?

Some of these couldn't be fully fleshed out without actual mechanisms but having the basic parts down would be a good start.

Any other ideas?

[Advay17]

• Format Checks? Maybe even some of the ones from Further Style Guidelines #149.
• Base Mechanism Template
• Classes like SysIdSubsystem or SimMechanism(idk if you still use the second)

[VMFortress]

Format checks and other guidelines would be a good idea.

Basic Mechanism would probably be good as well.

I am still using Sim mechanisms (both separate file and 2D mechanism sim, not sure which you meant). I saw some teams just put the Sim stuff in the main mechanism code but it generally looked pretty messy to me.

[Advay17]

I was referring to SimMechanism.java, the one that updates the battery voltage and stuff based on the sim draw

[Advay17]

We also need to get a better branch naming system, perhaps one we could enforce through Github Rules.

[VMFortress]

Agreed. I think maybe the bug/, feat/ or feature/, and event/ might work.

[VMFortress]

Maybe need something for documentation or something separately.

[Advay17]

Same with an outreach branch

[VMFortress]

I think I'd like to find some way better at handling outreach than a separate branch.

There's always a concern with having to deploy to the robot after awhile and we've seen issues with deploying when there's updates and such (though we should start mitigating those with offline mode).

Some sort of toggle would be nice but obviously it would have to be very clear and obvious. I was already thinking what if we made fake RSLs that had a single LED to indicate alliance but maybe we also have that with a different color for outreach.