The CCRE: A comprehensive award-winning robot code framework

[Cel Skeggs]

Developed by FRC Team 1540, the Flaming Chickens, the Common Chicken Runtime Engine (the CCRE) provides a powerful yet easy-to-use software framework for use by FRC teams during competition season and beyond. It has a number of major features:


Separation of concerns: separation of concerns is where all code for specific functionality is in exactly one place, and is regarded as good for maintainability. The CCRE helps foster this using its higher-level abstraction and composition techniques.
Emulation: the CCRE has a fully functional emulator built right in! This means that robot code can be tested before deployment - very useful during build season when the robot that the code’s written for doesn’t exist for a few weeks.
Networked operator interface: the CCRE features a match-ready frontend known as the Poultry Inspector. It’s designed to replace (when used on a touch screen) or augment the physical control panels used by many teams with customizable information displays and controls.
Code portability: code written with the CCRE can run on both cRIOs and roboRIOs, from the exact same project. This minimizes the time needed for teams to get up to speed on roboRIO software. (The CCRE runs in Eclipse, which is the standard development environment next year.)
Support: the CCRE is completely open-source, and the primary developer can be directly contacted. (See the GitHub page for the email address.)
Prebuilt modules: the CCRE includes more complex self-contained modules of code that are useful for most robots, such as the Logging Framework, the Networking Framework, the Autonomous Framework, etc. This means that you get lots of helpful functionality with minimal work on your part.


The source code and documentation for the Common Chicken Runtime Engine can be found on GitHub. (https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/wiki)

As part of the documentation, we have fifteen tutorials on different parts of the system, from installation and simple robot code, to advanced guides on Logging and Cluck-based Networking.

See an example of CCRE code here! (http://pastebin.com/Wniye024)

The CCRE has now existed for about a year and a half, and we have used it for all of our robots in that time, which includes preseason, prototype, competition, and non-competition robots. After using it for the season, we presented on it at our competitions and it won the Archimedes Innovation in Control Award at the 2014 World Championships.

Note: This is the second CCRE thread on these forums. After a year more of development, we’ve decided to create a new thread with up-to-date information on the CCRE, as we were unable to modify the original post on the previous thread.

[Joe Ross]

Code portability: code written with the CCRE can run on both cRIOs and roboRIOs, from the exact same project. This minimizes the time needed for teams to get up to speed on roboRIO software. (The CCRE runs in Eclipse, which is the standard development environment next year.)

How do you deal with the non-backwards compatible changes in WPILib?

[Cel Skeggs]

How do you deal with the non-backwards compatible changes in WPILib?

Simple: we don't expose WPILib. FRC robot projects written using the CCRE access hardware through the Igneous class (http://cgscomwww.catlin.edu/~skeggsc/ccre-javadoc/ccre/igneous/Igneous.html). This lets us smooth over any changes in WPILib.

Since the user project isn't the first thing that runs, the CCRE_Igneous_cRIO or CCRE_Igneous_RoboRIO module can register their own versions of the interface, so on the cRIO the interface is designed to work with 2014 WPILibJ, and on the roboRIO, the interface is designed to work with 2015 WPILibJ. When the user uses the "Deploy" target, it uses the roboRIO build system to download it (assuming that they have the required plugins), and when the user uses the "Deploy2014" target, it uses a heavily-modified version of the cRIO build system to download it, no plugins required.

In terms of the non-backwards-compatible hardware changes, we provide Igneous.isRoboRIO(), which lets the user program figure out which one is being used. Since a robot with the roboRIO and a robot with the cRIO would have different port numbers either way, we require that the user program chooses the correct port numbers itself. New modules such as the PCM are handled via methods such as Igneous.usePCMCompressor(), which will throw a helpful exception if used in a cRIO environment.

We've used this to make last year's code downloadable to both targets, and when our code ran on a cRIO at Girls' Generation and Rookie Rumble (offseason events), it used the exact same code that I've been downloading to a roboRIO for testing.

[NotInControl]

Simple: we don't expose WPILib. FRC robot projects written using the CCRE access hardware through the Igneous class (http://cgscomwww.catlin.edu/~skeggsc/ccre-javadoc/ccre/igneous/Igneous.html). This lets us smooth over any changes in WPILib.

Since the user project isn't the first thing that runs, the CCRE_Igneous_cRIO or CCRE_Igneous_RoboRIO module can register their own versions of the interface, so on the cRIO the interface is designed to work with 2014 WPILibJ, and on the roboRIO, the interface is designed to work with 2015 WPILibJ. When the user uses the "Deploy" target, it uses the roboRIO build system to download it (assuming that they have the required plugins), and when the user uses the "Deploy2014" target, it uses a heavily-modified version of the cRIO build system to download it, no plugins required.

In terms of the non-backwards-compatible hardware changes, we provide Igneous.isRoboRIO(), which lets the user program figure out which one is being used. Since a robot with the roboRIO and a robot with the cRIO would have different port numbers either way, we require that the user program chooses the correct port numbers itself. New modules such as the PCM are handled via methods such as Igneous.usePCMCompressor(), which will throw a helpful exception if used in a cRIO environment.

We've used this to make last year's code downloadable to both targets, and when our code ran on a cRIO at Girls' Generation and Rookie Rumble (offseason events), it used the exact same code that I've been downloading to a roboRIO for testing.

If I understand this correctly, backwards compatibility only applies to programs purely calling WPILib, because you wrapped it and any code dependent on the Java standard libraries will not have backward compatibility. Is that correct?

What happens when the users program tries to execute code written under Java 8, but then tries to exectute on the cRIO? For example, if the user makes a call to Java.io.socket networking classes, or uses automatic unboxing Double myVar = 5.

All are valid on the roboRio, but what happens when the user tries to run this code on a 2014 cRIO, does it have a compile error, run-time error, or work somehow?

Thanks for putting this together,
Kevin

[Cel Skeggs]

If I understand this correctly, backwards compatibility only applies to programs purely calling WPILib, because you wrapped it and any code dependent on the Java standard libraries will not have backward compatibility. Is that correct?

That's correct. We provide a few things from the standard libraries that aren't on the cRIO, but not anything significant.

What happens when the users program tries to execute code written under Java 8, but then tries to exectute on the cRIO? For example, if the user makes a call to Java.io.socket networking classes, or uses automatic unboxing Double myVar = 5.
All are valid on the roboRio, but what happens when the user tries to run this code on a 2014 cRIO, does it have a compile error, run-time error, or work somehow?

When targetting the cRIO, the code is compiled with Java 1.5, not Java 8 or Java 1.3. It then gets run through Retrotranslator, which converts it to Java 1.3 bytecode.
Using unboxing should work properly, as far as I can remember. This is a language feature, not a bytecode or library feature. (You can use all Java 1.5 language features safely on the cRIO when using the CCRE, as far as I know.)
Using java.net.Socket will cause a compile-time error when targeting the cRIO (but not when targeting the roboRIO). This isn't an issue, though, because you can just use ccre.net.Network.connect(addr, port), which wraps both Squawk and Java SE interfaces for you into one interface.

In general, things will either just work or have a compile-time error. There are few cases when something will fail at runtime.

Thanks for putting this together,
Kevin
Of course! Since it's licensed under the LGPL, any team that wants to use it (or any subset, really, but if you're going to use part of it, you may as well use the rest) is free to do so.

[Cel Skeggs]

Weekly update on 2014-10-27

CCRE release 2.1.1 is available.

Important changes since v2.0.0:
Added PIDControl.
Added Single Joystick drive.
Improved ExpirationTimer.

