"Java, Sun SPOT and the FIRST Robotics Competition"

[davidalln]

I'm excited to dive into Java as an alternative after a subpar experience with LabVIEW this year. I do have a few questions about how much of the more advanced/third party Java solutions we can use that will still be executable on the cRIO. Unfortunately, I didn't get a chance to drop in and say hi to the people from Sun at the competition over the weekend.

For example, can we use Java-based wrappers and implementations for other languages such as JRuby (my guess is yes, because Java is compiled into bytecode anyways, so whatever third-party libraries used should be compiled with it)? And will there be the ability to use a testing framework such as JUnit (with the emulator, it might be possible. I'd just rather not have to build and load every time I need to test out a small tweak or new feature, especially in the process of developing said feature)?

[j_johnson]

Originally Posted by davidalln

I'm excited to dive into Java as an alternative after a subpar experience with LabVIEW this year. I do have a few questions about how much of the more advanced/third party Java solutions we can use that will still be executable on the cRIO. Unfortunately, I didn't get a chance to drop in and say hi to the people from Sun at the competition over the weekend.

For example, can we use Java-based wrappers and implementations for other languages such as JRuby (my guess is yes, because Java is compiled into bytecode anyways, so whatever third-party libraries used should be compiled with it)? And will there be the ability to use a testing framework such as JUnit (with the emulator, it might be possible. I'd just rather not have to build and load every time I need to test out a small tweak or new feature, especially in the process of developing said feature)?

I got a chance to talk to several of the people at the Java booth at Atlanta and learned quite a bit about the setup. It will use the Squawk JVM running on top of the vxWorks OS. The WPILib should be ported over to Java. (It looked like they had most if not all of it ported already) This VM is Java Eicro Edition (Java ME), which is what runs on phones, smart cards, etc. Any third party libraries would need to be compiled down to the Java ME byte code, limiting them to using only the Java ME API, rather than the Java Standard Edition API.

The build system uses nant, and they will have plugins for the NetBeans IDE and maybe the Eclipse IDE as well. (As a side note, it was probably not a good idea to ask the father of the Java language why they are using a Sun IDE rather than one developed by IBM.)

The cRio will basically be formatted for c++ with the initial program being a bootstrapper to start the JVM. It sounded like this initial JVM will then listen for communication with the development PC and start a second VM with the robot code in it. Hopefully this means that it will be much easier to reprogram and test without the 30 second start up time.

All of this, of course, was in pre beta and could very easily change before it is released.

[Greg McKaskle]

Originally Posted by j_johnson

I it will be much easier to reprogram and test without the 30 second start up time.

This has been mentioned a few times. Can you elaborate on what the 30 second sequence is, and when it becomes a big part of the development cycle?

One mentor came by the booth and wasn't aware of the three button reboot, so they were power cycling the entire robot each time they deployed. Is this a similar situation? Or are you unable to simply reboot the controller? Or is your controller taking 30 seconds to reboot?

Greg McKaskle

[Bomberofdoom]

Hang on, let me get this straight....

Is Labview still available to teams to program the robot?

Is it that Java is replacing Labview or we're just gonna' have a 3rd programming language available?

[davidalln]

Originally Posted by Bomberofdoom

Hang on, let me get this straight....

Is Labview still available to teams to program the robot?

Is it that Java is replacing Labview or we're just gonna' have a 3rd programming language available?

I believe Java is another option for teams, along with LabVIEW and C++.

[EricVanWyk]

Originally Posted by davidalln

I believe Java is another option for teams, along with LabVIEW and C++.

Correct. They are adding an option, not replacing them.

However, at one of the feedback sessions they did mention considering dropping C (not C++, just C) support: Only one team reported using it, and they were planning to move away from it any way.

[Dave Flowerday]

It'll be interesting to see what happens here since Sun is now being bought out:
http://www.pcworld.com/article/16340...n_for_74b.html

Whenever a new owner comes in, a lot of old projects within a company being bought out can get axed rather suddenly. Hopefully this isn't one of them.

[JesseK]

Heh, the cRIO is getting complicated . So long as the other two languages aren't glitched by adding another one in, I see this as an opportunity for other teams. We'll stick with the C++ core with a Java display on the front-end. That hits all of the strong points on our team.

I can't wait to have the "But there are no memory leaks in Java!" discussion...just wait, it will happen.

[Boydean]

What I want to know, is whether this is going to open the door a little be more for other platforms to program on.(aka mac os, linux, ??solaris??).

None the less, this looks like an exciting thing to come out to the world of FRC.

[Dave Flowerday]

Originally Posted by Boydean

What I want to know, is whether this is going to open the door a little be more for other platforms to program on.(aka mac os, linux, ??solaris??).

Sun was demoing the new tools on all 3 of those platforms at the Championship, so it appears the answer is Yes.
{edit} Sorry, I meant these 3 platforms: Windows, OS X, and Linux. I assume they figured that very few robot people would be interested in using it on Solaris, but I'm sure they could make that work too. {/edit}

[Alan Anderson]

Originally Posted by Greg McKaskle

This has been mentioned a few times. Can you elaborate on what the 30 second sequence is, and when it becomes a big part of the development cycle?...Or is your controller taking 30 seconds to reboot?

It takes longer than 30 seconds, sometimes as long as 45 seconds, between clicking the "click here to reboot" button after setting the code to run at startup and having the battery voltage display on the DS screen. It was consistently 27 seconds from "three-button reboot" to responsive robot. That's a huge increase from the two to five seconds it takes to start up and begin controlling last year's system after loading a new program.

Don't even get me started on the ridiculous amount of time it takes to build a LabVIEW program this year.

[byteit101]

you can reboot by pressing the reset button on the crio. the programmers on our team have a rebooting tool, a small philips screwdriver that fits perfectly in the button. it's faster than the complete power cycle, and as fast (if not faster) as Reset target server (or whatever it is called, using WR)

[Adam Y.]

Originally Posted by Alan Anderson

Don't even get me started on the ridiculous amount of time it takes to build a LabVIEW program this year.

Just wait until you get acess to the FPGA. Whatever definition of ridiculous you are using pales in comparison to hardware synthesis.