Importing SDK .jar

[dc74089]

Hi all!

In preparation for the 2014 season, I was looking to put together a Java program for the team's 2013 robot to see if a LeapMotion would be an acceptable way to control the robot on the field, although maybe for the peripheral driver, not the drive train driver, but I digress. Using netbeans, the code I've written checks out just fine, as I've added the Leap Motion SDK .jar to the project imports, but when I try to build the code, I run into an error with all Leap-related classes and methods. I poked around and easily enough found out that adding the SDK .jar to the IDE wasn't enough, so I moved it into the SunSpot lib folder. This got me passed the class undefined errors, but now it's running into some "preverification" error, which is way out of the scope of what I know.

I'm using NetBeans extending SimpleRobot

Error message is here http://pastebin.com/DrS7qCX2 , LeapTasks is a class called in the tele-op code, and LeapTasks also extends Listener, which is a class from the Leap Motion SDK that listens for new frama data. PM me if you'd like to see the full code.

Have any other teams tried to use any control devices which required SDKs in the form of .jar's, or does anyone with experience with Java know how to get past the preverification error?

Many thanks in advance!

[BigJ]

Until next year, we are still running on a version of Java ME (which I believe is similar to Java 1.4). Unfortunately many modern libraries will not be supported by our VM. I don't know if that is exactly the problem, but I would wager a guess that a library provided for something as "new" as the leap motion is not going to work in your robot code.

However (and I have no real idea of how to do this), if you could somehow get your driver station computer to turn the leap motion inputs into a form that the computer recognizes as a joystick device, you could potentially use it that way

[dc74089]

Yes, there is software for the device to turn it into a Logitech gamepad, but, if at all possible, I'd like to do it natively, all within the code, just because the piece of software that does that is... limiting for what I had in mind. And not free! Thanks nonetheless, I wouldn't have thought of that myself!

[Joe Ross]

Originally Posted by dc74089

In preparation for the 2014 season, I was looking to put together a Java program for the team's 2013 robot to see if a LeapMotion would be an acceptable way to control the robot on the field, although maybe for the peripheral driver, not the drive train driver, but I digress.

Where would the LeapMotion Controller be located? On the robot or at the driver station?

Originally Posted by BigJ

However (and I have no real idea of how to do this), if you could somehow get your driver station computer to turn the leap motion inputs into a form that the computer recognizes as a joystick device, you could potentially use it that way

It doesn't even need to make it look like a joystick. It just needs to send the data over the network using either Network Tables or one of the approved ports (TCP, since the squawk JVM doesn't support UDP).

Originally Posted by BigJ

Until next year, we are still running on a version of Java ME (which I believe is similar to Java 1.4). Unfortunately many modern libraries will not be supported by our VM.

It's worse then that, it's somewhere between 1.2 and 1.3.

Another option (if you really need it on the robot) would be to compile the C++ SDK for the cRIO and then call that using JNA.

[dc74089]

Originally Posted by Joe Ross

Where would the LeapMotion Controller be located? On the robot or at the driver station?

Apologies for clarity, I'd be using my hands to control the robot at the driver station. And the SDK does a lot of processing, it can give me hand locations, vectors that show where fingers are pointed, characteristics of how the palm is curved, all functionalities that I really dont want to give up. Or maybe I'm misunderstanding your reply, I'd consider myself moderately versed in FRC java, but not much past that. :0)

[dc74089]

Quick fix, not sure if it'll work when I have a robot to deploy to, but I changed the failonerror in the preverify.xml referenced by the build xml from true to false. This fixes the problem, the code builds okay, but I'm not exactly sure what I turned off, despite searching the documentation for Ant. Does this throw up any red flags for anyone, I'd hate to brick our cRIO...

<exec executable="@{preverify.executable}" failonerror="true">

[BigJ]

You're just telling it not to stop when it hits an error The error will still exist and the code likely not work.

[dc74089]

Originally Posted by BigJ

You're just telling it not to stop when it hits an error

Oh... From what I've seen on preverification, it looks to me like I need to preverify the SDK .jar? I'm poking around with that now.

[RufflesRidge]

It's unclear what you are trying to accomplish by loading the library into the cRIO code. The device will be connected to the computer and the code will be on the cRIO so how will the two communicate?

It sounds like you want to create a Java dashboard or other program to run on the DS and pass messages over something like UDP or Network Tables to the cRIO to use as control signals.