After a solid night of hacking, I’ve managed to port Mozilla’s Rhino Javascript Engine(http://www.mozilla.org/rhino/) over from a half baked J2ME implementation(http://sourceforge.net/projects/rhinoj2mecldc/) to the 2010 FRC Java system–squawk VM etc.
I’ll post the code shortly, but some notable features
Running the rhino js engine allows you direct access to Java libraries and classes as well as Javascript code.
Javascript is fully interpreted in rhino(if someone wants to work on a JIT compiled V8 implementation, let me know ;)), but any Java calls will have equal performance to a normal java setup because they go straight to the JVM.
My implementation of rhino utilizes a socket on the cRIO, allowing users an interactive console with the cRIO as code is executed.
What does this mean for FRC? Well to put this in perspective–
Using this system, you can write as much of your code as you please in javascript(the benefits and conveniences of which are many) and still utilize the robot control libraries that are part of the new WPILibJ.
Using this system you can have an interactive console to your robot, and have code interpreted on the fly–that’s right, no deploy, no compile.
[If you are nuts, you can replace your driverstation joysticks with a keyboard and a pair of competent coders, and drive your robot with code :P]
You can easily toy with code as it runs on the robot.
You can teach and learn javascript with your team members, which is in many ways friendlier than Java while maintaining an un-weird syntax.
And much more…
Oh cool. We can save money on joysticks this year to pay for registration. After all, who uses joysticks these days. We play games with a keyboard and mouse. Maybe we’ll do that this year.
Oh cool. We can save money on joysticks this year to pay for registration. After all, who uses joysticks these days. We play games with a keyboard and mouse. Maybe we’ll do that this year.
Just keep in mind, the driverstation only passes joystick data.
Just try to plug a mouse or keyboard into the bluebox DS and it gives weird results.
Your mileage may vary.
Actually, I’ve written a shell/pair of shells that bypass the driverstation issue–
one exploits the ability of the cRIO to open ServerSockets via javaME’s Generic Connection Foundation, so i can pull up a socket on whatever port i like, and either telnet to it or write a proper client app.
The other shell is incomplete, but handles Stdin via an open and undocumented UDP port on the cRIO, passing keystrokes directly to the device. Personally I like the serversocket approach a lot more.
@bronxbomber92: I haven’t played with Rhino’s AOT compilation system yet, and I know it doesnt have a JIT compiler… so no idea.
On a side note, I’m running into some really nasty hitches in the Java-Javascript wrapper/classloader system, that I believe are the product of the crappy j2me rhino implementation i’m using.
If I cant hack the wrapper system together, I may be forced to switch to a full Java 5 SE version of rhino and will probably retroweave it to work with J2ME. Still that will take a little more work… If anybody knows stuff about this and would like to help out it’d be great. Its eating my hours right now, and I have work.
This is the last hurdle before WPILibJ works fully. If this can be thrown together in a week then it could be released to coincide with the FRC Java release, which would be amazing. 4 Languages for FRC
pm me if you are interested or post here. I can put up a repo &c, although if you are not a beta tester/[hacker] you will have to test your stuff in the SunSPOT environment. Nbd, just no WPILibJ for u!
Please bear in mind that using “undocumented ports” or “bypassing XYZ” run a good chance of only working at home. The at home network is intended to be as open as possible, to allow you the best possible prototyping environment. The at competition network is intended to guarantee good communication to all 6 robots, and may therefore deny some things.
If your communication does not adhere to the specified protocol, you will not have a leg to stand on should it suddenly be blocked.
As I recall, last year, anything except the standard DS UDP transmissions were firewalled. Some teams built tunneling protocols to sneak video data through, but this would be much more complicated for what you’re proposing.
On the other hand, Java…script? I think my brain just exploded.
Stdin is now being integrated into FRC Java images, so no more undocumentedness.
Also, I’m working on getting the Java5 version of rhino ported, because it is possible to run Java 5 stuff in J2ME – see sun’s playsim project presentation for a hint.
The major limitation with all of these dynamic languages is that java me doesnt allow for dynamic class loading.
Honestly if we want either of these to proceed, we should go back to stuff like v8 and the original python interpreter, written in C, and compile them for PPC.
