Team 2357 code release

Technical Java
1

The 2017 code release for team 2357 actually contains two implementations. The StreamCode project was used for all competitions and the KCup project which is an experimental re-write that contains some constructs we want to continue to develop and hopefully use in 2018 (the main reason for this release).

Here it is: https://github.com/FRC2357-SystemMeltdown/SteamCode

There are several things in the experimental KCup project that may be of interest to others.

First, is the /KCup/src/edu/wpi/first/wpilibj/command/StateMachineCommand.java abstract class and its related types in the same package. There are also a few sub class implementations in the project that can act as samples. While a CommandGroup enables serial and parallel command execution of child commands, a StateMachineCommand uses child commands to implement a state machine. Another key difference is that a CommandGroup requires the union of all the child required subsystems while a StateMachineCommand requires no subsystems and only the requirements of the active state are consumed at any point in time. There are some restrictions. The most bothersome is that while a CommandGroup can be used as the command for a state in a StateMachineCommand, the reverse is currently not possible, a StateMachineCommand cannot be a child of a CommandGroup (at least not without telling some lies with regard to subsystem requirements).

Second, is the way we use a configuration subsystem to initialize, reset and distribute (to the appropriate subsystem) configuration values read from a properties file.

Third, we are experimenting with having an OI class per subsystem rather than just one (we still do not know if we like this or not). We will probably either go back to one or go all the way with making this another type nested inside each subsystem. One interesting off-shoot of this experiment are the custom joystick button classes we have that fail at initialization if we accidentally put more than one command on a given button (see OneCmdJoystickButton). There is also one that fails if any command is associated with the button (see ReservedJoystickButton). This is to reserve a button for custom trigger use, like our TwoButtonTrigger class that we use to require a button press from both controllers to reset the configuration.

We hope someone finds this useful. Please let us know if you have questions, use any of it or make some modifications that work out for you and may work out for others.

Steve

2

Why are you putting your code in the wpilib namespace? We didn’t write that code, you did. It should be in your or your team’s namespace.

Namespace pollution can be confusing because API consumers expect code in a package (eg “com.google”) to be written and maintained by that organization. You placing code in the wpilib namespace implies that it is written or supported by WPI or the WPILib team, neither of which is the case.

Minor aside, you should also have a .gitignore file that blacklists the build directories (“bin/”, “build/”, “dist/”), otherwise you’ll have compiled class files and jars in your source code that change every time you run a build, as well as ballooning the size of your repository.

3

At one point of the state machine command development there were some package scoped methods we needed to access and so to keep things moving we used that namespace. I am not sure if we are still in that situation or not as the design has changed considerably. We will check. Hopefully we can move them.

You are certainly correct about the .gitignore. It is on my list of things to work with the programming team on.

Steve

4