montclairrobotics / infiniterecharge Goto Github PK

This is at least partially philosophical, but I believe that it will yield easier maintenance/changes in the future. I don't believe, for example, that LauncherRest should be dealing directly with AuxillaryButtons or DriverButtons. There are two major reasons for this.

First: it offers no way for the launcher to be controlled by automation; it is tightly coupled to the a controller. Second, it embeds within the launcher logic the way controller buttons are used. If this pattern is followed consistently, then the drive logic will know what buttons drive, the intake logic will know what buttons intake, etc. This is begging for a "collision", where two different components want to use the same button for different purposes.

There should be an interface for each of these. For example, there should be a LaunchController interface which the launch logic can query for "do you want me to be firing now?" or some such. A class representing the physical controller can implement this interface. That class would control which buttons map to "do you want me to be firing now?", "do you want me to be intaking now?", etc. All the button layout logic would be in that controller, making it easy/safe to change it and making collisions far less likely.

In addition, some automation logic could also implement the LaunchController interface. This would let that automation control the launching process in a way that has nothing to do with actual buttons.

This would also permit construction of one or more test classes which implement the LaunchController interface, which might be useful as you are developing and testing this code.

Just as DriveTrain implements a Component interface, and is used to hide (technical term: "abstract away") implementation details of the drive train from the robot, a Launcher should exist which does the same thing. The Robot class should know nothing about internals of the Launcher, including a given Launcher's states.

Commit e551f4d adds this to one major branch of work (drivetrain work). Can that be cherry-picked into the branch(es) with the launcher work?

Or even better, I see that there are only a few (3 non-merge) commits on the "drivetrain work" branches that aren't already in the "launcher work branches". Can the "drivetrain work" commits be merged into the "launcher work" branches?

I'm looking at LauncherRest.run() at the moment. It creates a LauncherRev object and calls run() on it. That doesn't seem to be correct.

Rather, I believe that, when a ...Periodic() method of Launcher is called (see #3 ), it should invoke run() in the LauncherState object that is the current state. The Launcher logic would look something like:

LauncherState newState = oldState.run();
oldState = newState;

so a particular run() method can trigger a state transition by:

return(new LauncherStateFoobar(...));

and indicate that the state should be unchanged by:

return(this);

In fact...to increase clarity, perhaps we should rename run() to robotPeriodic()? The "signature" of this method is not the same as that of the periodic methods in TimedRobot or Component, but the usage is quite similar.

@Josh-team555 et. al.

I noticed in frc.robot.core.components.LauncherShoot.LauncherShoot() there is a call to motor.wait() (added in 262dd67). Won't this cause all processing on the robot to pause until the wait() call returns?

Or can the robot be programmed using multiple threads? If that is the case, much of the discussion about maintaining state over iterations of ...Periodic() calls can be rendered moot, and a much simpler approach to programming the robot can be taken.

On the other hand, that simpler approach might not work well in all cases. For example, do we really want there to be no way to interrupt the shooter which is in the process of ejecting five balls?

Someone once told me that one could not use multithreaded programming on an FRC robot. However, I did notice https://webcache.googleusercontent.com/search?q=cache:iuiKNbUoqM4J:https://wpilib.screenstepslive.com/s/currentCS/m/java/l/681690-multithreading-in-java+&cd=1&hl=en&ct=clnk&gl=us which suggests that it is possible. Oddly, though, I've not (yet) been able to locate this text in the current documentation (notice this is pulled from Google's cache).