![]() |
Javascript Robots!
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... |
Re: Javascript Robots!
And I thought this was going to be #teamjavascript
Oh thank you Kamen. |
Re: Javascript Robots!
It wouldn't be that hard if you built it on top of Java's Nashorn interpreter. Summer project?
|
Re: Javascript Robots!
Quote:
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. |
Re: Javascript Robots!
It's not entirely implausible, we built our own version of java script to use in autonomous coding.
|
Interesting. Ill definitely look into the HAL interfacing, since Node is extremely capable.
|
Re: Javascript Robots!
By all means, go for it, but I wouldn't use it.
From: http://nodeguide.com/convincing_the_boss.html Quote:
|
Re: Javascript Robots!
Quote:
|
Re: Javascript Robots!
Quote:
|
Re: Javascript Robots!
Quote:
I'd be willing to help out, I write Node/JS every day (in addition to Java/Objective-C), the event'ed/streams Javascript model could be really useful for robot programing. |
Quote:
Yeah, I'm not concerned with Garbage Collection. It actually really helped with Recycle Rush this year (sorry :) .) Excellent John, I'd probably set this up as a collaboration-able repo, so I'll definitely contact you if this gets started. EDIT: Nobody caught the pun? :D |
Re: Javascript Robots!
Quote:
|
Re: Javascript Robots!
Quote:
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. |
Re: Javascript Robots!
Quote:
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. |
Re: Javascript Robots!
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...).
|
Re: Javascript Robots!
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) |
Re: Javascript Robots!
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):
Have an intuitive software design
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! |
Re: Javascript Robots!
Quote:
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? |
Re: Javascript Robots!
Quote:
Code:
talon.set(1)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. |
Re: Javascript Robots!
Quote:
|
Re: Javascript Robots!
Quote:
Code:
robot.elevatorMotor = robot.pwm.port3Code:
robot.elevatorMotor = HAL.getMotor(3) |
Re: Javascript Robots!
Quote:
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. |
Re: Javascript Robots!
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? |
Re: Javascript Robots!
Quote:
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! |
Re: Javascript Robots!
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. |
Re: Javascript Robots!
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 |
| All times are GMT -5. The time now is 23:02. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi