[FRC Blog] Control System Update

[ollien]

Originally Posted by Bkeeneykid

Since this is the upgraded model of the OM5P-AN, does this come with any upgraded stats like improved range or more throughput (not like that second one matters to FRC, but just curious)?

Or, hopefully, faster bootup/a better power connector? A boy can dream.

[SoftwareBug2.0]

Originally Posted by ollien

Not psyched about the WPILib changes, but it is what it is. I understand the sentiment behind it, but CANJaguar and CANTalon just seem like two hugely integral classes to remove.

What's done is done, I guess. I suppose I'm more not psyched to be debugging build path errors than anything. (Though, in theory, and not reality, those shouldn't happen.)

Perfection is less about effort or skill than it is about having a clear and limited goals. If this is a sign that the WPIlib authors are looking to reduce scope then I'm happy because it means that their efforts can be more focused on fixing their existing problems. If it turns out instead that they've taken this as a chance to implement some crazy plugin architecture I will be less pleased.

[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.

[calcmogul]

Originally Posted by SoftwareBug2.0

If this is a sign that the WPIlib authors are looking to reduce scope then I'm happy because it means that their efforts can be more focused on fixing their existing problems. If it turns out instead that they've taken this as a chance to implement some crazy plugin architecture I will be less pleased.

The CAN motor controllers are a big maintenance burden for us. At least in C++, the CANTalon code is 5.5k lines of code spread over two classes (we use a PIMPL pattern). Half of this is a class we can't touch since it comes directly from CTRE, but we have to maintain testing infrastructure for it. Moving CANTalon out of WPILib gives CTRE more control over testing/QA and gives them more freedom to add features / do bugfix releases independent of the WPILib release schedule.

CANJaguar is basically a giant, ugly, 10k-line ball of code that we are hesitant to touch. Few teams use it, so we can't justify cleaning it up, and teams still use it, so we can't just drop support. We're supporting it for 2017 as a third party library, but we're probably going to stop maintenance in 2018.

[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.

[maxnz]

Originally Posted by Bkeeneykid

It looks like the AC has better throughput, both ports are now gigabit, upgraded processor and DRAM (faster boot times? ), but at the cost of reduced range. I think we might prefer our AN over the AC just because of the range.

Out of curiosity, how do the old d-links compare to the new radios in terms of range?

[marshall]

Originally Posted by ollien

Not psyched about the WPILib changes, but it is what it is. I understand the sentiment behind it, but CANJaguar and CANTalon just seem like two hugely integral classes to remove.

What's done is done, I guess. I suppose I'm more not psyched to be debugging build path errors than anything. (Though, in theory, and not reality, those shouldn't happen.)

I think it is probably a good change given that we've seen it take quite a while to get new features into WPILib from when a manufacturer introduces them. As a LabVIEW beta team, it always seem to take a while before we could be using the latest features.

That being said, I'm worried a bit that some vendors are going to prefer developing in one language over another and therefore some teams aren't going to get access to the latest code/firmware/features because of it. I hope this doesn't happen but it is a possibility with moving the development and maintenance to 3rd parties.

[bobbysq]

Originally Posted by ollien

Or, hopefully, faster bootup/a better power connector? A boy can dream.

I agree. The attached picture is using the power cable included in the kit of parts.

[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. )

[adciv]

Originally Posted by marshall

I think it is probably a good change given that we've seen it take quite a while to get new features into WPILib from when a manufacturer introduces them. As a LabVIEW beta team, it always seem to take a while before we could be using the latest features.

That being said, I'm worried a bit that some vendors are going to prefer developing in one language over another and therefore some teams aren't going to get access to the latest code/firmware/features because of it. I hope this doesn't happen but it is a possibility with moving the development and maintenance to 3rd parties.

Labview has the capability of importing C libraries (Call Library Function Node) and C code (LabWindows). That would make it easier in some respects.

[Chris is me]

Originally Posted by frcguy

+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.

The big problem is that the USB spec limits the length of most USB cables to shorter lengths than Ethernet. Ethernet is designed to be used over longer distances than USB. In practice you're probably fine either way, but Ethernet is what we "should" be using IMO

[bobbysq]

Originally Posted by Chris is me

The big problem is that the USB spec limits the length of most USB cables to shorter lengths than Ethernet. Ethernet is designed to be used over longer distances than USB. In practice you're probably fine either way, but Ethernet is what we "should" be using IMO

Also, I don't believe you get full access to the robot's LAN when using USB. This is important if you used vision tracking with an external processor like us this year.

[frcguy]

Originally Posted by Chris is me

The big problem is that the USB spec limits the length of most USB cables to shorter lengths than Ethernet. Ethernet is designed to be used over longer distances than USB. In practice you're probably fine either way, but Ethernet is what we "should" be using IMO

Yep, I agree that Ethernet is the ideal tethering method. For us however, tethering was limited to just testing things in either our pit or in queue, and we didn't need the longer distance that Ethernet can handle. If we needed to test on the practice field or some other long distance tether we had a long Ethernet cable ready.

Originally Posted by bobbysq

Also, I don't believe you get full access to the robot's LAN when using USB. This is important if you used vision tracking with an external processor like us this year.

This is correct as well, although we didn't have issues with that this season (low goal robot ).

[adciv]

Originally Posted by frcguy

This is correct as well, although we didn't have issues with that this season (low goal robot ).

We were too...we still used vision in Auto. So nice to have a target right above your goal.