RoboRio

[krieck]

For the Java alpha testers, can you tell us what version of Java will be used (6, 7 or 8)?

Also, I'd read somewhere that the roboRIO will use "Java SE Embedded". Can anyone comment on the difference between Embedded Java and the Java SE desktop SDK?

[NotInControl]

Originally Posted by krieck

For the Java alpha testers, can you tell us what version of Java will be used (6, 7 or 8)?

Also, I'd read somewhere that the roboRIO will use "Java SE Embedded". Can anyone comment on the difference between Embedded Java and the Java SE desktop SDK?

We were running Alpha Testing Using JavaSE Embedded, based off of JavaSE 7 (Not sure what Update version at the moment)

I would imagine that WPI would like to stick with Java 7 for 2015 because that is what will be the most tested by that time. However, sticking with 7 is not written in stone, and if they are comfortable enough, they can upgrade to JavaSE Embedded 8.

As for the Differences between JavaSE and JavaSE Embedded. Don't think of it this way because it will be hard to convince yourself you need JavaSEEmbedded. Instead think of it like this: JavaSE Embedded, is the upgrade of Java ME CLDC.

Java SE Embedded derives from JDK, but provides specific features and support for the embedded market on a limited set of supported platforms. The embedded-specific features and support include additional platforms, small footprint JREs (optional files removed), headless configurations, and memory optimizations.


The reality is Java ME CDC and CLDC technology is Oracle's legacy technology that addresses embedded devices that had more than 1MB RAM and 10MB ROM. "Java SE Embedded is a new generation Java Embedded Platform that addresses devices that have [a little more] resources, but also allows them to access the latest APIs and functionality as is present in JavaSE. Truthfully, Java ME and Java SE Embedded address different segments of the embedded market. The Java ME CLDC and CDC offerings are designed for resource-limited devices including cell phones, handsets and media players. The APIs of CLDC and CDC are more limited than Java SE but enable these ME offerings to support devices with small footprints. Java SE Embedded provides the rich functionality of Java SE and is targeted at higher-end embedded devices - generally, those devices with at least 32MB RAM and 11MB - 20MB of ROM for a Linux/ARM platform." - From Oracle.

Hope this helps,
Kevin

[Andrew Schreiber]

Originally Posted by krieck

For the Java alpha testers, can you tell us what version of Java will be used (6, 7 or 8)?

Also, I'd read somewhere that the roboRIO will use "Java SE Embedded". Can anyone comment on the difference between Embedded Java and the Java SE desktop SDK?

From what Omar (CTRE) was telling me at CMP it will be full blown Java 8. This was a shock to me, everything I'd heard was Java 7 up until that point.

[NotInControl]

Originally Posted by Andrew Schreiber

From what Omar (CTRE) was telling me at CMP it will be full blown Java 8. This was a shock to me, everything I'd heard was Java 7 up until that point.

This should not be a shock, and should not be a fear. As I mentioned in my previous post:

Originally Posted by NotInControl

...However, sticking with 7 is not written in stone, and if they are comfortable enough, they can upgrade to JavaSE Embedded 8....

Java SE 8 Embedded was released sometime in March 2014. As Alpha testers we were using JavaSE 7 with latest patch because that was the latest technology available when we started alpha testing (Nov 2013).

Alpha testing was just that, Alpha. If FIRST/NI/WPI chooses to move to 8, we still have 7-8 Months of development time with SE 8. Ultimately it doesn't matter if it is 7 or 8.

There is no huge shift between Java SE Embedded 7 and Java SE Embedded 8 that is cause for concern, so no need for panic. And as an end user just writing code for the target, you don't really gain or loose much with either 7 or 8.

Any upgrade from 7 to 8 will not affect us as the end user for FRC applications.

Regards,
Kevin

[Andrew Schreiber]

Originally Posted by NotInControl

This should not be a shock, and should not be a fear. As I mentioned in my previous post:

I wasn't really scared by it. More excited. After years of being many years (if not decades) behind the times it seems we are finally moving to modern languages where students can learn similar practices on their bots as they would their desktop apps.

Now, if only we could get Ruby to run on these things... (I jest, my day job is ruby and I do a ton of development in it, at this point I think in it and have to translate to other languages)

[Ben Wolsieffer]

