Introducing the CCRE!

[Cel Skeggs]

Originally Posted by brennonbrimhall

I'm curious: in what ways do you feel your library structures code in a manner that is superior to alternatives like the Command-Based system from WPILibJ?

Originally Posted by Ether

Also: Is there a top-level 30,000 ft view executive summary document of the most important features of the framework that set it apart from the other frameworks?

Hi! I'm the primary designer, so I'm probably the best person to answer this.

The best summary document of the CCRE would be the DOCUMENTATION.MD file linked to above.

I don't have a good enough understanding of Command-Based in order to thoroughly compare the two, but I can point out the main helpful features of the CCRE.

First of all, The CCRE is designed to allow for very easy separation of concerns in the main robot code - the problem in our IterativeRobot code from last year, without the CCRE, was that while we did have multiple modules, there was no easy way to pull anything apart within files, meaning that you had to constantly search and reread the file to understand anything.

Code written with the CCRE, as opposed to code written for IterativeRobot or SimpleRobot, is primarily ran a single time, and pulls together various components (motors, axes, etc) and tells handlers to update them each cycle. This means that a small section of code can, for example, handle shifting and nothing else, and not be interconnected with anything else:

private void setupShifting() {
	BooleanStatus shifter = new BooleanStatus(makeSolenoid(2));
	shifter.setFalseWhen(startedTeleop);
	shifter.setTrueWhen(joystick1.getButtonSource(3));
	shifter.setFalseWhen(joystick1.getButtonSource(1));
}

Since you know for a fact that nothing else could mess with this section of code, by looking at this piece of code you can very quickly determine exactly how EVERYTHING relating to shifting is done.

The second main advantage is that channels are interchangeable.
The CCRE has a handful of interfaces: BooleanOutput, FloatOutput, BooleanInputPoll, FloatInputPoll, BooleanInputProducer, and FloatInputProducer, as well as FloatInput and BooleanInput which are really just combinations of a InputPoll and InputProducer.
Any status data sent anywhere in the CCRE uses one of these, and therefore they are all interchangeable.
For example, there is no "Talon" class that the user interacts with. There is no "Solenoid" class either.
When the user gets access to a Talon motor, they use makeTalonMotor(PORT_ID, MOTOR_DIRECTION, RAMPING_RATE) which gives them a FloatOutput.
This is exactly the same as you could get for a Jaguar, for example.
But then, you can plug any FloatOutput into many of the builtin Mixing methods. Mixing.negate could be ran on any FloatOutput to negate all values sent through it - Mixing.deadzone can be used similarly. And Mixing.limit. And ramping.
The point of that means that you can have generic utility methods to remix anything without special-casing.
So you can change a single line to switch from using a Solenoid to run an actuator:

BooleanOutput actuator = makeSolenoid(1);

To using a servo instead:

BooleanOutput actuator = Mixing.select(makeServo(1, 0, 180), 45, 135);

In addition, the CCRE has a wide variety of prewritten modules that provide useful functionality, but would take too much effort to reimplement during every build season:

• A logging subsystem - Send messages to the driver station computer, standard console, and anywhere else.
• A communication subsystem named Cluck - sharing of channels across the network between the robot and driver station (and logging targets and output streams)
• Concurrency helpers - More robust thread handling, non-synchronizing concurrent lists.
• Channel remixing tools - A lot of these.
• Constant tuning - Change constants from the driver station, save them on the robot.
• A imperative autonomous mode subsystem named Instinct - Used to write autonomous code sequentially. (See below)
• Phidget controller interfacing on the driver station - Team 1540 uses these for our copilot station.
• A minimized collections framework - similar to the Java SE collections framework.
• A robot emulator for testing - (See below)

As well, the CCRE has an emulator that can be launched directly from NetBeans (right click on the project - hit Test) that allows you to try out your code before putting it on the robot.
This doesn't do anything as cool as put a virtual robot in a 3D field, but it does let you test how the robot gets controlled:

It can display readouts/inputs for everything that the CCRE can interact with. (There's an extended IO combo box for things like encoders and gyros that pops up other windows.)

As a final useful feature, it allows you to write your autonomous modes as imperative code, instead of using state machines, without pausing the rest of the code:

new InstinctModule() {
	protected void autonomousMain() throws AutonomousModeOverException, InterruptedException {
		leftOut.writeValue(1);
		rightOut.writeValue(1);
		waitForTime(5000);
		leftOut.writeValue(0);
		rightOut.writeValue(0);
	}
}.register(this);

In our code in past years, we had to write finite state machines for autonomous modes, and we haven't had any luck making these easily understandable or maintainable, which is why imperatively sequenced autonomous is an important feature to us.

TL;DR: Separation of concerns! Interchangeable channels! Prewritten modules! An emulator! Imperative autonomous!