Javascript Robots!

[weaversam8]

I develop full stack Node.JS professionally, and I've seen the power in Javascript. Would anyone be open to building a collaborative framework for the RoboRIO to code in Javascript?

Seems rather promising to me...

[g_sawchuk]

And I thought this was going to be #teamjavascript
Oh thank you Kamen.

[nickbrickmaster]

It wouldn't be that hard if you built it on top of Java's Nashorn interpreter. Summer project?

[virtuald]

Originally Posted by weaversam8

I develop full stack Node.JS professionally, and I've seen the power in Javascript. Would anyone be open to building a collaborative framework for the RoboRIO to code in Javascript?

Seems rather promising to me...

I've definitely considered doing it, and would love to see someone do it.

RobotPy (the python port) is pure python this year, only interfacing to the robot at the HAL layer. If you're going to do this, I would highly recommend going that route instead of trying to write bindings for WPILib. Expect to spend 2 months of effort translating WPILib into Javascript if you want to do a full port. We did C++-based bindings for a number of years, but having everything be pure python (or js) means you can run the actual robot code on your laptop, which is great for testing + simulation.

There's a lot you can learn by looking at how RobotPy is implemented -- and if you implement HAL the same way we did, then you can use our HTML/JS simulator interface (not quite ready, but almost there)!

If you want to write a robot dashboard in HTML/JS, we've got that covered.

[Jacob4564]

It's not entirely implausible, we built our own version of java script to use in autonomous coding.

[weaversam8]

Interesting. Ill definitely look into the HAL interfacing, since Node is extremely capable.

[connor.worley]

By all means, go for it, but I wouldn't use it.

From: http://nodeguide.com/convincing_the_boss.html

But please be careful here, since JavaScript is a dynamic / garbage collected language, your response times may sometimes vary depending on how often and long the garbage collection kicks in (at which point your program is stopped). So don't try to build hard realtime systems in node, that require consistent response times. Erlang is probably a better choice for these kinds of applications.

[virtuald]

Originally Posted by connor.worley

By all means, go for it, but I wouldn't use it.

From: http://nodeguide.com/convincing_the_boss.html

Python has similar issues, and it works just fine for what most FRC teams create. Java has potentially similar GC issues.

[AlexanderTheOK]

Originally Posted by virtuald

Python has similar issues, and it works just fine for what most FRC teams create. Java has potentially similar GC issues.

That explains the 250ms lag spikes I've been seeing every once in a while. Any standard way to mitigate this?

[Bryan Herbst]

Originally Posted by AlexanderTheOK

That explains the 250ms lag spikes I've been seeing every once in a while. Any standard way to mitigate this?

Memory management is complicated, so there isn't really a silver bullet you can apply to make it better. To minimize garbage collection, you need to understand why things get garbage collected and why things don't get garbage collected.

Garbage collection generally occurs when Java decides it needs more memory for new allocations. Objects that are no longer referenced are eligible to be collected.

If you feel as though the garbage collector is running too often, it is likely because you are allocating too many objects too frequently. For example, if you have a loop that creates a new instance of an object in every iteration, those objects can pile up quickly.

[SoftwareBug2.0]

Originally Posted by AlexanderTheOK

That explains the 250ms lag spikes I've been seeing every once in a while. Any standard way to mitigate this?

1) Use a language implementation whose runtime doesn't do garbage collection (this may or may not exist for your language of choice)
2) Use a specially-tuned "low latency" garbage collector implementation (you probably need to test that it actually works properly for your application's usage pattern though)
3) Avoid heap allocation (to the extent that you can - just running the required libraries may produce a considerable amount of garbage, you'd need to check this)

You might also consider manually triggering a collection frequently so that less work is done each time it runs. For example, you could have it so that every time the robot got a packet from the driver station it would run an iteration of the control code and then do a GC. You would have to see how long the pause is to see if that would be acceptable.

[gixxy]

I AM GAME! I would love to run a Node.js application on the roboRIO and use our DriverStation.js (Node-Webkit) DS with it. (once we get the 2015 protocol unearthed...).

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