I am so glad for the upgrade to a modern version of Java (whether it be 7 or 8), because of the many times I have tried to use any of Java's cool features and been unable to (ex. enumerations, generics).

I hope FIRST will still provide support for Netbeans, because I favor it over Eclipse, but the change really isn't that big a deal (its still the same code).

[jagen31]

Originally Posted by Andrew Schreiber

From what Omar (CTRE) was telling me at CMP it will be full blown Java 8. This was a shock to me, everything I'd heard was Java 7 up until that point.

Yeah I attended a presentation at championships, and the panel there said it was shipping with Java SE 8 in the fall season.

Lambda Expressions anyone?

Also, CAN integration is pretty awesome (even the talons have it now.) Hopefully the roboRIO handles collisions better because when we tried CAN bus, the cRIO would die with a timeout exception (of course that could have been a wiring issue, I suppose.)

Another important thing they mentioned was that the terminating resistor is in the Power Distribution Panel, meaning you have to (well, you don't HAVE to, but its the easiest solution) daisy-chain all the breakout boards between the roboRIO and the PDP.

At least, this is what I've heard. I'm sorry if this is already common knowledge, I just thought it was important.

Also, netbeans support is not being dropped, says Brad Miller.

[Ben Wolsieffer]

Originally Posted by jagen31

Also, netbeans support is not being dropped, says Brad Miller.

That's good. I'm glad to hear that I can still use my favorite IDE.

Will the Talons really have support for CAN next year?

The current hardware doesn't support it AFAIK so will they release a new version? We were considering buying Talons to replace our Jaguars, but since I knew CAN would be easier to implement on the robotRIO end next year, I wanted to try it. I was reluctant to buy Talons because they don't currently have CAN support, but if they will next year then its a win-win for me (smaller size + more reliability + fancy sensor feedback). Do you know if the Talons will support all the potentiometer and encoder feedback the Jaguar does?

Originally Posted by jagen31

At least, this is what I've heard. I'm sorry if this is already common knowledge, I just thought it was important.

Your post was not common knowledge (at least for me) and you made me even more excited about next year.

[jagen31]

Talons will definitely have CAN support. A cross the road electronics employee was there speaking for it.

Because it is CAN I would assume there is a way of getting info from the Talon but I'm not sure.

I do know that the voltage of each PWM output can be retrieved, if that's any help.

[virtuald]

Originally Posted by Andrew Schreiber

Now, if only we could get Ruby to run on these things... (I jest, my day job is ruby and I do a ton of development in it, at this point I think in it and have to translate to other languages)

There's no reason you couldn't run ruby on the cRio, if we can get python working on it I'm sure ruby would work too. I imagine it should be pretty straightforward, especially for the RoboRio.

[jagen31]

The roboRIO, certainly, as it runs linux... But I think that the cRIO running VxWorks might be more troublesome... I haven't seen a port of ruby to run on VxWorks.

If you do get ruby working, don't build a climbing bot because Ruby can't scale.

[virtuald]

Originally Posted by jagen31

The roboRIO, certainly, as it runs linux... But I think that the cRIO running VxWorks might be more troublesome... I haven't seen a port of ruby to run on VxWorks.

And nobody had built a python port for vxWorks until we did it either. It's vaguely POSIX ish, so it would be troublesome, but doable. Probably not worth the effort at this point since it won't be used anymore -- but totally doable. And the SWIG wrappers used by the Lua version of WPILib could be a good starting point too.

If you do get ruby working, don't build a climbing bot because Ruby can't scale.

Nice.

[Thad House]

Since the RoboRio runs arm linux, and they finally recently got Hard Float Mono working, I really want to try and see if running robot code with C# would actually be possible. It would be fun.

[wireties]

Originally Posted by Andrew Schreiber

Yes. The C++ one is also changing from everything I've heard.

I'm sad about Java but welcome the C++ change. Windriver was... well it was special.

C++ and Java using Eclipse was pitched in the sessions upstairs. I did not hear anything about NetBeans. Wind River Workbench is also Eclipse-based though heavily customized. If only our Wind River licenses had included the memory, profile and stethoscope analysis tools...

[wireties]

Originally Posted by jagen31

The roboRIO, certainly, as it runs linux...

The NI guys emphasized over and over again it was REALLY LINUX (their emphasis). I don't know why on earth you would do such a thing but Ruby should be possible.