[FRC Blog] Control System Update

[bdaroz]

From http://www.firstinspires.org/robotic...-system-update

Written by Kevin O'Connor, Robotics Engineer, FIRST Robotics Competition.


FIRST and our FRC Control System team have spent the summer improving the FRC Control System. Information about some of those changes, as well as the announcement of the 2017 season beta test teams who will help us validate those changes, is in this blog. We are also working on information about device legality, but we’re not quite ready to share that yet, so stay tuned.

Device Libraries

This season we are making a change to WPILib (for all 3 software languages) where third party software for items not in the Kickoff KOP will be provided separately by that third party.

Since the CMUCam (and perhaps earlier), companies have provided powerful sensors and controllers to FRC teams. We encourage the development of these devices as they help raise the ceiling for teams and enable them to create incredible autonomous and semi-autonomous robot routines. In the past few years, the number of these devices has increased more rapidly (which is good!), but it comes with difficulties. Integrating software for these devices into WPILib requires a substantial amount of work from the device manufacturer and the FRC Control System team, and, we acknowledge that the status quo is not sustainable. As a result, we’ve implemented a solution that is more sustainable for the CS Team and removes some of the headache for vendors to develop and test their products.

Going forward, WPILib will not include direct support for many of these sophisticated devices (including CAN Jaguar and CAN Talon SRX). Instead, it allows the integration of 3rd party code into teams’ WPILib programs. Suppliers provide installers which place their libraries into the correct location on the user’s system. WPILib tools will automatically detect the libraries and allow them to be used in FRC programs. FRC will create a “one-stop-shop” page for these installers to help teams easily locate the software for their selected devices.

We acknowledge that this is a compromise; teams will take additional steps to get and install libraries, but WPILib development is more sustainable and there’s a clearer implementation and ownership path for 3rd parties.

The 2017 Beta Test teams will test this change and provide feedback on how to make the experience as smooth as possible.

Robot Radio

In June, we blogged that we would be introducing a new radio for the 2017 season, and can do so now. The new radio for the 2017 season is the OpenMesh OM5P-AC. The OpenMesh OM5P-AN will continue to be competition legal, provided it has updated 2017 firmware. In order to comply with FCC regulations, the FRC firmware for the OM5P-AC and OM5P-AN disables the web interface and SSH access. You will only be able to configure the settings on the device using the FRC Radio Configuration Utility. Meanwhile, we will add flexibility to that tool to cover as many use cases as possible.

The OM5P-AC is available from Open Mesh and will soon be available from AndyMark. See those sites for pricing and availability. Devices won’t be usable until the firmware and configuration utility are available to teams. Worst case, they’ll be posted on Kickoff Day, and if we can publish sooner, we will announce via this blog.

Beta Testing

The 2017 Beta Test teams have been selected! Thank you to everyone to applied. Teams were selected on the basis of location, past Beta performance, Beta application history, and submitted essay.

Selected teams will help the FRC Control System team test changes to the software libraries and any new hardware FIRST decides to test. Beta teams pledge to share their learnings and findings with the community, especially teams in their area, so make sure to reach out with any questions you may have for them via the FIRST Forums and keep your eyes peeled for any “Open House” or training seminar events in your area.

We are grateful to this group for giving our systems a test run before the season, and we thank them for helping us find and fix any issues before we deploy to the entire FRC community!

Ed: List of teams removed

[AllenGregoryIV]

That all seems like good news to me. I like the device libraries, they should make it easier to import libraries like the NavX library, etc.

[bdaroz]

I'm just hoping that they move to a more standard library distribution / installation method (eg maven).

[Dominick Ferone]

The only problem i have with these routers, is they only have 2 ports. When at competition we couldn't tether in and view the camera at the same time. One port had tether and the other has the rio then.

[AllenGregoryIV]

Originally Posted by Dominick Ferone

The only problem i have with these routers, is they only have 2 ports. When at competition we couldn't tether in and view the camera at the same time. One port had tether and the other has the rio then.

Can't you just tether with the USB cable? You can also just add a small network switch to the robot.

[adciv]

Originally Posted by Dominick Ferone

The only problem i have with these routers, is they only have 2 ports. When at competition we couldn't tether in and view the camera at the same time. One port had tether and the other has the rio then.

We acquired a 5 port 5v ethernet switch. Worked great.

[fsilberberg]

Originally Posted by bdaroz

I'm just hoping that they move to a more standard library distribution / installation method (eg maven).

