Javascript Robots!

[Arhowk]

I'm down as well (I was actually planning to do JavaScript this season but the teams member count was really low so I had no time).

Stuff that would need to be done
1) WPILib for JavaScript
2) JavaScript interpreter for the roborio (Java has on built in, there are some good cpp ones available)
3) sample projects
4) code development tool, preferably cross platform (recommended javafx or Qt)
5) rio tools (flasher If necessary, code dashboard, JavaScript rio interface)
6) code deployment tool
7) debugging tools
8) (optional) Js native interface tools (for running hard vision processing loops, sensor feedback loops, etc)

I'd be interested in learning Qt if there were enough other people to support the rest of the project (else I'd do something simple like a ftp server attached to sublime)

[michaelwm]

This was a small side project for me this year, and i'm finishing it during this offseason. Some useful things we learned that anyone interested in using javascript for their robot:

Don't use Java 8 / Nashorn (their built in JS interpreter):

• The initial build of Java 8 installed on the roboRIO does not include Nashorn (or any JS interpreter for that matter). See here.
• It grows exponentially slow. Just printing "hello world!" executes fine. The more code we added, the slower it's execution time got. Any function (releasing a cylinder, driving a motor) took upwards of 5 seconds to execute.

Have an intuitive software design

• We based our JS design off of the DOM webdesign convention. Driving a motor in JS is as simple as

  robot.talon.port3.set(1);

  (Subject to change as we refine our programming model)
• Aside from being interpreted in real time, JS is the most common language taught in high school programming courses. If you ever want new programmers, an intuitive design based on what students already know (DOM) will attract new programmers like crazy.

Our team is using the Google v8 JS engine (the same engine powering node), and we have had major success. We will be releasing the source soon, but I personally would love some competition!

[Arhowk]

Any function (releasing a cylinder, driving a motor) took upwards of 5 seconds to execute

O.O

How exactly are you doing this...? Assuming you're just throwing the talons inside of a SimpleBinding, 5 seconds is absolutely monstrous. Are you doing something wierd like interfacing with the HAL layer directly from JavaScript?

[michaelwm]

Originally Posted by Arhowk

O.O

How exactly are you doing this...? Assuming you're just throwing the talons inside of a SimpleBinding, 5 seconds is absolutely monstrous. Are you doing something wierd like interfacing with the HAL layer directly from JavaScript?

Not at all actually, we were passing the Talon, Solenoid, and other classes directly to the scripts as variables, and the scripts simply called their methods (i.e. Talon.set(n). The problem is with the amount of scripts / the length of scripts. If your program had just a single script that said

talon.set(1)

, it would execute fine (but is entirely useless). The more scripts and the longer the scripts are, the longer it took for the interpreter to parse them, and call their methods, thus the 5 second execution time.

We're switching to v8 because it utilizes JIT compilation. We are using the roboRIO's file system to store scripts, and the program compiles them at startup (during queue, for example), and never touches them again, unless our development mode is active. In this case, an external file watcher on the development machine watches for changes to javascript files, and when it detects one, sends the changes to the roboRIO, which stores the new file on the File System, and recompiles it. This minimizes execution time to instantaneous during competition (as no compilation is done during a match because no development is active), and much shorter times than the current java/c++ compilation times for WPI/eclipse.

[JesseK]

Originally Posted by michaelwm

Have an intuitive software design

• We based our JS design off of the DOM webdesign convention. Driving a motor in JS is as simple as

  robot.talon.port3.set(1);

  (Subject to change as we refine our programming model)
• Aside from being interpreted in real time, JS is the most common language taught in high school programming courses. If you ever want new programmers, an intuitive design based on what students already know (DOM) will attract new programmers like crazy.

If you're talking about intuitive design, Talon's don't have 3 ports - PWMs do. It'd get particularly sticky if you had to do Talon SR vs SRX vs SP. I'd recommend doing robot.pwm.port3.set(1), then at instantiation determine what port 3 actually is and make sure that object has a set() method.

[Arhowk]

Originally Posted by JesseK

If you're talking about intuitive design, Talon's don't have 3 ports - PWMs do. It'd get particularly sticky if you had to do Talon SR vs SRX vs SP. I'd recommend doing robot.pwm.port3.set(1), then at instantiation determine what port 3 actually is and make sure that object has a set() method.

I don't know if the roboRIO does this but I know you couldn't with the sidecar because jaguars and talons/victors took different PWM wavelengths. The most intuitive would be something like this

robot.elevatorMotor = robot.pwm.port3

or, if you have to

robot.elevatorMotor = HAL.getMotor(3)

[virtuald]

Originally Posted by Arhowk

I don't know if the roboRIO does this but I know you couldn't with the sidecar because jaguars and talons/victors took different PWM wavelengths. The most intuitive would be something like this

robot.elevatorMotor = robot.pwm.port3

or, if you have to

robot.elevatorMotor = HAL.getMotor(3)

Correct, there isn't a way for the program to determine which type of PWM device is attached to it, so if you were to use this notation then the user would need to provide some declarative configuration that indicates what device is at which port.

The robot.pwm.* or robot.port* notation is interesting, but it's probably mostly useful for retrieving objects, instead of actively using them that way. Consider 'robot.arm_motor.set()' vs 'robot.pwm.port2.set()' -- if you ever change what port your arm motor is attached to, then you'll have to change it everywhere in code if you use the second notation everywhere.

However, it could be a more useful way to create these objects. Maybe something like robot.pwm.port2.createTalon('arm_motor') automatically creates a robot.arm_motor attribute.

[bthlx]

Hi all, I just saw this thread and got super excited.
I've been wanting a JS alternative since I started doing FRC 3 years ago.
I was thinking it'd be fairly straightforward to implement RobotJS as a node add-on, but going with the v8 engine directly may be better. I was thinking it would be nice to use the built nide modules like fs if necessary so that was my attraction to the add-on route.
As far as syntax, couldn't you do something like:

var wpilib = require('wpilib');

var robot = new wpilib.IterativeRobot();

...

robot.liftMotor=new wpilib.Talon(1);

which is a very nodejs idiom.

Thoughts?

[michaelwm]

Originally Posted by bthlx

Hi all, I just saw this thread and got super excited.
I've been wanting a JS alternative since I started doing FRC 3 years ago.
I was thinking it'd be fairly straightforward to implement RobotJS as a node add-on, but going with the v8 engine directly may be better. I was thinking it would be nice to use the built nide modules like fs if necessary so that was my attraction to the add-on route.
As far as syntax, couldn't you do something like:

var wpilib = require('wpilib');

var robot = new wpilib.IterativeRobot();

...

robot.liftMotor=new wpilib.Talon(1);

which is a very nodejs idiom.

Thoughts?

There are 2 way's to go about this problem, a solution similar to Node, and a solution similar to DOM. Whichever way you choose, it shouldn't matter at all performance wise. We chose DOM, because the majority of new programmers are very familiar with DOM. If your programming team is more familiar with Node / classic programming markup, then your method is definitely better.

The great thing about using v8 directly instead of Node is that you get to choose your syntax and the way your programming team scripts it's robot. Go nuts!

[duane]

Resurrecting an old thread.

Did anything come of this project? I'd be interested in helping or taking a look at how it turned out.

[Jaci]

Toast has support for the Oracle Nashorn JS engine, which integrates directly with the JVM. https://github.com/Open-RIO/ToastAPI

You can write your robot program in .js files and we provide some common hooks to things like motors, logging and other stuff