[WPILib Blog] WPILib 2020.2.2 Update

Posted on the WPILib Blog, 1/17/2020: https://wpilib.org/blog/wpilib-202022-update

We are pleased to announce the availability of the first 2020 update release (2020.2.2) of WPILib, the official FIRST libraries for robot programming in C++ and Java. This is an update to the Kickoff Release.

Machine Learning Technology Preview

As we teased in last week’s blog post, our Machine Learning Technology Preview is now released and available for all teams to try out. The release includes documentation describing how to get machine learning running on your robot, over 4500 images from a real FRC field to train with (of which we have labeled 500 for you), and all the necessary robot software preinstalled in the FRCVision Raspberry Pi Image.

Advantages of using machine learning over traditional methods of object detection are that it is easy to recognize objects without retroreflective tape, it works under a variety of lighting conditions without branching, and it is able to recognize multiple types of elements at the same time.

You can get started taking a look at the documentation.

Changes in this Release

WPILib

Java

  • Make Color constructor public (#2222)
  • Fix named colors having zero values (#2269)

C++

  • Implement missing definition of PIDController::SetPID() (#2239)
  • Don’t add CommandBase to LiveWindow (#2255)
  • Fix default command name (#2256)

C++ and Java

  • Add Axis enum to XboxController (#2253)
  • Fix typos in color names (#2265)
  • Hook old and new commands into LiveWindow (#2053)

New Command Framework

  • [C++] Fix JoystickButton and POVButton (#2259)
  • [Java, C++] Fix CommandScheduler.cancelAll() when called from outside the run loop (#2251)
  • [Java] Make Button class concrete (#2244)

Documentation

  • Fix search in Javadocs (#2229)
  • Clarify AddressableLED constraints on number of drivers and LED string length (#2231)

Simulation

  • Default simulation voltage to 12V with user rails active (#2224)
  • Handle save file having window size=0 (#2260)
  • Fix SPI DIO count (#2272)

PathWeaver

  • Fix waypoint arrow rotation (#164)
  • Add field image for 2020 Infinite Recharge field image (#172)
  • Fix error handling when exporting paths (#169)

RobotBuilder

  • Fix frc namespace for CustomComponents (#195)
  • Fix case of Requires in C++ comments (#193)

Installation Instructions

The installation instructions for this release are the same as for 2020.1.2. However for this update, it is okay to skip reinstalling Visual Studio Code, the JDK, and the compiler if you already installed them with 2020.1.2.

After you install the update, VS Code will prompt when opening an older project whether or not you want to upgrade it to 2020.2.2.

12 Likes

Out team updated programming PC’s to this version. We’re using the new command framework. After updating our build gradle plugin changed as follows:

plugins {

id "java"

id "edu.wpi.first.GradleRIO" version "2020.2.2"

}

None of the commands that we were scheduling before the update will schedule.

I reverted the gradle file to version “2020.2.1” and the commands will schedule again.

I noted that there was no changed to the dependencies in our project after the update and wpilib-new-commands are still version 2020.0.0 … Should there have been an update to these?

Those command json files do not need to be updated, they use a trick to ensure they match the WPILib version.

Also, you mean you reverted to 2020.1.2, right? 2020.2.1 is broken and was never publicly released.

I can ask someone to look into the scheduing issue, that is bizzare.

Correct I reverted to 2020.1.2 and commands were scheduled properly.

Can you link to your code?

1 Like

Code is on github. FRC-team-4020/Robot2020

Current version is branch add-intake-test.

We’re currently running with bot name of test. That determines which subsystems and tests load in robot container.

We only have the new command base dependency loaded in vscode
.

Note that there are still some debugging commands in robot.java. We made a testchooser that you have to use to select the test command that runs. Debug commands may produce a stack dump if you don’t select a command to run.

Perhaps the following will help identify what changed.

In the release notes for 2020.2.2 I noted the following changes…

Hook old and new commands into LiveWindow (#2053)

[Java, C++] Fix CommandScheduler.cancelAll() when called from outside the run loop (#2251)

These could possible be responsible for the change we’ve seen.

I think I narrowed down the problem a bit. Our team is writing Test Commands to use in Test mode to validate new subsystem and provide future diagnostic tests as the subsystems are developed.

We’ve primarily been running Test mode to run these Test Commands. We’ve created a sendable chooser to select the tests that we want to run just like the sendable chooser is used for autonomous.

I cut and pasted all of the code from our Test Init method into the Teleop Init method and ran the code in Teleop. The code runs as expected and all commands are scheduled.

In Test mode in release 2020.2.2:
Default commands or commands bound to triggers or buttons in Robot Container are not scheduled.
Any commands scheduled in Test init or Test periodic are not scheduled.

I suppose it’s possible that they are canceled immediately after they are scheduled.

I put a diagnostic statement immediately after scheduling a command in Test Init and it returns false.
testCommand.schedule();
System.out.println(“Iscommand scheduled” + CommandScheduler.getInstance().isScheduled(testCommand));

Same statement returns true if I move it to TeleopInit and run it there.

In release 2020.1.2:
Default commands or commands bound to triggers or buttons in Robot Container are scheduled as expected.
Any commands scheduled in Test init or Test periodic are scheduled as expected.

I’ve not test Autonomous in release 2020.2.2.

That fix in 2020.2.2 restored the old (documented) behavior that was broken when the command frameworks were split out this year. Test mode enables LiveWindow which allows setting motor values on the dashboard and conflicts with running commands that could be setting the same stuff.

For what you are trying to do, putting the code in teleop with a specific way to activate it is how it should be done.

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