2017 WPILib Update

[JamieSinn]

Hey Jaci,

No huge rush, but would you mind updating your repo for the 2017 wpilib updates?

We're currently working off the 2016 version, but we're waiting on the 2017 update for the actual robot code.

Thanks!

PS. I plan to re-write the documentation on how to get started for this year too. I'll probably do it in LaTeX for easier updating and community input.

[JamieSinn]

Coincidentally this is issue 17 - Illuminati confirmed

[19lmyers]

This is somewhat amusing, because I remember that during the 2016 offseason the WPILib repo WA mistakenly returning the 2017 version...

I haven't built a 2017 project yet but shouldn't it be as simple as refreshing the Gradle dependencies?

[P1n3appl3]

Thanks Jamie, coincidentally I just linked my team's new programmers to your guide on setting up GradleRIO with IDEA.

[JamieSinn]

Basically yes @19lmyers - there's a few other minor things like how #16 comes into play, but it's somewhat like that.

[JacisNonsense]

I'm in the process of updating now. Unfortunately it's a lot more difficult than just changing the artifact version, as the native libraries have been decoupled from the jar, and adding support for device libraries like the SRX and NavX libraries. This should be ready soon enough, I'm currently working on getting CTRE's SRX libraries available through maven, and then updating the GradleRIO spec.

For 2017, the GradleRIO plugin location will be moved to the official repository (see #11), and the build system extensions specification will be changed. This is a full rewrite to accomodate future versions much simpler

[JamieSinn]

Thank you for everything Jaci!

[JacisNonsense]

All good. If I have access to an imaged RoboRIO it should be updated by tonight (I need to test deployment, I believe some libraries have changed), if not, tomorrow. This is all going off my timezone (Perth, WA)

[JacisNonsense]

@JamieSinn @19lmyers @P1n3appl3 the repository has been updated. Follow the readme to give it a test and get back to me whether it works or not. If it passes for all of you, I'll push it out as an official release. Please direct any questions to this issue. Closing #16 in favour of this issue

[BenBernardCIS]

Jaci, you're amazing. Thank you for getting to this so quickly! I'll do a test build-and-deploy after work this evening and let you know how it goes.

[HeroCC]

I tried the new version, and I get this error:

12:08:57 PM: Executing external task 'deploy'...

FAILURE: Build failed with an exception.

* Where:
Build file 'C:\...\Robot2017\build.gradle' line: 2

* What went wrong:
An exception occurred applying plugin request [id: 'jaci.openrio.gradle.GradleRIO', version: '2017.0.0']
> Failed to apply plugin [class 'jaci.openrio.gradle.frc.WPIPlugin']
   > Task with name 'build' not found in root project 'Robot2017'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 0.076 secs
Task with name 'build' not found in root project 'Robot2017'.
12:08:57 PM: External task execution finished 'deploy'.

My build.gradle:

plugins {
    id "jaci.openrio.gradle.GradleRIO" version "2017.0.0"
}

apply plugin: 'java'
apply plugin: 'idea'
apply plugin: 'eclipse'

frc {
    robotClass = 'org.usfirst.frc.teamXXXX.Robot'
    team = 'XXXX'
}

def robotManifest = {
    attributes 'Main-Class': 'edu.wpi.first.wpilibj.RobotBase'
    attributes 'Robot-Class': frc.robotClass
}

dependencies {
    compile wpilib()
    compile talonSrx()
}

jar {
    from configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }
    manifest robotManifest
}

[JacisNonsense]

@HeroCC please run with --stacktrace and send me the result, I'll have a look in the morning

[cyocom]

Have you been able to get the wpilibj from the maven repo to work with the 2017 roboRIO?
For me, I had to download the eclipse plugin to grab the jar from ~/wpilib post-eclipse plugin install.

[BenBernardCIS]

I hit the same problem as @HeroCC. Here's my stacktrace:
log.txt

And here's my build.gradle (renamed for github):
build.gradle.txt

Note that I tried it with both plugin syntax variations.

[HeroCC]

OK, here is the stacktrace:
https://hastebin.com/kefowihegu.vbs

[chrislo27]

I'm having the same problem as the others above.

Stacktrace: https://hastebin.com/dovovunuwi.vbs
build.gradle file: https://hastebin.com/ukanutujel.scala

[JacisNonsense]

@cyocom following the example, it should link correctly. This is using the 2017 WPILibJ 'athena' package.

@BenBernardCIS @HeroCC @chrislo27 does the problem persist if you change the top of your build.gradle to the following?

plugins {
    id "java"
    id "eclipse"
    id "idea"
    id "jaci.openrio.gradle.GradleRIO" version "2017.0.1"
}

Note that the version of GradleRIO has been updated to 2017.0.1