We actually already do this, and this was available last year. It's documented on ScreenStepsLive here: http://wpilib.screenstepslive.com/s/...aven-artifacts. There will be some updates to artifacts available in 2017, detailed in my design doc here: https://github.com/wpilibsuite/desig...eneration.adoc. The gist of it is that we'll be using real version numbers, and using 2 maven repos instead of 4, one for public releases and one for WPILib developers (although technically, there's nothing stopping you from using it). In fact, GradleRIO (https://github.com/Open-RIO/GradleRIO) already used the repo last year.

[Jaci]

Originally Posted by fsilberberg

[snip] In fact, GradleRIO (https://github.com/Open-RIO/GradleRIO) already used the repo last year.

If you want implementation details, see the WPIProvider class. The first two dependencies (L34-35) are the RoboRIO and desktop versions of NetworkTables (since we do simulation we include the desktop version, but if you're only doing RoboRIO development you dont need this). The next dependency (L37) is WPILib itself (in this case, the Java version). The next 2 dependencies (L39-40) are the source jars for WPILib and Network Tables, which we attach to IDEs like IntelliJ and Eclipse so you can browse the source directly without the inbuilt decompiler.

[Jaci]

I'm a fan of the separation of device libraries. For specifically large libraries (like the CAN motor controllers), the omission of these from the 'standard library' should result in smaller binary sizes and (at least on Java, not sure about C++ just yet), less RAM usage.

For the 'plugin system', I hope that this support comes in the form of compile-time library additions. For C++, I'm hopeful that library providers will include either the source, or both a shared and static version of their native library. For java the plugin system should be fairly trivial assuming JNI is done fine.

I'll try and contact some beta-test teams and keep an eye on the WPI repo to try and get OpenRIO's existing and new libraries up and running for the 2017 season, as unfortunately I don't have access to beta-testing stuff directly.

[bdaroz]

Originally Posted by fsilberberg

We actually already do this, and this was available last year. It's documented on ScreenStepsLive here: http://wpilib.screenstepslive.com/s/...aven-artifacts. There will be some updates to artifacts available in 2017, detailed in my design doc here: https://github.com/wpilibsuite/desig...eneration.adoc. The gist of it is that we'll be using real version numbers, and using 2 maven repos instead of 4, one for public releases and one for WPILib developers (although technically, there's nothing stopping you from using it). In fact, GradleRIO (https://github.com/Open-RIO/GradleRIO) already used the repo last year.

We saw that, however we've sworn off Eclipse this year for IntelliJ Idea for our Java development. The student's weren't quite ready for a Gradle build so the hoops we had to go through to continue to support the ANT build/deploy for 2016 code were a bit much.

    <target name="doInstall" depends="wpilib.check" unless="wpilib.exists">
        <mkdir dir="${wpilib}"/>
        <get src="http://first.wpi.edu/FRC/roborio/release/eclipse/plugins/edu.wpi.first.wpilib.plugins.java_0.1.0.201603020231.jar"
             dest="${wpilib}/plugin.jar"/>
        <unzip src="${wpilib}/plugin.jar" dest="${wpilib}">
            <patternset>
                <include name="resources/java.zip"/>
            </patternset>
            <mapper type="flatten"/>
        </unzip>
        <delete file="${wpilib}/plugin.jar" />
        <unzip src="${wpilib}/java.zip" dest="${wpilib}"/>
        <delete file="${wpilib}/java.zip" />
    </target>

We're hoping for a smoother 2017 code build/deploy cycle that's a bit more platform/IDE independent. (And yes, we're a looking at GradleRIO once we finish our off season. )

[frcguy]

Originally Posted by AllenGregoryIV

Can't you just tether with the USB cable? You can also just add a small network switch to the robot.

+1. We only used one Ethernet port and we still tethered over USB exclusively this season. And if you must tether over Ethernet, you can get an inexpensive switch that will run on 5v.

[Mark McLeod]

The switch doesn't have to be on-board either.
It can just be used in the pit to connect the camera and tether to the bridge.

[bobbysq]

It's good that they disabled the web interface on the FRC firmware. Hopefully the router won't have insane boot times anymore.

(I was really hoping for them to commission an FRC-specific router though, with screw terminals for power and at least 4 ports)

[feverittm]

Looking at the spec at the OpenMesh website it looks like this radio uses 24V. Is this correct? If so we will need a source of regulated 24V to power the radio.

What is others opinions?

[Hitchhiker 42]

I'm slightly disappointed with the radio choice, but the other things sound very good to me. Anyways, yay for improvements.