The devel-2.x.x branch has been created and has a variety of bugfixes on it, which will be in ccre-v2.2.0. (These fixes include removal of some legacy components, so it can't count as only a bugfix release.)

[Cel Skeggs]

Semi-weekly update on 2014-11-05

CCRE release 2.2.0 is available!

Changelog:
* Removed legacy version of the Poultry Inspector. This should not affect you.
* Moved ApolloGemini2014 to be another sample in SampleIgneousRobot, as would make more sense.
* TuningContexts will remember their names so that publishing a save event doesn't need to have the name specified again.
* TuningContexts will default to the global CluckNode if no node is specified.
* Added `Igneous.NO_RAMPING` constant, equal to 0.0f, which may be used as the ramping argument to `make*Motor`.
* Multiple interface savefiles are now supported by the PoultryInspector.

Bugfixes:
* Emulator failed to close if main code couldn't be loaded.
* Inverse trigonometric functions were unavailable on cRIO.
* (Partial) The build process paused a long time while old files are deleted.
* Emulator launch built more than was required, slowing down emulator launching.
* Poultry Inspector required Java 7, instead of Java 6.


As a reminder, we currently have a very active Trello board (https://trello.com/b/tAJrY3Ql/ccre-development-board) on which we keep track of current development status. For example, we have nineteen different cards under the "Done (October 2014)" column.

[Cel Skeggs]

Semi-weekly update on 2014-11-21

CCRE release 2.3.0 is available! Lots of goodies here - a total of 48 commits to our Git repository since the last release!

Major Changelog:

* Added booleans to TuningContext, so that the tuning framework works with them as well as floats.
* Added file and line number readouts to logging messages.
* Automatically set motors to zero on disable, to prevent ramping jumps.
* Added arithmetic on channels to FloatMixing.
* Added listing of robot addresses in PoultryInspector, instead of a preset address.
* Added lots of alternative views for PoultryInspector controls.
* Added method by which .input and .output for the same channel get shown as the same channel in the PoultryInspector.

Minor Changelog:

* Removed launches from TemplateIgneousRobot, so that only real projects get them.
* Sped up cRIO library building.
* Miscellaneous visual improvements to the Poultry Inspector.
* Cleaned up the implementation of the Mixing* classes: https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/issues/7
* Added `IJoystick.getXSource()`, `IJoystick.getYSource()`.
* Made the averageBits parameter optional in Igneous.makeAnalogInput.
* Added OutputStream support to PoultryInspector.
* Cluck can now publish EventStatuses without manually breaking out the channels.
* Let DriverImpls Single Joystick Drive (Arcade Drive) take Joystick handles directly.
* Added unofficial copy of the Squawk source code to the repo so that source shows up.
* Added copy of the WPILibJ source code to the repo so that source shows up.
* Added roboRIO debugging support.
* Streamlined instantiation of TuningContext objects.
* Marked `makeAnalogInput_ValueBased` as deprecated.
* Added dynamic time waiting method to InstinctModule.
* Added direct access function for `Utils.currentTimeSeconds`'s value.

Bugfixes:

* Fixed incorrect Java versioning on some CCRE projects.
* Fixed off-by-one error with axes in roboRIO glue.
* Fixed the out-of-limit bug with PoultryInspector float readouts.
* Added backport rules for some mathematical functions that were unavailable on the cRIO.
* Fixed the bug where dragging out BooleanOutputs in the PoultryInspector would set them to false immediately.
* Fixed default positioning of the Logging Component in the PoultryInspector.

We also now have standalone downloads of the PoultryInspector binaries available with each new release. See the current release on GitHub (https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/releases) for the binary download. (Scroll down a bit.)

As always, if you have any issues, suggestions, questions, comments, etcetera, about the CCRE, please post them here!

[Cel Skeggs]

Hotfix update on 2014-11-23

CCRE release 2.3.1 is available! This fixes a few problems, most importantly a major serialization bug introduced and present only in CCRE release 2.3.0. You should not be affected by this bug unless you're using the saved-layouts feature of the PoultryInspector.

Bugfixes:

* Fixed issue with saving PoultryInspector views that contain control components.
* Added keepalives for Cluck.
* Fixed ISOMETRIC_BUTTON stretching issue on PoultryInspector.

We try our best to keep the CCRE bug-free, and it almost always is. Of course, please report any issues or difficulties you have with the CCRE or any components, to help us keep it as high-quality as possible.

We recommend keeping your copy of the CCRE as up-to-date as possible. See the short update guide on GitHub. (https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/wiki/Update%20Guide)

[Cel Skeggs]

We're getting ready for release 2.4.0, but it's probably not going to be ready before Kickoff. However, we need to release all code before Kickoff by R13, so here are the details on where you can get it:

Everything is on the GitHub repository. The latest changes are in the devel-2.x.x branch, which is also publicly available. There is also a pull request in process (#10), which is also publicly available.

If you want the sum total of everything we have "unreleased" (it's public but we haven't signed off on it as a stable CCRE release), those two places will have it. We also plan to get them together into ccre release 2.4.0 soon, so you can also wait for that.

If anyone thinks that this doesn't satisfy R13, please let me know and I'll try to fix things.

[Cel Skeggs]

Release 2.4.0 should be up either today or tomorrow. The main thing remaining is to test the latest version to make sure that nothing's been accidentally broken since the last release.

Once this release is out, you will definitely want to upgrade - it has a number of fixes and improvements that are essential to programming the roboRIO with the CCRE, such as the rewritten Emulator that also supports the roboRIO.

We're also going to be pretty much requiring Java 8 now, so make sure to grab it from Oracle's site (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html).

Also, we can see that a number of people have downloaded the CCRE recently! If you have, consider posting your opinions/findings here. (Especially if you plan to use it.)

[Cel Skeggs]

CCRE update on 2015-01-06

CCRE release 2.4.0 is out! This is the major 2015 season release - it contains working versions of most of what you'll need to use the CCRE in the 2015 season.

Major Changelog:

* A new Emulator model: DeviceList. This doesn't use screen space as well, but is easier to understand and only shows what your code uses.
* The Emulator now supports the roboRIO.
* Java 8 is now required for development.
* A new MultiModule system for easily selecting and configuring autonomous modes.
* Added an example of good usage of the CCRE by rewriting last year's robot code.
* ExtendedMotors were added, which allow for CAN motor support.
* Barebones CAN motor support.

Minor Changelog:

* The PoultryInspector now allows the END key to be used in place of ENTER to avoid disabling the robot.
* Added a version of `CluckTCPServer.setupServer` that takes a port number.
* Added FMS-compatible ports to roboRIO and PoultryInspector defaults.
* Added USB preset to PoultryInspector.
* Added `BooleanMixing.whenBooleanChanges` and `FloatMixing.whenFloatChanges`.
* `createDispatch` no longer ignores the initial value.
* The Emulator now reports errors in the GUI.
* Improved helpfulness of the message when the roboRIO plugin is not found.
* A wide variety of internal code enhancements.
* Moved the virtual phidget display to be a PoultryInspector component instead of a window.
* Added buildscript for the PoultryInspector's package.
* Added screenshots to PoultryInspector documentation.

Bugfixes:

* One implementation of `FloatMixing.onUpdate` was private.
* ConnectionReceiverThread always said port 80 when connection failed regardless of port.
* createDispatch now includes the original value in the result.
* Mixing.select now updates even when the selector stays the same.
* Fixed occasional link unavailable errors without useful information.
* Miscellaneous behavior fixes in Mixing methods.
* Miscellaneous concurrency fixes.
* Several other miscellaneous fixes.
* Fixed some minor licensing issues where the wrong documentation was provided.

We plan to build an Eclipse plugin for the CCRE at some point soon, which should make the CCRE much easier to install.

As usual, please send us any comments, questions, complaints, suggestions, etc!

[BrianAtlanta]

Your framework looks really nice. I was reading your documentation on the logging portion of the framework. You mentioned that some logging frameworks wouldn't run on the limited FRC setup. I was wondering if the change to the Roborio increased performance so that some of the logging frameworks would now work? I was looking at having our team look at something like Log4J, but I'm concerned it won't work.

Brian Carlson
Programming Mentor

[Cel Skeggs]

Your framework looks really nice. I was reading your documentation on the logging portion of the framework. You mentioned that some logging frameworks wouldn't run on the limited FRC setup. I was wondering if the change to the Roborio increased performance so that some of the logging frameworks would now work? I was looking at having our team look at something like Log4J, but I'm concerned it won't work.

Brian Carlson
Programming Mentor

The issue isn't with performance so much as the version of Java. The cRIO with just Squawk runs Java 1.3, which is a very old version. Log4j, for example, requires Java 6. With the introduction of the roboRIO, you can now use a number of these frameworks without too much work. The CCRE's Logging framework still has some advantages - it can work on any platform, including the cRIO, and by default works well with the rest of the system - no setup required.

You can certainly use Log4j, but you'd have to do your own work to integrate it.

[fsilberberg]

Your framework looks really nice. I was reading your documentation on the logging portion of the framework. You mentioned that some logging frameworks wouldn't run on the limited FRC setup. I was wondering if the change to the Roborio increased performance so that some of the logging frameworks would now work? I was looking at having our team look at something like Log4J, but I'm concerned it won't work.

Brian Carlson
Programming Mentor

One thing to note with Log4J and some other libraries is that with the embedded profile we use to create the JRE, some of the necessary bean components don't get enabled to save space. You could create your own JRE and put it in /usr/local/frc/JRE with the necessary components enabled, but we don't support it with the installer.

[Cel Skeggs]

CCRE release 2.5.0 is out! The main feature here is RS232 support.

Release of CCRE with API v2.5.0.

Major Changelog:

* Support for RS232 ports on cRIO and roboRIO.
* Infrastructure to support Serial IO in general.
* ExpirationTimers now allow for tunable delays.
* A driver for the UM7LT heading sensor is now included.

Minor Changelog:

* CArrayUtils now has sorting methods.
* Igneous now acquires method information during caller analysis, meaning that logging messages on the cRIO now include the line number as well as the file name.
* Added direct isDoingWork() method to CollapsingWorkerThreads.
* Removed old non-RawIO roboRIO IgneousLauncherImpl.
* Added cRIO backporting support for java.util.Arrays.
* Miscellaneous cRIO backporting support.
* Moved most TODOs from the code into Trello and GitHub.
* Refactored CluckPublisher subscribers to have less code duplication by factoring out `CluckRMTSubscriber`.
* Most of Cluck now has an automated testing system set up, invokable via the PoultryInspector
* A unit test for CArrayUtils sort methods has been added.
* CLinkedList now has a `setAll` method used for bulk-reloading data.
* Miscellaneous PoultryInspector graphical code cleanup.
* Added missing documentation for Beeper.

Bugfixes:

* roboRIO RawIOIgneousLauncher no longer stores state statically.
* If cRIO library builds fail, they will no longer silently allow robot projects to still be compiled with the old version.
* Fixed a race condition in the Emulator's redrawing code.

If any other teams are actively using the CCRE, please let us know!

[Cel Skeggs]

CCRE release 2.6.0 is out! A number of features have been added - CAN Talons, RConf, StateMachines, additional PoultryInspector configuration, log fetching, etc.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Release of CCRE with API v2.6.0.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Major Changelog:

* Support for CAN Talons on the roboRIO. cRIO will not support them in the near future.
* RConf (Remote Configuration) subsystem introduced.
* StateMachine is now provided for middle-complexity subsystems.
* PoultryInspector now allows for range configuration.
* PoultryInspector components now configured via RConf views.
* Support for multiple PCMs/Solenoid Modules.
* Support for Joystick POV hats.
* Support for log fetching from roboRIO targets. (Autoruns on code download.)
* Code coverage for tests can now be generated. Tests expanded to cover approximately 30% of codebase.
* Prototype (not used by default) version of roboRIO target that bypasses the majority of WPILib, for a theoretically more stable experience. Practically, don't use this yet for anything real.

Minor Changelog:

* Deprecated makeAccelerometerAxis, as it is so trivial that it shouldn't have a builtin method.
* Removed ComputationBenchmark. It was completely unused and not particularly helpful in any way.
* InstinctModule.waitUntilNot.
* BooleanStatus.asInput, asOutput, asInvertedInput, asInvertedOutput.
* EventStatus.countConsumers.
* BooleanMixing.xorBooleans now supports BooleanInputs, not just BooleanInputPolls.
* FloatMixing.floatIsOutsideRange, floatIsInRange, normalizeFloat now support Inputs, not just InputPolls.
* Mixing.quadSelect now supports Inputs, not just InputPolls, at least for the selection parameters and return value.
* BooleanMixing.setWhile, setWhileNot.
* FloatMixing.setWhile, setWhileNot.
* BooleanMixing.toggleEvent.
* ExpirationTimer.terminate, PauseTimer.terminate.
* Igneous reports the name of the main class at startup.
* Fixed up Deprecation notes.
* Usage reporting now includes CCRE note.
* WPILib version number now includes CCRE version too.
* Extracted AbstractJoystickWithPOV from various IJoystick implementations.
* Automatic CAN error recovery - CAN motors are bypassed temporarily on exception-throwing communication failures, to keep the rest of the code running. Certain other errors are logged and ignored.
* Removed testing package from cRIO builds.
* ExtendedMotors now support ANY_FAULT and COMMS_FAULT.
* ExtendedMotors no longer include _PID in mode names.
* Now specified that ExtendedMotors report temperature in Celsius, if at all.
* A number of ExtendedMotor methods no longer throw ExtendedMotorFailureException.
* ExtendedMotorFailureException is now a checked exception. (Since CAN functionality is not an officially finalized API, changes like this don't officially break backwards compatibility.)
* ByteFiddling.asInt32LE, ByteFiddling.asInt32BE.
* Made IgneousLauncherHolder publicly accessible.
* TestingException now always requires an argument. This was only internally used, so this shouldn't be an issue.
* PoultryInspector float-based components now accept ranges.
* Initial version of a deeper example of how to use the CCRE's more complex features on a simple robot.
* Joystick access example added.
* Added inversion option to BooleanDisplayComponent.
* Added exclamation point to the warning light view for aesthetics.

Bugfixes:

* Fixed broken serialization on a variety of PoultryInspector and Cluck systems.
* Fixed unbalanced SpinDevice weighting.
* Removed extraneous debugging statement in DeviceListMain.
* Improved Ticker synchronization.
* Fixed NaN-propagation bug in PIDControl that could permanently deactivate the PID.
* Clarified IJoystick documentation.
* Code is much less likely to crash if CAN devices cannot be contacted at startup.
* Removed some warnings for missing Javadoc in places where it doesn't make sense to be added.
* Miscellaneous warning fixes.
* Miscellaneous Javadoc fixes.

We'll probably have another release around the end of build season, but no promises.

Also, keep in mind that downloadable PoultryInspector builds (https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/releases) for your Driver Station are available from our GitHub page.

[Cel Skeggs]

CCRE release 2.7.0 is out! This release is light on features, and heavy on bugfixes and minor improvements, especially reliability improvements.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Release of CCRE with API v2.7.0.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Major Changelog:

* Access to information on roboRIO power rails.
* Emulator supports using physical Joysticks using JInput.

Minor Changelog:

* Most PoultryInspector components can be closed by clicking on a red circle.
* `RConfable` autorefreshing is now possible.
* `InstinctMultiModule` now allows for selecting autonomous modes over RConf.
* Packages built by the CCRE now include version numbers that can be programmatically queried.
* CCRE version numbers are now always included on roboRIO version reporting.
* The Direct roboRIO implementation now reuses `IntBuffer`s most of the time instead of allocating new ones.
* Shorter warnings when the HAL reports a warning.
* Set up `CluckTCPClient` to allow some useful subclassing.
* `CollapsingWorkerThread`s can now be terminated.
* Improved UM7LT driver reliability and automated recovery.
* Optional tracing mode in PoultryInspector for debugging Cluck traffic.
* PoultryInspector now reports network usage rate instead of sum usage.
* `CountingNetworkProvider` provides rate calculation.
* A `TopLevelRConfComponent` is provided that allows object browsing and some internal access in the PoultryInspector for emergency debugging.
* Added dragging-out of CluckRefs from `RConfable`s in PoultryInspector.
* An option in the PoultryInspector to not try to connect at all is now provided.
* The `org.team1540.tester.Tester` example now publishes controller power information.

Bugfixes:

* Fixed merged control components refusing to resend the same value, even if the remote end changed.
* Fixed crashes during init on the Emulator not logging the error.
* Fixed opening `DefaultNetworkProvider` connections sometimes waiting forever instead of timing out.
* Fixed rare crash due to concurrent modification of global logging targets.
* Cluck endpoints no longer arbitrarily fail to refresh after robot restart.
* roboRIO triggering mode start events no longer trigger constantly.
* Old log tarfiles are now removed from roboRIO after being retrieved.
* Fixed serialization of subscribed `RConfable`s and `RemoteProcedure`s.
* Fixed infinite recursion during failed remote logging.
* Added warnings for incorrectly-targeted Cluck messages instead of blindly accepting them.
* `*Mixing` methods now check for null arguments.
* Better error reporting in case `ByteFiddling.toHex` fails again.
* Fixed PoultryInspector trying to reconnect before a full network address was entered.
* Miscellaneous bugfixes and code cleanup.

A notable feature here is the ability to use physical joysticks with the Emulator: once plugged in, hold any button down and click on the UNATTACHED label on the Emulator.

Our first competition is this week. If anything breaks, we'll have a release out ASAP to resolve it. If you need any tech support during the event, keep in mind that I won't have access to email most of the day and might not see your message. If you will need faster responses to any issues encountered during the event, please contact me beforehand to ask for contact details.

[Cel Skeggs]

CCRE release 2.7.1 is out! This release contains a couple of RConf-related bugfixes and removes the prebuilt Javadoc folder. You can access the Javadoc online. (http://cgscomwww.catlin.edu/~skeggsc/ccre-javadoc/)

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Release of CCRE with API v2.7.1.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Major Changelog:

* Removed Javadoc from repository - generated files don't go here. Use the online version.

Minor Changelog:

* None.

Bugfixes:

* Removed most of the log spam from RConfComponents that can't connect.
* Fixed RConf-based autonomous mode switcher.

The CCRE had no issues during our last event except the minor issues fixed in this release. We expect the same for our next event.

[Cel Skeggs]

After over a month since 2.7.1, CCRE release 2.8.0 is out! This release adds interrupts and improves autonomous loop timing!

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Release of CCRE with API v2.8.0.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Major Changelog:

* Added support for interrupts on Digital Inputs!
* Added "recoverable events" that extend the recovery subsystem to be smarter and work better with highly-layered channel code.
* Disconnected autonomous mode cycles from periodic events.

Minor Changelog:

* Added ability to check if robot is connected to an FMS (as opposed to running outside of an official field.)
* Made `waitForEvent` return quicker and not poll.
* Added `setAutoCycleRate` and `getAutoCycleRate` to InstinctModule to control update rates of autonomous modes.
* Deprecated `InstinctModule.updateWhen`.
* Increased range of Emulator's current channels from 20A to 100A, to better reflect real ranges.
* Made mode test channels have more consistent behavior.

Bugfixes:

* Fixed failure to build cRIO libraries preventing use of roboRIO.
* Added missing null check to `filterEvent`.
* Fixed miscellaneous typos.
* Fixed miscellaneous compilation warnings.
* Added missing `serialVersionUID` to some PoultryInspector components.
* Fixed PoultryInspector lock-up if multiple CluckUnitTestComponents are dragged out.

Our robot code, which contains a very substantial demonstration of CCRE use, is posted (https://github.com/flamingchickens1540/quasar-helios-2015)! It's not perfect CCRE code by any means, but it successfully ran what was probably the most complicated robot in our team's history, with a level of automation that we haven't achieved before.

We're planning future direction of the CCRE at this time. If you have any input, please let us know by posting in this thread!

[Cel Skeggs]

CCRE release 2.8.1 is out! This is primarily a bugfix release in preparation for a larger 2.9.0 release.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Release of CCRE with API v2.8.1.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Documentation changes:

* First tutorial sequence now assumes use of a roboRIO instead of use of a cRIO. (#24)

Minor Features:

* Emulator outputs now respect disabled mode! (#48)

Bugfixes:

* Cluck no longer propagates errors through transmission.
* Improved support for Linux networking implementations.
* Better error insulation for StorageProvider.
* Fixed unexplained crash with null keys in CHashMap. Now it's an explained crash.
* Updated version of Cobertura.
* Added some missing buttons to emulator.
* Fixed pointer-out-of-bounds bug in the PoultryInspector rendering of merged IO. (#26)
* Fixed .gitignore to exclude PoultryInspector logs.
* Fixed PoultryInspector incorrectly displaying RConfComponents that contain inline AUTO_REFRESH entries.

New Tests:

* Test of file saving/loading infrastructure.

Notably, this release accompanies a tutorial sequence updated for the roboRIO and fixes for most of the known issues in the CCRE. (Except for fixes that require implementation of new features and APIs to fix.)

The CCRE's bugtracking and enhancement-tracking have been moved from Trello to GitHub (https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/issues).

We also plan to set up testbed robots for the cRIO and roboRIO, which should allow for unit testing of the complete stack, which should mean more rapid releases and fewer bugs.

[cadandcookies]

Just wanted to say that though my team isn't currently using CCRE, I'm planning on trying it out this summer and am very thankful that you've chosen to release your framework for the benefit of all. Thank you and keep up the good work!

[Cel Skeggs]

Just wanted to say that though my team isn't currently using CCRE, I'm planning on trying it out this summer and am very thankful that you've chosen to release your framework for the benefit of all. Thank you and keep up the good work!

Great! Please be sure to let us know your experiences with it.

If you have any issues or questions, you can either post them here or email me at robotics [AT] colbyskeggs [DOT] com. (Email obfuscated because spam.)

We plan to release CCRE 2.9.0 in a few weeks, and hopefully CCRE 3.0.0 a few weeks after that (maybe with CCRE 2.10.0 in-between.) We use semantic versioning, so 3.0.0 will be a point where we may break some amount of backwards compatibility. (There are things that we ought to change that we haven't because we've been trying to maintain backwards compatibility.)

[Cel Skeggs]

Finally! CCRE release 2.9.0 is out! Besides lots and lots of minor improvements and bugfixes, this release includes the major features of Control Bindings and Mecanum support!

Full changelog:
Release of CCRE with API 2.9.0.

WARNING: This release has not been tested on the cRIO due to a lack of a cRIO robot to test on. If you need cRIO functionality and don't have time to debug, refrain from upgrading.

Major changes:

* Added ControlBinding module.
* Added Mecanum implementation to DriverImpls.
* Added access to Joysticks 5 & 6 on the roboRIO. This still doesn't work on the cRIO even if a new DS is used.
* Added logging pane to emulator.

Minor changes:

* Added onInitComplete event to Igneous.
* Added addAllIfNotFound() to ConcurrentDispatchArray.
* Added asOutput()/asInput() to EventStatus and FloatStatus to match BooleanStatus.
* Added null checks to FloatFilter.
* Added invalid-parameter checks to some FloatMixing methods.
* Added CArrayUtils.collectIterable.
* Added LogLevel.next().
* Added ability to change bounds for PoultryInspector FloatControlComponent.
* Added ability to control LoggingTargets and RemoteProcedures from the PoultryInspector.
* Changed StorageProvider to accept arbitrary names for storage segments.
* Improved networking diagnostics.
* Expanded EventOutputRecoverable subsystem to include more EventOutputs. (debounce)
* Renamed BooleanMixing.ignoredBooleanOutput to BooleanMixing.ignored.
* Deprecated BooleanMixing.ignoredBooleanOutput.
* Renamed FloatMixing.ignoredFloatOutput to FloatMixing.ignored.
* Deprecated FloatMixing.ignoredFloatOutput.
* Deprecated EventStatus.countConsumers.
* Upgraded to Cobertura 2.1.1.
* Added deactivated QuickDeploy implementation.
* Added --failfast option to testing harness.
* Added assertFloatsNear to testing harness.
* Added TextBoxComponent to emulator.
* Added ccre.log.Logger to default list of imports in RobotTemplate.
* Deprecated CCRE.jar dispatch launcher.
* Deprecated RLoad mechanism.
* Deprecated Tokenizer.
* Deprecated Utils.dynamicCast.
* Deprecated Utils.getGenericClass.

Bugfixes:

* Fixed rendering glitches of PoultryInspector FloatControlComponent.
* Stopped attempting the impossible task of binding to port 80 on Linux and Mac OS.
* Specified behavior of CallerInfo more accurately.
* Improved edge case handling of DefaultThrowablePrinter.
* Improved behavior of ThrowablePrinter in exceptional scenarios.
* Improved edge case handling of CHashMap.
* Fixed DefaultStorageSegment handling of null values.
* Fixed completely broken FloatMixing.onUpdate() implementation.
* Simplified one FloatMixing.select() implementation.
* Improved error handling in PauseTimer main loop.
* Updated javadoc for DriverImpls.
* Fixed race conditions in EventStatus, MultipleSourceBooleanController, FloatMixing.select(), and PauseTimer.
* Fixed emulator race conditions.
* Fixed issue in check-header.sh caused by cRIO build.
* Clarified FloatMixing semantics on edge cases.
* Clarified *Input semantics on edge cases.
* Removed premature optimization of *Status objects.
* Clarified RemoteProcedure documentation.
* Slightly clarified licensing.
* Fixed miscellaneous typos.

New & improved tests:

* Added TestFilters.
* Added TestFloatMixing.
* Added TestWorkarounds.
* Added TestLineCollectorOutputStream.
* Added TestUniqueIds.
* Improved TestBooleanMixing.
* Improved TestPauseTimer.
* Expanded TestBooleanStatus.
* Expanded TestFloatStatus.
* Expanded TestMixing.
* Improved and expanded TestEventMixing.
* Improved and expanded TestEventStatus.
* Rewrote and expanded TestUtils.
* Rewrote, expanded, and improved TestCHashMap


The control binding system lets your drivers configure their OI to their specifications, without (too much) programmer involvement. A programmer can simply write code like:


// ...
public static final ControlBindingCreator driveControls = Igneous.makeControlBindingCreator("Drive Code");
// ...
BooleanInput highGearButton = driveControls.addBoolean("High Gear");
// ...
FloatInputPoll leftDriveAxis = driveControls.addFloat("Drive Axis Left");
// ...


Then, on the running robot, a user can select any buttons/axes to use for specific controls by holding the button and selecting the control. And then press a button to save their configuration permanently, so this works even if you turn off your robot.

http://i.imgur.com/5ISOHdY.png

And, of course, the emulator will just display these controls as the names you gave them, which means that you don't have to remember the button and axis numbers of everything during emulation!

[Cel Skeggs]

I've been working on some prototypes for the 3.0.0 release. This release includes a lot of improvements to the Mixing system, namely by getting rid of the Mixing, FloatMixing, BooleanMixing, and EventMixing classes, and using Java 8's new default interfaces to implement the same functionality on the objects themselves.

As an example of how much this can help:

Mixing.select(calibrating, FloatMixing.multiplication.of(FloatMixing.multipli cation.of(p, (FloatInput) dconstant), (FloatInput) period), FloatMixing.always(0));

becomes

calibrating.toFloat(p.multipliedBy(dconstant).mult ipliedBy(period), 0);

which is much easier to understand and has a lot less boilerplate!

Also, the Input/InputPoll distinction is going away, which means (for example) that code will no longer be scattered with FloatMixing.createDispatch and BooleanMixing.createDispatch everywhere!

To replace the previous easy of use of InputPolls that is now going away, code like:

BooleanMixing.createDispatch(new BooleanInputPoll() {
public boolean get() {
return /* some expression */;
}
}, Igneous.globalPeriodic)

is now written as

new DerivedBooleanInput(/* dependent inputs */) {
protected boolean apply() {
return /* same expression as above */;
}
}

This is slightly more complicated in that you have to specify when the value could update, but it ultimately will lead to better, easier-to-understand code and less overhead.

[Cel Skeggs]

For anyone interested, I will be presenting about the CCRE at FIRSTFare this weekend! (FIRSTFare is a PNW robotics conference, for those who don't know.)

I will post the slides afterwards, and might record either the presentation itself or a practice run for anyone who can't make it.

(Also, work on 3.0.0 is going strong! Feel free to come take a look and/or help out on our GitHub repo (https://github.com/flamingchickens1540/Common-Chicken-Runtime-Engine/tree/devel-3.x.x)!)

[Hsifeulbhsifder]

Quick Question, roughly how long is the compile and deploy time?

[Cel Skeggs]

Quick Question, roughly how long is the compile and deploy time?

On CCRE v2.9.0, the current stable version, it's a bit longer than WPILib but not by much.

On the latest development version, which will be released in a couple of weeks (probably), it's four seconds. No, that's not a typo. We rewrote the deployment system from the ground up for this version, and the benefits show.

Obviously, YMMV, but that's how it worked in my last test with a fairly typical setup.

[Hsifeulbhsifder]

That's pretty impressive, our current software takes about 1-2 seconds but can be loaded dynamically, so I was wondering if the CCRE can be loaded dynamically as well i.e. Changing code while the robot is running and not breaking. Although, we require dynamic linkage to a separate binary, and I was wondering if you guys have a better solution. Thanks for the help.

[Cel Skeggs]

That's pretty impressive, our current software takes about 1-2 seconds but can be loaded dynamically, so I was wondering if the CCRE can be loaded dynamically as well i.e. Changing code while the robot is running and not breaking. Although, we require dynamic linkage to a separate binary, and I was wondering if you guys have a better solution. Thanks for the help.

It's possible, but we also provide easy ways to tune and store values on the robot, so most tweaking jobs can be done without code downloads. Plus, once you get below fiveish seconds, it probably doesn't matter too much exactly how low you go.

The reason that our deployment system is so fast in comparison to WPILib's system is that we only open two SSH connections - one for 'admin' and one for 'lvuser', but we could probably find a way to only use one of those. We could probably also parallelize the different deployment steps, and maybe also check hashes to see if we need to download at all.

We aren't planning to improve deployment much more right now, as we've been focusing our development time on improving our core framework as much as possible. Once we release v3.0.0, we plan to keep backwards compatibility for a relatively long time, which limits the extent of our possible refactorings.

[Jaci]

Once we release v3.0.0, we plan to keep backwards compatibility for a relatively long time, which limits the extent of our possible refactorings.

Why not release as soon as possible? Most of your users will be during build-season start all the way through to a few months after champs due to offseason events. Just my opinion, but as soon as possible seems like the most optimal time to do some major refactoring.

[Cel Skeggs]

Why not release as soon as possible? Most of your users will be during build-season start all the way through to a few months after champs due to offseason events. Just my opinion, but as soon as possible seems like the most optimal time to do some major refactoring.

I'm not quite sure what you're saying - are you suggesting that we should release v3.0.0 as soon as possible? We do plan to - I've spent well over a hundred hours recently working on it. For anyone who wants to try it now, it IS available on the devel-3.x.x branch of our repo, but we won't release it (give it a final version number and mark it as stable) until it's ready.

If you mean in general that we should release all our changes as they happen, again, they are available, but we want to provide assurances to users that what they're doing won't break constantly as we change things. That's why we following Semantic Versioning practices in our code, which means only breaking backwards compatibility in major releases.

[Jaci]

Alrighty, I probably misunderstood something. All good, I look forward to seeing how the code evolves over time :)

[Cel Skeggs]

Alrighty, I probably misunderstood something. All good, I look forward to seeing how the code evolves over time :)

Alright! Thanks for your interest - and do feel free to suggest anything you think would make this better.

Aaaand... on a different topic, we're getting a solid amount of attention on GitHub:

http://i.imgur.com/faD4bWM.png

If your team ends up using the CCRE during the season or plans to, please let me know about it and let me know anything I can do to help!

Also, I'd love to hear the experiences of anyone who's tried it and decided against it, since we want to make it as useful as possible.

[Cel Skeggs]

At long last! CCRE prerelease 3.0.0-pre1 is out! It's only been 3-4 months.

This is not quite yet the final 3.0.0 release, but it's close, it has a huge list of improvements, and it works!

Full changelog:
Prerelease of CCRE with API 3.0.0-pre1.

Highlights:

* Structure: Removed support for cRIO.
* Structure: Started using Java 8 features everywhere.
* Dataflow: Removed pollability as a dimension of complexity.
* Dataflow: Moved *Mixing methods to instead be default methods on interfaces.
* FRC and roboRIO: Renamed Igneous to FRC.
* Documentation: Added a new Scribble-based documentation system.
* Deployment: Added DeploymentEngine system to manage deployment to robots, which is many times faster than WPILib's deployment tool.

Documentation changes:

* Added a new Scribble-based documentation system.
* Removed examples from last year's FIRSTFare presentation and added this year's examples.
* Continuous integration via Travis CI is now in use, which covers unit testing and checking of certain code maintenance targets, such as keeping license headers up-to-date. This should help future maintainers.
* Javadocumented just about everything important.

Dataflow changes:

* Removed InputPolls. Inputs only now.
* Added DerivedInputs, which replace some functionality of InputPolls.
* Pollable I/O is replaced by interfaces which take polling events and return updating I/O.
* Moved *Mixing methods to instead be default methods on interfaces.
* Added UpdatingInput as a superinterface of the *Input classes.
* send is no longer a fundamental method, but an implementation on top of the new onUpdate.
* Removed `unsend` and replaced it with unsubscription EventOutputs returned by the `send` family of methods.
* Renamed Statuses to Cells and extracted IOs as superinterfaces that merge Inputs and Outputs.
* Converted PIDControl into PIDController and inverted control to make more sense.
* Support for taking derivatives of float channels.
* Added miscellaneous new remixing methods and constant fields.
* Renamed EventStatus.clearListeners to __UNSAFE_clearListeners.

Error handling changes:

* Let setupRobot() and autonomousMain() throw Throwables.
* Added safeSet/safeEvent for top-level handling of errors.
* Removed EventOutputRecoverable and restructured error handling to ensure consistent propagation.

FRC and roboRIO changes:

* Renamed Igneous to FRC.
* Shorted names of everything in FRC.
* Removed the WPILibJ-wrapping style of FRC/Igneous implementation. Direct is the only implementation now.
* Added support for FPGA Counters on the roboRIO.
* Removed WPILib Eclipse plugins as a dependency.
* Added sensorPeriodic as the default polling interval in FRC.
* Renamed IgneousLauncher to FRCImplementation.
* Removed the driver station screen I/O methods.
* Added simpleControl of CAN to FRC and ExtendedMotor.

Deployment and build changes:

* Added DeploymentEngine system to manage deployment to robots, which is many times faster than WPILib's deployment tool.
* Removed dependency on Git in build process; versions are now specified in a source file.

Control interface changes:

* All Joysticks have POV hats now.
* Converted POV hat accesses to angle checks rather than angle and press accessors.
* Added AbstractJoystick to assist conversion of pollable interfaces into updating interfaces.
* Added default ControlBinding.
* Renamed IJoystick to Joystick.

Structural changes:

* Removed support for cRIO.
* Started using Java 8 features everywhere.
* Renamed all of the projects to have shorter and more accurate names.
* Changed expected project structure; added script to autoupgrade projects to v3 structure.
* Removed CCRE Collections.

Testing changes:

* Added FakeTime, for faking time in tests.
* Converted test infrastructure to JUnit.
* Unit tested huge sections of the CCRE that weren't before.

Miscellaneous changes:

* Added an abstraction for Time, for use in time-influenced testing.
* Renamed StorageProvider to Storage.
* Made StorageSegment its own implementation: now final instead of abstract.
* Slimmed down ExpirationTimer.
* Slimmed down StateMachine slightly.
* Added support abstractions for the dataflow event dispatch infrastructure.
* Added utility to rewrite CRLFs to LFs.
* Added miscellaneous support abstractions.
* Rearranged a few packages.
* Renamed just about everything to make meanings clearer.

Networking changes:

* Deabstracted the networking system and integrated traffic metrics.
* Added versioning to the Cluck protocol, which is backwards-compatible with v2.x.x Cluck, but only until the first protocol version increment.
* Added ability to subscribe to IOs.
* Deprecated Cluck UNSUB messages; they are replaced with NACKs.
* Cells are no longer RConfable.
* Removed default PoultryInspector link naming.
* Removed openDataInputStream and openDataOutputStream from ClientSocket.
* Removed minimum logging levels from network logging.
* Removed old Cluck searching methods.

UI changes:

* Resized Emulator components so that they require less screen space.
* Added window title to PoultryInspector.

Removals:

* Removed support for Phidget.
* Removed BooleanFilter.
* Removed StringHolder.
* Removed IgneousCore.
* Removed BootLogger.
* Removed ccre.launcher.Launcher dispatcher.
* Removed RLoad client and server.
* Removed Tokenizer.
* Removed the CCRE_Examples project.
* Removed MultipleSourceBooleanController.
* Removed Utils.currentTimeSeconds.
* Removed cRIO workarounds.
* Removed alternate storage implementations.
* Removed miscellaneous premature optimizations.
* Removed all sorts of deprecated and outdated methods.
* Removed deprecated EventOutput and updateWhen code in InstinctModule.
* Removed ApolloGemini2014 and InfernoDante examples.
* Removed vestigal kinect support, as it was only easily supported with the cRIO.
* Removed other vestigal and deprecated utility methods.

Implementation changes:

* Moved useCustomCompressor into FRC.

Bugfixes:

* Fixed incorrect disabling of digital outputs in emulator.
* Improved all sorts of bounds and argument checks throughout the CCRE.
* Fixed lots of edge cases.
* Fixed encoding incompatibilities and standardized on UTF-8.
* Fixed incorrect error propagation when broadcasting.
* Added missing top-level error handling.
* Fixed some miscellaneous race conditions.
* Fixed incorrect naming of mecanum drive code.


The length of that list should hopefully justify how long this release took to get out the door. Keep in mind that the thing with adding more unit tests took a lot longer than the single changelog line might imply.

Highlights:


Being a major-number release, we were allowed to break backwards compatibility for the first time since v2.0.0! This was part of the inspiration for many of the changes made.
We removed support for the cRIO. Getting Java 8 to work on the cRIO would have been more of a challenge than we wanted to take on.
Thanks to that, the CCRE now takes advantage of a significant chunk of Java 8's featureset! Default interfaces are the biggest advantage, because they allow us to have both a) easily implemented channels AND b) remixing methods on the channels themselves.
We realized that the InputPoll versus Input dichotomy was not helpful in real programs, and only made things more complicated. So, we got rid of it! Everything's an Input now. To replace the previous ease of defining new InputPolls, there are now DerivedInputs that are almost as easy (for defining InputPolls) and much much easier (for defining Inputs.)
We renamed a very large number of things in this release, because the old names weren't very helpful. For example: the Igneous subsystem is now called the FRC subsystem.
We added an entire new style of documentation. Check it out here! (http://cgscomwww.catlin.edu/~skeggsc/ccre-docs/) This uses Racket's Scribble system, which is good for guidebooks like this. This documentation is not yet complete, but should be a good place to start with the new version.
We wrote the DeploymentEngine to simplify the deployment of code to FRC robots, and it just so happened that it also sped up everything by a significant margin!
On a related note, we got rid of our dependency on WPILib's Eclipse plugins, so installation is smoother than ever.


Looking towards the future, we have some more changes planned for the final 3.0.0 release, which should be coming in a few weeks. We do have the opportunity to make more backwards-incompatible changes for that release, but we've made most of them by now, so don't worry too much about that.

We also plan to do things like Eclipse plugins so that you don't have to download the CCRE source to use it!

One quick note on upgrading to CCRE 3: we have a tool that will offer to upgrade your v2.x.x projects for you. Simply import your old project into your new CCRE 3 workspace, and press Build All. You should be asked if you want to upgrade your project to CCRE 3: make sure your old code is backed up, and then press Yes and type in your team number. This won't do everything for you, but will do the easy things like replacing InputPolls with Inputs, replacing Igneous with FRC, and handling most of the other major renamings. You will have to manually move your Mixing invocations to the new system, however.

[Cel Skeggs]

Since we're coming up on build season, here's a clarification about using this under the rules:

Since the CCRE is publicly available, you can use it for FRC robot software legally under the rules (at least as of 2015), if you don't make any changes before Kickoff. If you do make any changes before Kickoff, you must make your changes available publicly, which you could do for example by pushing it to a public repository and either posting the link somewhere or opening a pull request to the main CCRE repository.

We will make sure that 100% of our work is available in our repository at the point of Kickoff. Most of it will be in the latest release - some of it will probably be in the development branch devel-3.x.x - and the tiny remainder may be scattered around feature branches, which you will be able to find on GitHub under the branch listing.

During the build season, we will continue to release all of our changes as normal - we don't use any private versions internally, except, of course, for the time during which each feature is being developed.

If you have any questions or concerns - just ask!

[Cel Skeggs]

More work has been done on the documentation! It's currently up to about 13,000 words across a variety of topics. It'll probably reach around 25,000 words by the time it's done, so don't expect it to be quite complete. It is being updated almost daily with incremental additions.

You can view the new-style documentation here. (http://cgscomwww.catlin.edu/~skeggsc/ccre-docs/)

If you have any questions, comments, or suggestions about the documentation - including typos - just post them here!

[Cel Skeggs]

Sorry about the wait on 3.0.0. I'm almost done with my college apps, and CCRE v3.0.0 should be out at least a few days before Kickoff.

You can track the progress of the release on this PR. (https://github.com/flamingchickens1540/common-chicken-runtime-engine/pull/141)

[Cel Skeggs]

At long last, CCRE v3.0.0 is OUT!

This is a MAJOR RELEASE. It contains all the same changes as v3.0.0-pre1 plus a few extras:

Major changes:
* Rename DriverImpls to Drive and drop "Drive" from method names
* Expand new-style documentation significantly
* Extract setup-mode EventOutputs as CancelOutputs

Minor changes:
* Add single-parameter motor creators to FRC
* Add FloatIO accumulate & friends
* Rename static BooleanOutput.onChange to BooleanOutput.polarize
* Made FloatOutput.filter work consistently with BooleanOutput.filter
* Add waitUntilNot with timeout for symmetry with waitUntil
* Change default value of subscribed FloatInputs to start at NaN
* Collapse various duplicate transformation methods to use each other
* #90: Remove HALControlWord
* Made InstinctMultiModule final
* Clean up miscellaneous code

Bugfixes:
* Fix handling of infinities by motors
* Fix edge case of onChangeBy
* Fix timing issue in PauseTimer unit test
* Fix float inspecificity in testing utilities
* Fix lack of error information during setRoots in Deployment Engine
* Fix occasional error silencing bug in testing utilities
* Fix miscellaneous documentation typos
* Fix CI integration issues

As this is a major release, we now have a backwards compatibility base established: we cannot break backwards compatibility until 4.0.0 - and since 4.0.0 is probably at least a year off, you should be set to trust that the current version is stable and will continue to work.

There are a couple of minor bugs remaining that we're going to fix ASAP and get out as 3.0.1 shortly, but probably nothing major.

And remember these links: the new-style documentation (http://cgscomwww.catlin.edu/~skeggsc/ccre-docs/) and the Javadoc (http://cgscomwww.catlin.edu/~skeggsc/ccre3/).

[Cel Skeggs]

3.1.0 will be out sometime next week. 3.0.1 is being skipped because we need to get a release out with the fixes to support the 2016 roboRIO image as soon as possible, and that will require you to upgrade to the 2016 image, so it doesn't qualify as simply a patch release.

Also, this can't happen until after the 2016 NI Update Suite is unlocked and I do enough work to finish adding support, which is why I can't do it now.

Obviously, it won't break any code or API compatibility, just require a newer roboRIO image on the bot.

Also, our CCRE repository now has all of our WIP code as well as all of our releases - simply browse the branches to see all of them, or just wait until they get included in a release.

[Cel Skeggs]

CCRE v3.1.0 is out!

The CCRE now supports the FRC_roboRIO_2016_v19 roboRIO image! It also no longer supports the FRC_roboRIO_2015_v23 roboRIO image, which is why it's a minor release rather than a patch release.

A few other bugs have also been fixed in this release, but no user-visible features.


Release of CCRE with API 3.1.0.

Major changes:
* Add support for 2016 roboRIO image

Minor changes:
* Support new mDNS hostname
* Remove extraneous StandardStreamLogger
* Add support for testing logging messages
* Add testbed sample for Valkyrie

Bugfixes:
* Fix serialization of PoultryInspector components
* Fix infinite loop bug with recursive error reporting in Cluck
* Fix CCRE version number support


The new support might have some bugs - there were a lot of changed JNI bindings! If anything seems to not work, reporting it immediately will get it fixed as fast as possible.

[Cel Skeggs]

CCRE v3.2.0 is out!

This release has two large features (CCRE Eggs and Behavior Arbitrators) and a wide variety of minor features. Also bugfixes.


Release of CCRE with API 3.2.0.

Major changes:
* Implement CCRE Eggs, which package up a code snapshot for later deployment
* Implement Behavior Arbitrators, which manage active subsystem controllers

Minor changes:
* Add static Output.combine methods
* Add negateIf, negatedIf
* Add conditional method for booleans: BooleanInput.select
* Add ExpirationTimer.getRunning method as BooleanIO
* Add ExpirationTimer.runWhen method
* Add onPress, onRelease, onChange with integrated send
* Add absolute value filter
* Add cell() shortcut to Outputs
* Add event and toggle button control bindings
* Add sample of Behavior Arbitrator use
* Provide BooleanIO-based control of InstinctModules
* Remove year-specific message from library version

Bugfixes:
* Fix certain test failures to not appear as errors
* Fix broken FRC inTeleopMode() method
* Fix loading storage segments with escaped names
* Fix version shortening for development versions
* Fix PoultryInspector RConf left click glitch
* Fix POV always-UP glitch that broke ControlBinding
* Fix javac incompatibility on some systems


CCRE Eggs are a way to build (lay) a snapshot of code into a single executable JAR which has the ability to deploy (hatch) that snapshot of code to a robot, even without a development environment installed. This has applications in both saving old code and letting non-programmers deploy new or old versions of code to a robot. CCRE Eggs are still in their first iteration, but they'll get better over the next few releases. For example, we'll add a deployment-time GUI to let you decide where you want to deploy an egg.

Behavior Arbitrators are the other major feature: you can specify a prioritized set of mutually exclusive "Behaviors", and the arbitrator selects the highest-priority behavior that currently wants to run, and allows it to control the actuators associated with that arbitrator.

For example, you could have a "pit safety behavior", "autonomous behavior", "mecanum behavior", "tank drive behavior" and "test mode behavior", and the arbitrator would automatically select the best behavior to apply in the situation, based on the priorities and conditions that you've specified.

Behavior Arbitrators are also in their first released iteration, but they're already practically useful. Behavior Arbitrators are joining Control Bindings, Cluck, Instinct Modules, Control Structures, and RConf as the primary components of the CCRE toolkit.

[Cel Skeggs]

CCRE v3.3.0 is out!

This release is from over a month of active software writing, and adds a very large number of minor features and quite a few major features as well.


Release of CCRE with API 3.3.0.

Major changes:
* Add recording toolkit and Timeline Analyzer
* Add discrete channels
* Rearchitect and expand serial bus handling system
* Add new fleshed-out CAN Talon SRX interface: TalonExtendedMotor
* Add ethernet camera support to PoultryInspector
* Overhaul timing system to use a unified scheduler
* Add StopwatchTimer
* Add support for SD540 speed controller
* Add support for Spark speed controller
* Add support for Victor SP speed controller
* Add support for Talon SRX over PWM

Minor changes:
* Extend Time.* constants to longs to avoid overflow
* Add rumble support to Joysticks
* Support axis inversion in ControlBindings
* Add "OPEN NETWORK" button to PoultryInspector
* Allow PoultryInspector component removal by dropping components back into network palettes
* Add tunable ramping methods
* Add main class selector to SampleRobot
* Add recorder example to Valkyrie code
* Add selectByState to StateMachine
* Add mode tracking via discrete inputs to FRC API
* Add discrete input support to BehaviorArbitrator
* Add Storage support for deletion, existence checking, and file listing
* Deprecate old derivative implementation; add version without the zero-delta bug
* Add modulation (remainder) operation to FloatOperation
* PauseTimers now can take a FloatInput for the delay
* Add support for reading total current of the PDP
* Add Faultable<F> interface
* Add Derived...IO classes to match Derived...Input classes
* Allow Cluck publishing of any IOs, not just Cells
* Improved documentation in various ways

Invisible changes:
* Speed up unit tests
* Overhaul time testing system
* Switch travis CI from trusty-based to container-based
* Add support for reversed InputStreams to Cluck
* Add support for multiple SuperCanvas applications
* Update libwpilibJavaJNI.so to newer, slimmer, custom version
* ExtendedMotors are now enabled as part of simpleControl()
* Miscellaneous code clean-up and refactoring
* Apply author name change

Bugfixes:
* Fix long-standing serialization issue in PoultryInspector
* Fix FRC.counter to not fail most of the time
* Miscellaneous fixes


The recording system is one of the most interesting new features:

http://i.imgur.com/MAT7tP3.png
http://i.imgur.com/15qpItz.png

This system allows recording precise information about the function of a robot, down to an accuracy of 10 microseconds. In the above diagram, you can see a snippet from an actual robot test run that shows precise information on the timing details of certain periodic events and the exact state of the robot's scheduler. Tools like this allow recording an entire match and looking back later to discover exactly what happened. To use this, look at the ccre.recording package.

We've also introduced a new scheduling system, which collapses all of the different timing threads into a single thread, which increases consistency of timing, simplifies timing code (so fewer bugs), and makes finer-grained CPU load analysis and management possible. You don't need to do anything to work with this - it's automatically used by the latest version of the CCRE.

We added support for SPI and I2C, and expanded support for RS232. We expanded the CAN Talon SRX interface to allow access to almost all of its internals through a CCRE-style reactive interface. We also added support for other PWM speed controllers like the SD540, Spark, Victor SP, and Talon SRX (when used over PWM.)

Discrete channels are a new addition to the core architecture of the CCRE: these are like boolean channels, but with a used-defined set of options, so that it can be used for robot mode access, behavior arbitrators, and more.

The PoultryInspector interface is now slightly more intuitive, and it now supports viewing AXIS M1011/M1013 webcams, including drawing targeting rectangles on top.

This releases includes fixes for all on-field bugs that we know about, and we'll be certain to release any further fixes promptly during the competition season. If you find anything that doesn't work, please contact me immediately so that we can get it fixed quickly.

[Cel Skeggs]

CCRE v3.4.0 is out!

This release is from our competition season, and while it doesn't involve very much in the way of new features, it has a boatload of minor improvements and bugfixes.


Release of CCRE with API 3.4.0.

Major changes:
* Add optional Phase Verifier system

Minor changes:
* Add safe ExtendedMotor control methods
* Add unique identifiers to roboRIOs
* Support programmatic autonomous mode aborting
* Export IO subscribes through Cluck API
* Add 16-bit integer decoders to ByteFiddling
* Scale up PoultryInspector webcam views
* Raise PoultryInspector Webcam highlight components on top of everything else
* Allow DeploymentEngine users to access Emulator API
* Add view toggle button to PoultryInspector channel components
* Change default views on float components to textual
* Add startIfNotAlive to ReporterThread
* Add reset method to PIDController
* Remove CCRE 2->3 updater
* Let RS232IO extend Flushable
* Use events for flow phase cancels in Scheduler
* Improve Deployment Engine API slightly
* Add launcher for CCRE core tests
* Improve sample robot code
* Improve Javadoc slightly

Invisible changes:
* Increase priority of InstinctModule threads
* Streamline roboRIO detection in DeploymentEngine
* Improve TimelineInspector project setup
* Improve use of @Override
* Add phase annotations to a significant portion of the CCRE
* Simplify miscellaneous pieces of code
* Cache byte arrays to avoid GC churn in WebcamReader

Bugfixes:
* Ensure that the user intends to overwrite files in PoultryInspector save dialog
* Fix IO subscriber suffix confusion bug
* Fix Emulator reference issues by offloading classloading from itself
* Fix PauseTimer BooleanInput contract violation
* Fix camera over-refresh bug
* Provide consistent velocities in Emulator
* Remove extraneous logging from Emulator joysticks
* Hide NoRouteToHost log spam
* Increase length of Cluck TX queue
* Ensure that voltage logging includes the entire range
* Fix recorder printing name bug
* Fix miscellaneous Eclipse issue


Are you interested in helping develop the CCRE? Since I'll be graduating from high school, I won't have as much time to dedicate to the CCRE next year, and while we have plenty of talent ourselves to keep it maintained, we're interested in getting contributions from other teams to help us keep it going as long as possible.

If you want to help - or might want to help but aren't sure - drop me a line either here or in the FIRSTCodes Slack (http://www.chiefdelphi.com/forums/showthread.php?t=146938)!