[BenBernardCIS]

That takes care of it for me. Thanks!

I do get an error when I try to "Import Project from Gradle" in intellij:
Cause: jaci/openrio/gradle/GradleRIO : Unsupported major.minor version 52.0

That doesn't seem to be a show-stopper though.

For reference by others, here's my updated build.gradle:
build.gradle.txt

[19lmyers]

That's probably because you don't have Java 8 installed.

[BenBernardCIS]

@19lmyers Indeed...I have Java 8 installed, but accidentally selected my Java 7 JVM in the import window. Thanks for pointing that out! It's all set now.

[chrislo27]

The fix worked, thanks so much! Build worked and it got the dependencies, can't deploy tonight because I don't have the roboRIO with me but I'll report back tomorrow when I get a chance to try it.

[BenBernardCIS]

I am having trouble now getting gradleRIO to pull in cscore...all the other dependencies pulled in fine (ntcore, opencv, etc). Do I need to specify it in my build.gradle?

[19lmyers]

Quick question: Is the build.gradle template majorly different from the old (2016) version for a specific reason?

[JacisNonsense]

@BenBernardCIS I'll take a look shortly. Is gradle panicking or is the IDE just not picking them up?

@19lmyers the general gist of things is still the same (frc { team = "5333" } is an alias for frc.team = "5333"). I split up the gradlerio extension into frc and wpi to more easily accomodate for projects that don't directly depend on WPILib, but depend on other projects that package WPILib (toast modules are an example)

A lot of the old build.gradle is no longer needed thanks to the new plugin support in Gradle 3.2, and the plugin has been moved from my personal maven to Gradle's official repository.

The WPILib dependency isn't linked automatically. This is for a few reasons, but most prominently is that which is mentioned above, and allows for the specifications of wpilibVersion and ntcoreVersion to actually work (they didn't in the old stable versions of GradleRIO due to a race between plugin configuration and buildscript evaluation)

This is mostly trying to converge to GradleRIO-C, which has a better backend overall than the previous versions of GradleRIO for Java, which were written poorly. The new version conforms much more tightly to Gradle's internal model

[BenBernardCIS]

Neither the ide nor gradle see the cscore lib.
In the ide, I have all the other libraries listed under External Libraries, but not cscore.
When I run a gradlew build, I get a compile error on the line that imports UsbCamera:
22:02:51.672 [INFO] [org.gradle.api.internal.tasks.compile.JdkJavaCompiler] Compiling with JDK Java compiler API.
22:02:52.562 [ERROR] [system.err] C:\...\Robot.java:4: error: package edu.wpi.cscore does not exist
22:02:52.574 [ERROR] [system.err] import edu.wpi.cscore.UsbCamera;

[19lmyers]

On my end, IntelliJ IDEA is only detecting the 2016 version of the library in its dependencies. Gradle works fine, but the IDE is ignoring the Gradle dependencies...

[JacisNonsense]

@BenBernardCIS I can confirm that cscore isn't being found. I will look into this.

@19lmyers it seems to be working correctly for me. Ensure your build.gradle is close to that in the quickstart, and try running ./gradlew cleanIdea clean build idea --refresh-dependencies --rerun-tasks. This will take a while to complete, so grab a coffee or something

[BenBernardCIS]

I may have found the problem...in WPIPlugin.groovy, the wpilibNative block has opencv and cscore swapped:
project.dependencies.ext.wpilibNative = {
["edu.wpi.first.wpilibj:athena-jni:${project.wpi.wpilibVersion}",
"org.opencv:opencv-jni:${project.wpi.cscoreVersion}:linux-arm",
"edu.wpi.first.wpilib:athena-runtime:${project.wpi.wpilibVersion}@zip",
"edu.wpi.cscore.java:cscore:${project.wpi.cscoreVersion}:athena-uberzip@zip"]
}
Or this could be completely unrelated.

[19lmyers]

@JacisNonsense That solved it for me, thanks!

[BenBernardCIS]

I think the cscoreVersion typo is unrelated. It's probably a problem, but not this problem.

