Can I put Shuffleboard code in and add a second Robot class for physically different bots?

I am kinda tired of using our boolean Robot.isCompRobot in a bunch of if statements, which we set to change the code we use, since our practice robot and competition robot are physically different and not compatible with code.

So my questions here are:
Can I use Shuffleboard in, before the Robot class is instantiated, and
can I have an alternate Robot class, so we can choose robot code before it enables… or something like that?

I am thinking I might just have external classes to to inherit that.

How different are your practice and competition robots? Just things like different speed controller types/IDs, or more complex like subsystems missing?

If it’s just the first, you could turn the RobotMap into an interface with methods returning SpeedController objects, and have different map implementations for the different robots. Then you’d create the map in robotInit based on that flag, and pass the resulting map into the constructors for your subsystems. 166 tried this method this year, though it was slightly limited in functionality by the fact that we didn’t end up having a practice robot.

If entire subsystems are missing, you might be able to do similar by either:

  • Creating mock speed controllers (shameless plug for the one 166 uses) and returning those in the robot map, so you can see the “motor” change on Shuffleboard, but without actually affecting things. This will probably require mock sensors, as well, if your subsystem uses them.
  • Create mock subsystems in their entirety (each “subsystem” is an interface with a real and mock implementation), and assign those in robotInit. This might be simpler, since you don’t need to mock and wrap various sensor classes, but you will end up with larger overall code, since any operations your subsystem uses will need to be interfaced

It’s not really the intended use-case of the library, but if you want mocks of concrete classes you can just use Mockito.

This year, we used swerve just like we did last year. In our case, we used the same talons and same encoders. The encoder offsets were different as were the trackWidth and wheelBase.

I created an interface called SwerveSetup with methods to get the IDs of the talons and methods to get the encoder offsets for each wheel.

When I constructed my SwerveDrive, I just called methods on whatever SwerveSetup I was using.

When implementing SwerveSetup, I used an enum with a single instance. Because my enums don’t hold state, it was a valid use case.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.