We use IoT quite a bit in the public sector, especially for things like traffic, weather and parking data, and we’ve been running much of it on our lorawan setup, using node on the actual devices.
I wouldn’t have thought it at first, but JavaScript is turning out to be our most important language for driving IoT, and while I haven’t heard about Johnny-five before, it looks pretty good.
If you're interested in JavaScript and IoT, check out Moddable[1] and their open source SDK/runtime[2] as well. It's by a small group of great engineers who know how to build tiny, performant runtimes.
Gonna have to agree with the others here. My comment wasn't that helpful and I could have expressed my contempt for "Javascript-all-the-things" in a more constructive way.
My understanding of Johnny Five is that it's a way to drive an external board from a "normal" computer. So you aren't putting any execution (or JavaScript) onto the Arduino (or other embedded) controller. Instead you load their premade firmware onto the controller, hook that controller up to your computer via some serial connection, and then the Johnny Five library lets you control everything from the main computer.
It seemed kind of trivial when I first heard about it, but now that I've experimented some with these things it's not that trivial, and it's a reasonable approach. Especially for robotics – an Arduino board isn't a good way to drive a robot (too limited), but it's a good way to drive many (but not all) of the specific components you might want to control. Then the real brain can be a Raspberry Pi or some other proper computer.
My sense is that "devices" you hook up to a computer are themselves entire computers with fancy high-level protocols to control them. Sure the Pi, unlike a normal computer, has its GPIO ports. You can use those to directly control hardware that is not smart (or is only a tiny bit smart). But still you run out of ports really quickly, managing those ports isn't easy, and if you are controlling things that need more power than the GPIO ports can provide then you'll need additional circuitry. You usually need additional circuitry.
The obvious solution is to create higher-level hardware that the Pi can control without, say, pulsing on a regular interval, or without having to provide the full power requirements via GPIO. An Arduino board is a modular way to do exactly that. The Arduino then becomes the "device".
Johnny-Five programs can run on board any SBC that runs Linux and can support Node.js. For those platforms, GPIO and serial bus interfaces are interacted with directly; examples include Raspberry Pi, Intel Edison (+Galileo 1 & 2, Joule), Tessel 2, Linino and pcDuino
The next line of code in JavaScript isn't always going to be executed after the previous line is complete. This is unlike Python, which generally executes each line after the previous line is complete.
Hence all the callbacks, promises, async/awaits patterns to learn in JavaScript..
async/await is pretty easy to use... plus if you want your robot to be able to perform multiple actions at once (i.e. rotate a camera to stay focused on an object while moving) having asynchronous capabilities seems like it would make things easier.
That being said I have zero robotics experience, just a lot of JS experience lol :shrug:
The next line in JS is guaranteed to execute immediately after the preceding one; except in the case of callbacks (including sugar, like promises), which are also executed sequentially, but deferred until they are explicitly called by whatever they're passed to. In fact, one of the biggest complaints about JavaScript (that it can block the main thread if it tries to do too much in one frame) is a consequence of this guarantee.
Granted, I've written primarily JavaScript for the last five years, but it's pretty straightforward to reason about. Any language that lets you respond to events, I/O, etc. is going to require that you reason about things over time - JavaScript is no outlier here.
The way you've written your remark, it sounds as if JavaScript executes lines out of order, or will wait an arbitrary amount of time to move from one line to the next. Obviously, neither of those is true.
You have things backwards. Python has threading, JavaScript does not. Potential breaks in execution are limited and explicit in JavaScript but almost ubiquitous in Python.
Johnny Five doesn't let JavaScript (Node) run on the microcontrollers themselves -- it requires a USB (or serial) link firmware installed in the board.
The program runs on your computer and issues commands to the firmware via the link. This makes the board "tethered" to the PC so to speak.
That said, hooking up a Raspberry PI running node to an Arduino sort of alleviates the "tethered-ness" and I believe it is the lowest effort barrier to entry into robotics and presents endless creative opportunities.
I believe you're incorrect, Johnny five supports both runtime models.
Was playing with Johnny Five yesterday (while they were releasing 1.0, fun to watch), and was deploying my node project code to my Tessel 2, which then ran independently of my laptop.
I was amazed at how easy it was to go from 0 to deployed code running reliably on the (detached, untethered) dev board. At least when working with the Tessel 2, they really think through the dev experience end-to-end.
Make Magazine's Make Controller Kit followed the same model. Unfortunately, it was maintained by one guy during nights and weekends (which meant it was never well supported and became deprecated before it was useful). Still, the model of allowing developers to learn robotics in whatever language they're comfortable in is fantastic for making the field accessible to newcomers!
I tried my hand at an MCK because I could do it from ActionScript, a language I was already comfortable with. Asking users to learn both about controlling hardware and a new programming language/model simultaneously steepens the barrier to entry versus decoupling those things.
This is awesome. I met some of the Johnny-Five devs at Maker Faire a couple years ago, and they were demoing an interesting web-application controlled robot with a camera at the Intel booth. Glad to see that they've finally hit 1.0.
But as the top commenter mentions, still no standalone support on devices like Arduino, which is what prevented me from using it in my projects. (I don't know if it's possible to fit a node runtime onto something as small as an Arduino, anyways)
It’s really too bad people aren’t doing things like this in Lisp. There are so many more tools for building useful abstractions and a rich history of real work in the field to draw upon, performance is very good, and CFFI works great for interfacing with very low level C-callable code. (It didn’t take me long at all to use CFFI to bridge to Intel’s MRAA on the Edison, for example.)
34 comments
[ 3.8 ms ] story [ 59.5 ms ] threadI wouldn’t have thought it at first, but JavaScript is turning out to be our most important language for driving IoT, and while I haven’t heard about Johnny-five before, it looks pretty good.
[1] http://www.moddable.com/ [2] https://github.com/Moddable-OpenSource/moddable
:/
https://news.ycombinator.com/newsguidelines.html
It seemed kind of trivial when I first heard about it, but now that I've experimented some with these things it's not that trivial, and it's a reasonable approach. Especially for robotics – an Arduino board isn't a good way to drive a robot (too limited), but it's a good way to drive many (but not all) of the specific components you might want to control. Then the real brain can be a Raspberry Pi or some other proper computer.
but why use this if Pi has support for sensors and stuff already? (other than, "because I've already bought Arduino")
The obvious solution is to create higher-level hardware that the Pi can control without, say, pulsing on a regular interval, or without having to provide the full power requirements via GPIO. An Arduino board is a modular way to do exactly that. The Arduino then becomes the "device".
Johnny-Five programs can run on board any SBC that runs Linux and can support Node.js. For those platforms, GPIO and serial bus interfaces are interacted with directly; examples include Raspberry Pi, Intel Edison (+Galileo 1 & 2, Joule), Tessel 2, Linino and pcDuino
Hence all the callbacks, promises, async/awaits patterns to learn in JavaScript..
That being said I have zero robotics experience, just a lot of JS experience lol :shrug:
The next line in JS is guaranteed to execute immediately after the preceding one; except in the case of callbacks (including sugar, like promises), which are also executed sequentially, but deferred until they are explicitly called by whatever they're passed to. In fact, one of the biggest complaints about JavaScript (that it can block the main thread if it tries to do too much in one frame) is a consequence of this guarantee.
Granted, I've written primarily JavaScript for the last five years, but it's pretty straightforward to reason about. Any language that lets you respond to events, I/O, etc. is going to require that you reason about things over time - JavaScript is no outlier here.
The way you've written your remark, it sounds as if JavaScript executes lines out of order, or will wait an arbitrary amount of time to move from one line to the next. Obviously, neither of those is true.
The program runs on your computer and issues commands to the firmware via the link. This makes the board "tethered" to the PC so to speak.
That said, hooking up a Raspberry PI running node to an Arduino sort of alleviates the "tethered-ness" and I believe it is the lowest effort barrier to entry into robotics and presents endless creative opportunities.
Was playing with Johnny Five yesterday (while they were releasing 1.0, fun to watch), and was deploying my node project code to my Tessel 2, which then ran independently of my laptop.
I was amazed at how easy it was to go from 0 to deployed code running reliably on the (detached, untethered) dev board. At least when working with the Tessel 2, they really think through the dev experience end-to-end.
[Edit: Tessel, not Tessle]
I tried my hand at an MCK because I could do it from ActionScript, a language I was already comfortable with. Asking users to learn both about controlling hardware and a new programming language/model simultaneously steepens the barrier to entry versus decoupling those things.
For beefier linux boards, like Tessel and Beagle Board, it's what you've described: http://johnny-five.io/platform-support/#beaglebone-black http://johnny-five.io/platform-support/#tessel-2
But as the top commenter mentions, still no standalone support on devices like Arduino, which is what prevented me from using it in my projects. (I don't know if it's possible to fit a node runtime onto something as small as an Arduino, anyways)