 Let me get you the YouTube link. I have her laptop. Yeah, you'll have to email it to me. OK. Hey, people, this is our first time doing this, so we are still working out some kinks. But hello, I'm here with Rick Waldron, and you can hear Jory first. Jory's going to be tweeting the YouTube link, where you can see this. And if you're watching this now, then you're watching this now, right, on our Google Plus page. So yay. Hi, Rick. Hi. Hi. We're washing the slate clean of all the technical difficulties we just had. And let's talk robots. Yay, robots. Go. Go. So yeah, you've been doing crazy things with robots, but you've been doing it with Arduino stuff. And yes, there it is. When I was up there over the summer, I had never seen one of these before, understood what it was. So maybe you drew a really cool picture, but maybe you can sort of explain what this even is. Well, actually, for the viewers at home, we could probably throw a link to that picture after the broadcast. So basically, this is the Arduino Uno revision 3, you could tell, because it says so on the back, also because the back is white. Anyway, what this is is an open source piece of hardware. It's a microcontroller here, and USB connectivity with 5-volt power, and a variety of delightful little pins to allow you to literally plug and play. And when I say play, I mean play with robots. Traditionally, you would program this guy with the Arduino API, which is basically some C++ code. Those are called sketches, Arduino sketches, and you would plug them into the Arduino IDE, compile it, and push it up to your Arduino Uno. And magic will hopefully happen if everything is worked all right for you. So that's cool. That puts a hardware programming into the hands of the average Jane or average Joe. It doesn't matter who you are. Now you can program interesting gadgets and gizmos. You have to know C. Right, but you have to know C. It's actually C++. It does support the whole range of C++ functionality. Anyway, but you still have to learn how to do that. So I don't want to do that. I mean, I can write C, I can read C, and I just don't really want to. Folks at home probably are not going to hear like, yeah, I don't want to either. So about a year and a half now ago, I happened to bump into Chris Williams' project notes here at the port. And I was like, what is this? So I went to a microsenter in Cambridge, and I got an Arduino kit, and I was like, I'm going to make all kinds of awesome stuff. This is where I'm going to be a mad scientist. And I went home and promptly failed hard. Didn't do anything at all. Over a couple of weeks and a lot of annoying Chris and nagging him on IRC for help, I finally got the first demo ever made with that it's still in the repo for node serial or it's a light dependent resistor. You put your hand over the resistor, and you can see the output at a, let's just like a Rappel session running in the terminal. That's a Rappel, using big words. Read, execute, print, loop. So that means from the command line you can. Meet your command line. Where you input, execute, and print in a loop. Standard I know. Good work. I know what a Rappel is, yeah. I don't know if I could have like come up with the word said that. I'm sorry, that wasn't supposed to be like trivia. That's okay. I am. People at home are like, oh. Rappel. So, that was not that exciting. And I quickly lost interest. I was actually busy with some, with projects here about who, but part of the problem that I lost interest was is it required me to write an Arduino sketch that I had to compile and upload and put onto this guy in memory. And that was written in, actually I think that was like before they had full C++ support. Maybe? Anyway, it was horrible and I was like, I don't want to have to write a different program for handling like input and output, serialized input and output from a node program for every single thing I want to do. And I briefly looked at this thing called, I saw it as called Formata, it looked terrifying and I walked away, I ran away. Anyway, so I put everything on the shelf, it collected dust for about a year and then I had renewed interest after seeing what Ken Peterson was doing with the Arduino project and I started contributing to that. And then I just wanted to go much bigger and that's when I came across Julian Gaultier who had actually done a JavaScript implementation of that scary Formata thing, it's a communication protocol. So now these pieces were coming together so that is my anecdotal version of what the hell is an Arduino and why the hell are we here? So how do you, probably most of the people watching this write JavaScript or maybe they know C maybe not or C++, I discovered that yes, I can read but I don't ever want to write it either. Well, I've been trying to find my way through this Arduino stuff and hey, how do you talk to, like, we're all used to writing like document create element or to like dollar sign and get some elements and do something with them. How do you talk to, like, what are you sending to this board? So for, I'll try to give like a brief explanation of Serial's parallel and how to communicate. So parallel, you have was this eight pins of back and forth which allows you to do parallel input. However, USB is not parallel, USB is Serial, but USB is like light speed Serial which means that only a lot, Serial means there's only one thing at a time can go in and out but what you do is you create a system of start byte and stop byte message packets. So that's what basically Formata is doing is it's packaging up commands with data, wrapping it end to end with a start system, exclusive message byte and a stop and then it's sending it to serial port which is node serial port which is then breaking that down to like, just to like a byte string and sending it down the line to this guy, the USB. So this guy gets like, just gets a whole bunch of ones and zeros in the program on that board figures out how to send those ones and zeros to the different pins which are connected to different things. Right, so there's a like a partner program for Formata that you, it's like a one time deal and you compile it and upload it to the board and all that does is it takes care of the business of receiving information, essentially unpackaging it and then just distributing it out to the pins and vice versa if there's, you know, I don't know, like some sensor or whatever and it's piping information through one of the pins which wants to send to the client. This just takes the job of wrapping that up and sending it to the client. So all this is really doing is this a glorified sensor device in terms of what we're doing with it. So when node serial port gets it, once again it's like, I recognize your start byte and your stop byte and everything in between I'm going to pass off to Formata and Formata is like, ha, I know what you wanna do and it's, so node serial port is a stream so it sends it's streaming all of its data events to Formata and then Formata is basically acting as like a switchboard operator, more or less. Yeah. Which brings me to our project which is this API layer that sits on top and so Rebecca was saying like in the browser we're used to, you know, document create element or whatever which in itself is a horrible API. Forget about that for a moment. Now imagine if you could construct an instance object that represented a board or an LED. Of course, that'd be fantastic because then I could have prototype methods that I could just call on the board or on the LED like I could tell the LED to blink or I could tell it to blink repeatedly right? Are you gonna show us this right now? Yeah. Of course I am, so. This is actually a cool project. So this is really satisfying because it just works all the time. It actually even works without an LED because it's using N13 which is the default board LED. So just to clarify, what's about to happen is I'm about to run, I have another laptop in front of me over here. We're about to run a node program. It's written entirely in JavaScript that is essentially sending, it's a loop. It's sending a set of information. It's just a byte stream to this board. It's telling it turn this on and off. It's just on, off, on, off with a time delay. So. Hi Steve, blinking LED. It looks really kind of trippy on the, on the, there you go. What? Yeah. Well that's cool but it's really just a blinking LED. But that's, but it's like you said when you were first telling me about all this, like when you're used to just making the steps show up on screens and you make something happen in the real world. Yeah. It's pretty cool. It's amazing. So like blinking LED, I think of as that's the first time you wrote the jQuery code to show and hide something on mouse over. Great. And you were like. Oh my God. Like you cut. Oh my God. Then you get that same exhilarating feeling the first time you make a thing in the real world. Later. Well, for example, you could make a thing in the real world move at like your command. By that, I'm going to tell you that you can make. You've been waiting for that moment. You know. That moment when you press that button. Absolutely. You could even tell them to stop before they run over your other keyboard or reverse. I mean, so remember we were talking about REPL earlier. I'm actually patrolling this little guy from a REPL session on this other. And you really, like you've written the code to make it so that you're really just saying like little guy back, little guy forward. Right. What I've typed was just bot.fwd, which is an alias for forward. And it's just a function call and it goes forward. I can give it a speed if I want, but if I go too fast, I'll just run it like that. I can't type fast enough to keep up with it. And what's the thing that we saw like going back in like scan? They're close up for those of you at home. In case anybody's wondering, this is actually is the robot that I built to propose to my girlfriend. This robot's grippers held the ring box. And I used a compass to determine where to stop and pay attention to my girlfriend. But what they're just asking me about is this right here that's moving around. So this is actually an ultrasonic sonar sensor. And basically what it's doing is it's detecting I don't know if you can hear that. The threads think it's near something. Thinks it ran into something. So this is actually capable of navigating its way around a room and not crashing into things based on how it manages to deal with, in this case, seeing my hand in front of it. And it's like, oh, I better back up. I'm on the wall. I either have to back up or I have to turn. And it does a number of different maneuvers that I've ended up programming based on where it's actually, like if it's closer to center, it does a stop, back up, and then turn. If it's, if it sees something far to the left or far to the right, it'll just turn in the opposite direction. Just a couple of different fun things to optimize it. But the most fun thing about this, and I hope Max Ogden is out there somewhere because I hope Harry, you can tell me the credit of this, is the most fun thing about this is JavaScript is fun. So Node is fun. And this whole thing was programmed in JavaScript and is running as a Node program on the Node.js platform. I haven't written any C++ code since starting this project since I moved over to using the Formata protocol there because I no longer have to worry about handling what goes on on the board. It's just a kind of like a dumb terminal almost. The brain is now in my laptop, in my MacBook Pro, right? It's in a Node program that's running on the command line. So that's like, that's really exciting because that solves the, I don't wanna write Fubar language or whatever. And some people have mentioned like, well those languages and platforms have, you know, long and glorious legacies. Also would like to remind them that they have long and inglorious lines of code. Not to say that we could program Mars rovers but that Mars rover has a lot of code and it runs on the VxWorks platform. And I'm pretty sure most of the things that we're doing today, it's just reading input and analyzing the value of the input and reacting to it. And it's a stream so we can attach data events to it so we can make things that have some sort of logical sense so like a compass can, when a compass turns, right? We can have an event that's called heading change and then have that have a property that is like a summary of the current bearing that's, yeah, what is so much, what I think like how far different and far removed is that from whatever it is that the, you know, curiosity itself is doing on the surface of Mars. I don't think it's that far off. It's certainly far off as far as maturity goes and I'll be the first to admit that this is like a five month old project. You're not ready to go to Mars? What's that? You're not ready to go to Mars? Not ready to go to Mars, not quite yet. You can drive that across town though, that one very, very slowly. Very slowly. Very slowly as long as there were no cars. So I'm gonna let Rebecca talk for a minute because I've been talking too much. I'd actually like to harken back to a time when we didn't have support for a few things in the Johnny Five project that are kind of super important. Primarily, shift register, which I'm gonna let Rebecca explain. But before she got to that, she dove right in to her and Andreas Hagstra. They kind of co-wrote together the whole LCD API and support. They wrote the support for having an LCD constructor and the entire API around that. But there was nothing there and the two of them were just like common bearded and they did an amazing job. But it also led to other new breakthroughs such as the shift register. So I'm gonna let Rebecca take over and tell her version of that story because it is her story, Rebecca. Tell us about LCDs. LCDs. I don't even know. I don't know how it happened that I ended up writing or helping to write the LCD API. It was just like, one of the things that's been really fun about this is like, so I got, Rick suggested I get the SparkFun Inventors kit to get started. And it has a bunch of built-in, not built-in, but it comes with a bunch of sensors like a light sensor and a little bendy sensor and a touch sensor and a bunch of different sensors and LEDs and a motor and some servos and stuff. But, and maybe it's just because I make websites. I really wanted to be able to use the Arduino to show words, which seems kind of dumb, but that was really fascinating to me to show output of some sort. Because like, I know it's not very fun to write a node program that makes there be output on your screen. Or at least there's nothing like that felt kind of dumb to write a node program that made there be output on my screen via the, I don't know. That wasn't that exciting to me. So that's kind of how I got interested in making an LCD work. And also because I think, if I recall, Rick was like, yeah, LCDs won't work because of blah, blah, blah. There was some thing that you were like, oh, they won't work because of such and such. And so that was sort of like, oh, I'll see about that. With the serial, the serial, for sure. Yeah, it was like some kind, what it was was actually, and I may have misunderstood Rick, but what I heard was this won't work. And it was really that some kinds of LCDs won't work, but this kind will. But then we had to write the code to actually make it work. But one of the fun things about this is like, you know, you learn about all these sensors that come with the inventors kit and then you start to go shopping for, shopping, yeah, Rick and I actually went on a shopping field trip last time I was up in Boston. But yeah, so you get to go shopping and they learn about all these things that you could buy and some of them are 50 cents and some of them are $50. And some of them are way more than that. But LCDs were really intriguing to me. So, you know, Andreas actually did, he did the hard part, which was. Proved that it can be done. He proved it can be done and he wrote code that did it sort of. And once he wrote code that did it sort of, because I had been playing with shift registers and learning, and we'll talk about shift registers in a minute, but because I had been playing with shift registers and learning about binary operations and JavaScript, I was able to see, like, look at his code and be like, I know how to make this work. Like, it just, the light bulb goes off in my head of like, I know how to make this work, I know how to make this good. You know, he was passing around strings of zeros and ones and splitting them and doing all this stuff and it was very, it was very much a working prototype. Like, it worked and he could get letters to show up on the screen, which was super exciting. And then I was able to take that and actually work with it. I read the C code and discovered that I could read C and read it, read the API that the liquid crystal library that is available and just sort of started courting it and making it better in some places because it's bad. Like, all of the C++ code is in varying states of goodness. That's it. That's the generous way to say it. Some of it's really terrible and you have to kind of, I learned quickly that if it felt dirty, it probably was. It wasn't just that I didn't, went away for a minute. I don't know why I went away. It wasn't just that I didn't understand it. It was that it was wrong or dumb and I could make it better. And sometimes it was like, you could make it better because you had jobs and so you could do smarter things than you could do and see as far as time out. And this sorts of things. Anyway, so that was the LCD and that was really, really fun. And then I went back, so I mentioned that the whole way that I was able to realize what that was was because I didn't play with shift registers. And shift registers, so Rick was holding up the board and you could see on the board that Rick was holding up that there are, as it turns out, there's what, like 16? Not even, there's like 13 useful pins. And some of them are only, there's a subset that you can use for certain things. So there aren't a lot of pins. So what a shift register lets you do is rather than needing, say, eight pins to control eight LEDs, which is what you would normally need. With a shift register, you can use three pins to control those eight LEDs. So you can, it's basically a tiny chip that stores in memory eight bits. And so you tell it, I'm going to send you a message. You send it a bit and then say, hey, I just sent you a bit. You send it a bit and then say, hey, I just sent you a bit. And when you're done sending the bits, you say, okay, now I'm done sending you the message. And then it shifts those eight bits that you just sent out to the eight pins. And so shift registers are really, really useful when you want to control a lot of things with as few pins as possible. Three is about as low as you can get. So I have a little, I am not nearly as prepared as Rick was, but I have a little thing that I wrote. And you can sort of see, no, you totally can't see, there's way too many wires. So here, this little black box is the shift register. This little black box here, and there's a diagram on mine that we can show you. It's a lot better. And as you can see, there's a whole lot of wires connected to that little black box. And they're hooked up to this little seven segment display over here that is showing the number seven right now. And you can see too that there's just three, besides the power wires, there's just three wires going from the shift register here, the green, yellow, and orange wires are going from the Arduino done to the shift register. Then this white wire is just going to go into an LED just for fun, as we'll see in a minute. So those three wires, could you explain the clock latch and data? I can't remember which one is the which. So I think that you cycle the latch to, oh, I'm gonna get this wrong. You cycle the latch to say I'm about to send you data. You send data and you clock in the data. Yes? I think so. I'll have to double check myself. I have to look at it. People are like, God, these stupid JavaScript photos. Yeah, these stupid, I know. On the one hand, I feel dumb because I can't tell you the clock, latch, and data pins. And I still have to look at a diagram until they get the shift register wired up correctly and remember which one's pin zero and which one's pin one and all that. So on the one hand, I feel dumb about that. On the other hand, the beautiful thing about Johnny Five is that I don't have to remember any of this. I can just say, hey, send this data. And it just sends the data. Like that's why I wrote the shift register API is so that I would never have to think about any of this ever again. And so now the answers to Rick's question are in the shift register API. Oh, so you were right, by the way. Oh, is that it? Yeah, yeah, yeah. So I wanna run my node program which does not make anything move. But so you can see this will count down. So if you ever need to make a timer for some nefarious purpose, Johnny Five, and then light blinks to tell you you got to the end of the timer. So this is, each of these segments in this display, I loosened one of the wires and now the middle one isn't working. Each of the segments in this display is its own LED. And so if you didn't have a shift register, you would need to have eight of the pins on your Arduino connected, I'm sorry, seven pins on your Arduino connected to those seven LEDs. And you couldn't really do a whole lot more with your Arduino after that because like if you wanna have a motor, that's two, that's three pins. If you wanna have a servo, that's three pins. And so you quickly run out of pins. So shift registers are really cool because they let you get around that. And they're also really cool because they make you learn about binary. So that's what I'm actually sending to this is if I want all of the segments on, then I send it 255, which is eight, each of the eight bits is set to one. That's actually a lie because this is a common cathode. I can't remember which one this is, but actually I send a bunch of zeros to turn them on, but that's just the detail that I should have left out. Anyway, I send the number 255 and that turns on all eight bits. I send the number 128 and that turns on just the first bit. So it just turns on one segment. I send 128, or I send 192 and that turns on the first two bits. So that turns on two segments. So that's the other fun thing about this is I'm using JavaScript for stuff I never would have used it for. And so I'm having to learn things I never would have had to learn before. That's been fun. We can pop the stack back to a point we made very early years. Traditionally as web developers, like how often do you have to like shift bits around to append nodes to the document, not that often at all. Probably never, ever. Of course, there are millions of use cases, but this is like the use case. Actual hardware communication programming is where hardware doesn't know much more than electrical pulse on and off. Right, and it's been, what's been really neat has been thinking about, now that I know this, thinking about when I could use it to set a configuration in the browser. You know, when I now have this new tool that I didn't have before that I can use to solve problems in the browser that I just never would have thought of before. Rick's gonna show another robot, I can tell. I was just getting ready to sort of. We still have to talk about the JavaScript parts of this too, so, but this is a good time for a robot interlude. Robot interlude. Oh, right, interlude. This one was fun. This was like one of my first adventures in the land of moving away from wheels to legs. So this is actually like a pretty common, like beginner project. It's like a four leg, two servo bug, essentially. Like this is, I didn't invent this. This is, I mean, essentially the hardware is not that interesting, but what is interesting is programming it with JavaScript. So there's actually a funny story. I was at home visiting my parents and the legs on this used to be much steeper. And I was showing my dad's, I had left work and driven straight home with all of my gear piled in the car and I was showing my dad the thing. I was like, I can't figure out how to make it to walk forward. It dances in place, but which you'll know that that's actually a recurring theme of my leg robots that I've been working on. So it was just dancing in place and I couldn't figure out why. And my dad said, well, you know, lower the base of the legs. I was like, oh, all right, well I'll humor you because I know for a fact that you've never built robots before, but sure, why not? I've got no better ideas. That's just totally right. Right then and there, I just bent, it's all it is, is a metal hanger. So I just bent the legs, made them flatter. Now it walks. It looks like I like this one. You say it's funny, but it doesn't do much more than that. It was really like, I wanted the challenge. I wanted, you know, wheels are cool, right? Really, there's not much separate to this from the wheel, the tank wheel robot earlier. They're actually both powered by two servos. Tank wheels are continuous servos, which mean that they, you send them basically a current level. In the case of Johnny five, I've made it all degrees, you know, zero through 360, that's actually not true, but it's in the documentation, but that's for continuous servos. It's actually 90 is stopped. 91 is the slowest in one direction and 89 is the slowest in another direction and just keep branching out from there. So that's how you make it go forward or backwards. This is just two regular standard servos that are going from something like 40 degrees to 140 degrees, and they're just ticking back and forth at a regular interval, which is when you have the legs bent a certain way, we'll propel it forward. We'll propel it forward. So let's talk about the sad fact of the tail that that robot had, the USB cord. And I don't think of it as sad. It's just an early developmental obstacle. It's a leash because it's still. Yes. And we're actually dolphins. I made that up. That's not real science. So currently Firmata was designed by, I believe by a couple of the developers that actually work on Arduino. And their whole plan was like, how cool would it be if we could turn the board into essentially like a dumb terminal, like a sensor like just an endpoint for putting sensors in and plugging things in and doing stuff and be able to write programs and their examples were Python, Java, Ruby, you know, on the client. So they developed Firmata, which was based on the MIDI protocol, MIDI communication protocol. And then they did that and then they stopped doing that. And really, really basic. And it's right now, unfortunately, it doesn't know how to give up control over the two communication slots, which are zero and one, which are Rx and Tx, receive and transmit, respectively. So in order to go wireless, shed tail, you know, get rid of our wisdom teeth. We don't need our pinnix anymore. To shed these things, we need, for wireless, we need to be able to essentially plug in and like overtake those two pins. And unfortunately, that requires a particular software package that's written in C++ called, it turns a serial line into a software serial port. And it basically allows you to control traffic to the actual serial line. Unfortunately, we don't yet have support for that, but this is something that like by the end of this year, I absolutely hope that we have, because once we shed this, we'll be able to have, we can build, we can build quadcopters. Yeah, exactly. Well, Felix's quadcopter, which is actually controlled over HTTP, which is really fantastic. People should check that out. He got the AR drone quadcopter and it is an HTTP connection to it. It's a totally different protocol than what we're using for Johnny Five. But in reality, he's just sending like packaged byte streams. No different than what we are. It's just a completely different protocol from the ground up. And it's not unfortunately not at all compatible with Arduino or with Johnny Five. It's significantly more expensive. However, once we have wireless capabilities and built into Formata, in which essentially what it needs to do is Formata needs to know, needs to be able to accept an instruction to initialize a new software based serial port and stream data to it and read data from it. And also be able to remember the original line that it had as well so that it's not held up by USB but can be programmed via USB removed and then it can still communicate over wireless when you even get like a shield that just sits on top of it, takes over two pins and then you have another receiver part. So yeah, we just had someone ask in the chat if it would work with wireless shield and you're saying not yet because it won't give up those zero and it won't listen to the zero and one pins yet. It just doesn't know that it's there. Right. You know what to do with it yet. Right, it's just another. The person in the chat is welcome to help us. Are you opening a source reframe? No, I'm like, I stand by it. I'm not even saying it as a, I'm not even trying to be all hand wavy like what does that have contributors to it? But no, seriously, come help us out. That would be awesome. I want contributions. I want people to help. Right now the only person working on the Firmata site is Julian and he's a human being with a wife and a job and also real world responsibility so he can only do so much and I'm sure that he's always open to having other people pitch in as well but it would just be a matter of modifying the actual Firmata protocol itself because you would need to reserve a bite for that particular command and then of course like another pride. I think it's like three bites total you would have to reserve for different commands. Like one, open a port, two, read, three, write. So help us out. But yeah, that's how we can get rid of the tail but I don't even mind the tail that much. I like the tail because I want to set, we had someone try to steal my scooter and I want to set up some elaborate thing outside that will shine a laser at them the next time they try to steal my scooter and think that something bad's about to happen to them. You could, let's be resourceful, if you have an old laptop, you could set it up near a window and wire it near a window. I could, then they might steal the laptop, like this is the, they're like, oh, I can handle them stealing the Arduino board because they're like 25 bucks, what, right? But stealing a laptop would be a little sad. And then use my Chromebook. And then they use the scooter to drive away and then it's back. So we've been talking for a while, I want to talk about the JavaScript side of this because that's the other really cool thing and one of the things, again, that you said to me when we were talking about this, is that you get to use, as web developers, we're always like, oh, we'll never get to use those features for another five years until IE gets around to supporting them and we don't have to support old IEs. But you get to use some really neat features via six. So talk a little bit about that. Well, actually only one. Only one, but it's awesome. So it exists in the sense that if you ran Johnny Five programs with the Harmony flags switched on, in Node, you'd get a real weak map. Otherwise, you'd get a shimmed weak map. What a weak map does is it lets you use an object as a key. So instead of just traditional JavaScript hashes, objects, dictionaries, whatever the hell you want to call it, people have a million different names, they're actually just object objects, to be honest with you. Anyway, they're limited to strings as keys. Even if you give it a number internally, the way the semantics of keys of an object are dealt with, they're always strings. So with a weak map, what you can do is you construct a new weak map and then what you do is you call set on it and its first argument is the key and second argument is arbitrary data of some object or some sort. But the first key can be any kind of object, right? So what I've done to support real private state, now say yourself like, oh, private state, that's not really a real thing in JavaScript. Yes it is, actually. And this was the first time, reading this code was the first time that I was like, oh, that's what they're for. Yeah, so here's how it works. I use weak maps and object-defined properties to create actual accessors. But I use the weak map every instance of every single thing that gets created. If it needs some form of state maintained, which is just about any one of the sensors, anything that is an input device will have a data stream, of course. So we don't want to feed that straight to an instance property because that will let end user just cave over it or whatever and you can't set a property that isn't yours to set. So I had to figure out a way to avoid that. So we actually send all input data into a weak map and you basically use the instance when it's constructed, the constructor itself sets up a new entry in a weak map that's actually in the module code, right? It says this and then it's just some object literal declaration that has some relevant keys in it. And then later, when I want to access that data, without ever putting it directly on the instance at all, so it's not like throwing an underscore in front of the, at the beginning of the name and being like, oh, it's private, don't touch it. It's got a friggin' underscore. Whoa! I'm actually locking it away in the weak map and when I need to access it, say, from inside the accessors that are being defined, I just call it up by going, you know, weakmap.getthis and that returns that arbitrary piece of data that's been stored in the weak map. This also means that I can access it from any of the prototype methods. So generally, you think to yourself, like, that's the reason why you end up having all these crazy, like, closeover patterns or you probably, like me, in the past, resorted to having to put everything on the instance. Now, because inside the prototype method, I have access to this, and it's the correct this that I need, I can just dip into the weak map with this as the key and get out that private state. Whatever its current value is, I can react to that and turn switches and pull knobs in the programmatic sense and then update that state by setting it back into the weak map and move on. So now you actually have this sort of, like, floating piece of scope almost. It's like, holds on to information. It's like having a credit system, private data. It's just real private data. It's like a bank account for the instance. Now, you can do the same thing with map. So there are ES6 collections, there's map set, weak map. You can do the same thing with map as far as using objects as keys. However, weak maps are superior for this because if your key goes away, it also, it'll, like, if it goes away at some point in the lifespan of your program, weak maps are designed to release them, release everything. Once the key doesn't exist anymore, release all of things. So you won't end up with a memory leak because you used the object as a key or because you used the function as a key. Some folks will say, like, oh, just use, you know, initialize an object literal and, like, have some sort of ID key in there and then have its value be, like, another object. Except for if my ID key thing, whatever is connected to that, ever goes away, there's no link back to that object. That object just sits there filling up with crap. So, and you think to yourself, like, oh, that's awesome. Are you worried about, you know, memory leaks? Well, if you have, like, a 16 by 16 LED matrix that you're building out with multiple shift registers that you want to maintain the state over, then, yes, you could be creating, like, several orders of magnitude problem with memory leak. So, having a weak map means that whenever any of these go away throughout the lifespan of the program, which is, to be honest, very unlikely, but it's just a smart practice to use, to correctly use private data because it's now becoming available to us, the garbage collector will clean up after you and that's actually a really exciting thing to be able to take advantage of in JavaScript and the future of JavaScript. Yeah, and like I said, it was reading even just the LED code, which I pasted in the channel, just the LED code shows you how you're using a weak map there and it really did just make it like, oh, I get this now. And I had seen weak maps used before and hadn't really grasped it for whatever reason and now it all makes sense, so that's pretty fun. So, okay. Sorry, they're a great receptacle for, like, these large data streams because most of the sensors and things are fireboses. You don't want to be firing other data events directly from these data streams or else you're asking for nightmarish problems that of the scroll event kind of nightmarish. So, having these weak maps where the instance has this little bucket, you could just push everything into the bucket and just keep updating these state values and then you can have other functionality and other logic in your program or in our case in the constructors that we're creating for Johnny Five that then can do some processing, some lazy processing on those values. So, like, maybe I don't always want to calculate the three-way X, Y, and Z of an accelerometer. I don't need to calculate that every time I receive information, but if I just pipe the value into this bucket and then when my program asks for that data via a defined accessor, we can then say, so we've defined this getter that dips into the bucket and says, what's the current value? Right, we'll do the calculation and send you back what you asked for. So, that was a great question. So, that way I'm preventing large calculations from building up in all the CPU cycles, which brings me CPU cycles, which brings me to another thing, which is a newer development in the land of Johnny Five. So, I had this idea, so Rebecca was talking about timeouts earlier, things you could do smarter in JavaScript that you can't even do in CPC++ because those APIs have, like, so those Arduino APIs are, like, delay. Delay for these milliseconds. This is blocking. So, all hardware is, like, implicitly synchronous. So, one thing that, like, started to feel dirty to me was I felt like I was amassing technical debt with regard to timeouts and my use of timeouts and intervals, and then it sort of came to a head when Andreas was forced to create a loop, which we'll soon do away with now that I've actually figured out a way to get around this by using nodes, like, so no Node.js idiomatic that it fucking imparts the solution I came up with. It's a package I created called Compulsive, and it also has four methods, wait, loop, repeat, and queue. Queue lets you create a queue of waits, loops, and repeats. What it does is say if I want to wait, so I just do, you know, convulsive.wait and then milliseconds and a callback. Instead of using a timeout or interval or anything that is process bound in that it wants to, you know, wait for the stack to wind down, actually using process next tick. What it does is it says, what time is it right now? You want me to do something in 100 milliseconds? Great. So it adds an entry to a schedule table, essentially. It says, like, at this time, process these. So the rule of thumb here is to keep all of these callbacks very, very computationally light, and you maintain, like, a non-blocking respect with, like, a respectfully mutual, non-blocking partnership with Node and your programs. You're no longer doing sleep or crazy set and, like, nested set amounts to trigger sequences of events for whatever reason or another. So what it does is it adds process next ticks going around and says, what time is it? Okay, we've got the stack. Bang, bang, bang through those. Clear those out. Repeat, reschedule for the future. And, of course, if it's a loop, reschedule for the future. And definitely, if it's a repeat, reschedule and keep track of how many times I've gone and when I have no more reschedules left, dump it. So what this has allowed me to do is sequence, again, hardware is synchronous, right? Everything is synchronous. Well, if I tell the servo to turn to, you know, so you actually hold it this way, 0, 90, 180, that actually took actual time in the real world, okay? So I need to be able to create sequences because if we're ever going to make robots walk, we need to be able to sequence how they do that. So I sat in my living room one day walking around like a funny weirdo trying to figure out how legs should move. And then I tried to make it happen with these crazy series of set timeouts. So it turns out that when you unwind the stack in a nested fashion several times deep, it doesn't ever do what you want it to do. However, if you do a thing and then, say, in the future, do something else without any sort of constraint beyond the fact that I'm simply queued up to exist at a certain time, you can then create actual sequences that happen in order without colliding with each other. So that lets you sequentially order servo movement or anything but in this case servo movement because you can't just go move forward, move forward or else it will just fall on its face. What you need to do is have your movement in a specific order. One second. You don't want it to fall on its face. I'm watching this. So I was actually patrolling this from the command line. It's just a function called step. And step just, you just tell it either forward or reverse. But what's important, see it's like all in crazy order. Give you a better idea. So we want it to stand straight up. As you guys catch that, it just reorganizes itself. But that's four different servos that have to be sequenced together. So in order to do something like make it dance, you need a number of moving parts at the same time. Are you going to build a transformer? Jesus, I don't know, but that would be really awesome. It turned into the wedding ring bearing robot. Like walking robot into the... I think we need more pins, right? Hold on, I'm trying to make something else happen here. No, I don't know what's going on. Well, you get the idea. That's like a number of different sequential movements that have to all happen simultaneously. It's not acceptable to do move. Next movement, it has to be fluid to a certain degree. So harnessing process next tick to keep it non-blogging turns out to work really, really, really well. So I'm excited about that. So I plan on moving all of the current Johnny 5 stuff, anything really that uses any sort of set timings over to that system. So that will be exciting. But that was me popping stack way back to things we can do better in JavaScript than other languages can do. In this case, being asynchronous. A better at it than everyone else. And as it turns out, that makes a whole lot of sense for controlling hardware, which is itself synchronous. So if I need to wait for a thing to happen, JavaScript is beautifully suited to waiting around, doing nothing in the meantime, and then kicking into gear when it's time to actually run a program. Right. Well, we have been talking for one hour, so I think we should go. Okay. This was fun. I can't remember what was working last time I was there. I don't know if the stepper was working. It wasn't dancing for sure. I don't know if it was even working at all. Did you need this last time you were here? You're right. It was an earlier model that I was using, too much smaller servos that I had them, I had their horns were screwed together and I was supposed to sort of walk like... Maybe I saw that. Right. That was the one that you and I... Yeah, but your dad had the better design. Well, so that was the other thing that just walked in place. Turns out you need to have a certain amount of weight to make the balancing. Make the walking happen. You would just kind of moonwalk on the table. Which is cool in and of itself. Yeah, but only secondary to actually being able to walk for you. Actually being able to walk fair enough. The next big project is I'm going... So this is four degrees of freedom. I'm going to move to six and have full hip, knee, and foot joints. So three servos on either side. Basically the idea is every time I do something, the next thing to do is bigger. Bigger or more. More something. Well, cool. Well, this was fun. And this will be on YouTube and there will be links and we haven't really figured out all that part yet, but it'll all be on the Google Plus page and probably other places, too. So, yay. Anything else to say, Rick? Um, nope. Nope, all right. All right, we're going to go. Bye, guys. We're coming to hang out. Thank you. Thanks, guys. Bye, Jory. Bye. In the background.