FYI, manually adding cscore.jar to my lib folder (and including compile filetree(...etc...) allowed my build to succeeed, so we're off to the races! Thanks for the help...tomorrow I'll try deploying to our rio.

[JacisNonsense]

@BenBernardCIS Good spotting. Although that was an issue, it didn't cause any issues (both cscoreVersion and opencvVersion are + by default). Further down, however, it has come to my attention that cscore doesn't have a non-classifier jar, so the latest commit should fix this issue. Update to GradleRIO 2017.0.2 and rebuild your workspace with ./gradlew cleanIdea idea and you should see cscore and other libraries linked correctly.

[BenBernardCIS]

Yes, that did the trick for me. Thanks again for the quick responses, and the great tool!

[JacisNonsense]

Before testing deployment, please use version 2017.0.3. It includes fixes for native library deployment

[JacisNonsense]

Make that 2017.0.4 to include the ldconfig calls to avoid a required restart

[timtim17]

I'm having trouble deploying the code to the RIO. The roboRIO is running image version FRC_roboRIO_2017_v8. It looks like robotCommand is trying to run /usr/local/frc/bin/netconsole-host, but after ftp-ing into the RIO it looks like that doesn't exist. I also get a message saying that netconsole-host is not a valid file:

11:07:15.505 PM
/bin/bash: /usr/local/frc/bin/netconsole-host: No such file or directory

Edit: It looks like as part of the ant build script WPI deploys netconsole-host?

    <deploy-libs libs.name="netconsole-host" libs.basedir="${wpilib.ant.dir}" libs.deployDir="/usr/local/frc/bin">
      <libs.local>
        <fileset id="netconsole.local" dir="${wpilib.ant.dir}">
          <include name="netconsole-host"/>
        </fileset>
      </libs.local>
    </deploy-libs>

Should I just copy it via FTP?

[JacisNonsense]

Don't copy it just yet, I'll see if I can automate it. Sit tight

[JacisNonsense]

@timtim17 Pull 2017.0.5 and get back to me, that should fix the netconsole issues

[timtim17]

So, after deploying a basic, Quickstart project, it worked. It looks like after deploying netconsole once, the build fails at the deploy step - the code still works though (stacktrace). However, with a more complex project (navX & talon), Java crashes immediately after teleop is enabled.

 # 
 # A fatal error has been detected by the Java Runtime Environment: 
 # 
 #  SIGSEGV (0xb) at pc=0xb6f314c4, pid=5385, tid=3063166048 
 # 
 # JRE version: Java(TM) SE Embedded Runtime Environment (8.0_06-b23) (build 1.8.0_06-b23) 
 # Java VM: Java HotSpot(TM) Embedded Client VM (25.6-b23 mixed mode linux-arm ) 
 # Problematic frame: 
 # C  [ld-linux.so.3+0x94c4]  _dl_rtld_di_serinfo+0x1e4 
 # 
 # Core dump written. Default location: //core or core.5385 (max size 2048 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again 
 # 
 # An error report file with more information is saved as: 
 # /tmp/hs_err_pid5385.log 
 # 
 # If you would like to submit a bug report, please visit: 
 #   http://bugreport.sun.com/bugreport/crash.jsp 
 # 

There's probably something wrong with the way I imported the navX library, and our build.gradle is a mess anyway since we have a whole bunch of other deploy tasks in there for different systems.

Is there a correct way to add the navX library?

[JacisNonsense]

@timtim17 the if I'm correct in saying that the NavX library doesn't require the JNI, it should be a simple case of putting the following in your dependencies { } block:

dependencies {
    compile wpilib()
    compile talonSrx()
    compile fileTree(dir: "<libs directory>", include: "**/*.jar")
}

[timtim17]

👍 That's what I did. After further testing it looks like only certain methods are failing, and I don't think that's GradleRIO's fault. Other than the deploy "failing" every time after netconsole has been deployed once, it looks good. Thank you!

[JacisNonsense]

Failing each time? I know the build isn't always consistent, but is it always failing after the netconsole deploy?

…

On Thu, 12 Jan 2017, 16:47 Austin Jenchi ***@***.***> wrote: 👍 That's what I did. After further testing it looks like only certain methods are failing, and I don't think that's GradleRIO's fault. Other than the build "failing" every time after netconsole is deployed, it looks good. Thank you! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJyG6L5S_T7UtONOjfHc1JZSsaNE-qkXks5rRei0gaJpZM4LgAOn> .

[JacisNonsense]

I think the issue is that the Java process isn't dieing fast enough. I'll look into it soon. Any logs would help

[timtim17]

Here's a stacktrace (that's my entire stacktrace, from starting the build to deploying it. there is another stacktrace from Gradle about Task.leftShift(), that's irrelevant). My guess is that it just can't sftp netconsole because it already exists. The code still copies fine.

Also, after doing more work on the navX all the methods work when deploying with the WPI plugin, so it looks like it may actually be a GradleRIO issue. However, I'm not quite sure why they wouldn't work. (Core dump) Edit: For some reason, adding a random line into robotInit() (SmartDashboard.putNumber(Double.MAX_VALUE) to be precise) fixed the problem...?

[JacisNonsense]

@timtim17 with the deploy issue, I'm assuming this is because netconsole itself isn't being killed before the deploy. I will take a look into this tomorrow

As for the java issue, my only observation is an issue with Network Tables. I believe the WPILib plugins and GradleRIO are using the same library versions, so I'm not exactly sure what is going on.

[chrislo27]

Deploy is not working (2017.0.5).

Stacktrace: https://hastebin.com/asomileqeq.vbs

[JacisNonsense]

@chrislo27 remove the space from your project folder

[chrislo27]

Works now, thank you!

[JacisNonsense]

@chrislo27 @BenBernardCIS are you guys receiving the same sort of error as @timtim17 when the code is running on the RoboRIO? If possible, I want to determine whether this is a common issue. @timtim17 would you mind linking your code repo?

[Masterzach32]

I believe I am receiving the same error as @timtim17
stacktrace: https://hastebin.com/udezinijov.bash
build.gradle: https://hastebin.com/izadurimuz.cs
Hope these can help!

[timtim17]

Our repo is here. It is a little messy, particularly in the build.gradle file - we have a whole bunch of tasks for a deploy/build system we somewhat started last year, including what appears to be a secondary, unrelated deployRelease task. Those don't appear to matter; I've commented them out before and still seen the same issues.

Edit: If you're referring to the Java/ntcore issue, I'm not sure if that's related to GradleRIO. Although it had to do with the deployed .so files, it fixed itself somehow by adding another random SmartDashboard.putNumber() (specifically putting Double.MAX_VALUE). It may just be an issue with this specific RIO...? However, I don't have access to another RIO right now to confirm it.

[timtim17]

Also, regarding the Java/ntcore issue, I removed my "magic, nonsensical" line of code that fixed things earlier, and it appears that after deploying, running code that puts values on SmartDashboard causes a crash. However, once the code reboots, it works fine, even after a reboot. However, if I put a SmartDashboard call in robotInit(), it works first time. However, even with that call in robotInit(), SmartDashboard code in an init method (I tested 'autonomousInit()`) crashes (but just for the first time) anyway.

At this point, I'm just confused. It doesn't really make sense why it would crash only if certain things are in certain places. However, I do know that the same navX code (without the SmartDashboard calls) works fine when deployed in Eclipse with the WPI plugin.

[BenBernardCIS]

@JacisNonsense Our deploy went smoothly first try (we updated to 2017.0.5 first) and I haven't heard any reports of runtime issues--we're testing on our Stronghold bot and driving seems normal. I'll ask the team to keep an eye on the logs, but so far so good.

[JacisNonsense]

@Masterzach32 @timtim17 can you run deploy using the 2017.0.6 version? I believe this fixes the netconsole-host issue during deployment. I am still working on a fix for the JVM crash

[timtim17]

@JacisNonsense Tried the 2017.0.6 version. No more "build failed" message, but the robot code doesn't start automatically. When the code is deployed, the driver station shows robot code, but then after netconsole-host is deployed, the robot code doesn't start again, and the DS shows "No Robot Code".

Edit: It looks like it doesn't start if you reboot the RIO either.

[JacisNonsense]

@timtim17 try 2017.0.7

[timtim17]

👍 Looks like 2017.0.7 somehow fixed both the deploy issue and the NetworkTables JVM crash!

Looks like it works pretty well. Thanks!

[JacisNonsense]

Ahh, neato. Looks like netconsole must have had a lock on something from NetworkTables.

@Masterzach32 @BenBernardCIS can you confirm 2017.0.7 fixes your issues? If so I'll increment to 2017.1.0 and do a full release

[Masterzach32]

Ill be at the shop later tonight to test that version

[BenBernardCIS]

Our programmers report that 2017.0.7 worked fine for them. No issues with build, deploy, startup, and running. This includes our camera code using cscore, our dashboard/networktables usage, and our NavX code. All-clear from us.

[JacisNonsense]

@BenBernardCIS that's fantastic news. I'll do some more house-cleaning commits in the morning and do a full release

[chrislo27]

I will be able to test code in about one and a half hours. If you want to release 2017.1.0 before then, that's fine but I could test 2017.0.7 as well if you'd like.

[JacisNonsense]

@chrislo27 I'm about to head out to bed, it's quite late over here. Run the tests and post a reply here and I'll take a look in the morning

[Masterzach32]

It works now, but deploying seems to push the same libraries on each deploy to the robot, causing deploys to take up to 10 minutes, which is kinda annoying. Any fix to check whether the deps are already on the rio, or can i implement something like that myself?

[chrislo27]

Deploy and test works.

[Masterzach32]

Nvm about what I said earlier. Deploy and test work perfectly.

[JacisNonsense]

@Masterzach32 that will only happen on library updates / first deploy. GradleRIO stores a checksum to ensure this doesn't happen every single deploy.

Thanks for your help everyone, you've been integral to making sure GradleRIO is stable for 2017