"Java, Sun SPOT and the FIRST Robotics Competition"

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

[Kingofl337]

After speaking with a number of teams, many do not know about the 3 finger reboot. Also, some of those that did know didn't know that if it doesn't display "Robot Rebooting" on the driver station screen that robot didn't reboot.

[AustinSchuh]

Originally Posted by virtuald

Now if they would just get rid of vxWorks and let us use Linux on there we'd be really set...

I run linux every day on my laptop and every other computer I own and use, but I wouldn't want to use it on a robot if I had the choice to use VxWorks or some other real realtime OS. The robot needs to be realtime to be guaranteed to respond quickly to user and sensor input, and Linux is not designed to do that. It's designed to run on servers and desktops where a bit of latency isn't an issue. There are patches that have been made to make the linux kernel more real time, but they aren't nearly as good as running an actual realtime OS.

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

[virtuald]

Originally Posted by AustinSchuh

The robot needs to be realtime to be guaranteed to respond quickly to user and sensor input, and Linux is not designed to do that.

So I don't know if you've noticed this or not, but how much realtime stuff did most people's code actually do this year? Answer: most probably did almost nothing. What about interrupts? Nothing again.

Thats what the FPGA is for, it takes care of the nasty latency dependent stuff for us (among other things).

It's designed to run on servers and desktops where a bit of latency isn't an issue. There are patches that have been made to make the linux kernel more real time, but they aren't nearly as good as running an actual realtime OS.

I won't disagree, but I don't think the realtime stuff is a huge issue for what most people are doing. If there were no FPGA, then I'd definitely agree. Otherwise... hard to say.

From the experience I've had so far, porting software to vxWorks is really annoying (even nix-like software) because it has random oddities in its networking library (and other libraries too). The biggest advantage I see for linux would be that theres a *ton* of software that would pretty much *just work* without too much modification. Not so with vxWorks.

Then we wouldn't be just talking about java bots, we could have python bots or ruby bots...

[AustinSchuh]

Originally Posted by virtuald

So I don't know if you've noticed this or not, but how much realtime stuff did most people's code actually do this year?

Correct me if I'm wrong, but I believe that updating the speeds of the motors on the robot 50 times a second while processing images using the rest of the CPU time would qualify. When I've tried to get code I've written under Linux to execute a loop 50 times a second without the timing being off by a fairly large percentage while using all of the available CPU resources, I've had trouble and found the best way to get the loop to execute every 20 ms is to use less CPU resources. Maybe I was doing it wrong, but that's been my experience.

[virtuald]

Originally Posted by AustinSchuh

Correct me if I'm wrong, but I believe that updating the speeds of the motors on the robot 50 times a second while processing images using the rest of the CPU time would qualify. When I've tried to get code I've written under Linux to execute a loop 50 times a second without the timing being off by a fairly large percentage while using all of the available CPU resources, I've had trouble and found the best way to get the loop to execute every 20 ms is to use less CPU resources. Maybe I was doing it wrong, but that's been my experience.

You're right, obviously linux and vxWorks have different design goals. Probably would be a bit better if you were running in the kernel like we do on the cRio or if it were a realtime patched kernel, but hard to say -- I've no experience with realtime Linux.

In any case, I value the flexibility quite a bit more than I value the realtimeness. Cmon, a robot controlled by a shell script... would be pretty amusing.