Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2017 WPILib Update #17

Closed
JamieSinn opened this issue Jan 10, 2017 · 65 comments
Closed

2017 WPILib Update #17

JamieSinn opened this issue Jan 10, 2017 · 65 comments

Comments

@JamieSinn
Copy link

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
Copy link
Author

Coincidentally this is issue 17 - Illuminati confirmed

@19lmyers
Copy link

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
Copy link

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

@JamieSinn
Copy link
Author

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

@JaciBrunning
Copy link
Member

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
Copy link
Author

Thank you for everything Jaci!

@JaciBrunning
Copy link
Member

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)

@JaciBrunning
Copy link
Member

@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
Copy link

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
Copy link

HeroCC commented Jan 11, 2017

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
}

@JaciBrunning
Copy link
Member

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

@cyocom
Copy link

cyocom commented Jan 11, 2017

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
Copy link

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
Copy link

HeroCC commented Jan 11, 2017

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

@chrislo27
Copy link

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

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

@JaciBrunning
Copy link
Member

@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
Copy link

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
Copy link

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

@BenBernardCIS
Copy link

@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
Copy link

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
Copy link

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
Copy link

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

@JaciBrunning
Copy link
Member

JaciBrunning commented Jan 12, 2017

@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
Copy link

BenBernardCIS commented Jan 12, 2017

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
Copy link

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

@JaciBrunning
Copy link
Member

@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
Copy link

BenBernardCIS commented Jan 12, 2017

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
Copy link

@JacisNonsense That solved it for me, thanks!

@BenBernardCIS
Copy link

BenBernardCIS commented Jan 12, 2017

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.

@JaciBrunning
Copy link
Member

@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
Copy link

timtim17 commented Jan 12, 2017

👍 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!

@JaciBrunning
Copy link
Member

JaciBrunning commented Jan 12, 2017 via email

@JaciBrunning
Copy link
Member

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
Copy link

timtim17 commented Jan 12, 2017

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

@JaciBrunning
Copy link
Member

@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
Copy link

Deploy is not working (2017.0.5).

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

@JaciBrunning
Copy link
Member

@chrislo27 remove the space from your project folder

@chrislo27
Copy link

Works now, thank you!

@JaciBrunning
Copy link
Member

@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
Copy link

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
Copy link

timtim17 commented Jan 13, 2017

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
Copy link

timtim17 commented Jan 13, 2017

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
Copy link

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

@JaciBrunning
Copy link
Member

@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
Copy link

timtim17 commented Jan 13, 2017

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

@JaciBrunning
Copy link
Member

@timtim17 try 2017.0.7

@timtim17
Copy link

timtim17 commented Jan 13, 2017

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

Looks like it works pretty well. Thanks!

@JaciBrunning
Copy link
Member

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
Copy link

Ill be at the shop later tonight to test that version

@BenBernardCIS
Copy link

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.

@JaciBrunning
Copy link
Member

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

@chrislo27
Copy link

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.

@JaciBrunning
Copy link
Member

@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
Copy link

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
Copy link

Deploy and test works.

@Masterzach32
Copy link

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

@JaciBrunning
Copy link
Member

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants