 Really, thank you so much and my name is David Nathendee. I am actually the first time coming to this building and I really feel like a fish farm owner. Because I'm actually an accidental developer before this. I was working as a research assistant in National Institute of Education. We developed classroom software by taking out actually in statistics and marketing. In my previous job there was a need for my principal investigator to develop some software. So I transitioned into that and started an open node and I really love for that. And I also like to play single board computers. But about three, three and a half years ago I had a baby. And so I don't really have that much time outside work to socialize with many people. But now it's almost home now and it's much easier to take care of. I mean we just give in about an hour. But yeah, now I can come out and meet people and I really look forward to be more involved. So yeah, before we begin, sorry. Until number two comes along. Until number two comes along. Yeah. So before we begin, everybody familiar with node I guess. And familiar with Arduino I guess. Okay, so for Arduino the way I don't know just as far as I can, I don't really know. It's just serial, doing over serial. And there's a node module, node serial port. Who has ever tried node serial port here? Just so that I can reach. Not really. Well actually probably it's a bad idea to ask you. Because my eyesight is really bad. So yeah, so what I have here is a little project that I do on my own. Just to keep myself sharp when getting on jobs. And what I have is a webcam and a temperature, humidity sensor. And grouped up to Arduino Uno and then connected to node. The project is long view and hang on, let me just pull up to you. Okay, so that's the diagram. It's pretty simple. At the left you have your Arduino. That's the sensor in there. Basically it's just a normal Arduino. It just made it just like how you would do an Arduino project just as long as it outputs serial and listens to serial. And I have a node.js app running on a latest computer. This can be on a laptop or it can be on a Raspberry Pi or PC. That's the remote unit. And they talk about serial using node serial port. And the remote unit goes to the server. And the server is an Arduino.js app with Express. And the communication between the server and the remote unit is via socket IO. So there is a little kind of communication there. And also of course you can log in to the server with the browser. And communication is also done over socket IO over there. So yeah, so let's just try it out. Okay, so I just connected the unit to the server over my Wi-Fi. I already loaded the server on my digital ocean drone pad. And after logging in, we can see the temperature data. And we can start as well to get camera image. So that is a system that changes the camera. But there is a limit that the camera can turn. And that actually is from the Arduino. So it went from the browser to the server over socket. And the server goes to the remote unit over socket. And then over there, the remote unit node.js app checks for... Oh, sorry, for the panning, it goes to the Arduino. And then the Arduino says, hey, sorry, this is the end of the rate already. And then the node.js remote unit app sends socket IO message back to the browser. So I thought it would be good to have some basic control just in case the user... Tick-tack-tack-tack-tack-tack-tack-tack-tack... There is a billion check. The user cannot do that. Too quick it cannot be within 500 milliseconds. So right now, anybody has any questions? What's the resolution of the camera image that you are sending? Oh, the resolution, I don't know, this is just a very low-cost camera. I guess it's 640, 480. Yeah. And we can definitely expand with more sensors or so. It really is not there, so we can add on more. There's nothing special with the Arduino software. It just listens for commands over serial. So if the node.js remote unit sends 1, that means pan the camera lag. It is 0 and pans the camera right. And it is 2 and just speeds up the sensor data and that's it. And the code is on GitHub. I think I put a link on the top.js page. But just in case, you can go to github.com. It's just a personal project right now, but if anybody is interested to make this into a more elaborate project, I'll be more than happy to collaborate. Actually, I got a friend that is building a submarine using Oculus Rift control. Maybe I can hook you up. Oh, very cool. Yeah, cool. So far, any questions? You guys have been quiet, so I kind of don't know. What is the size of the image that is passed to the server? Sorry? You're passing some image from the client to the server right? Yes, correct. Size of each image? This is 648. I mean when you say it physically into the case somewhere, right? You're not saving any physical images? What do you mean physical images? I mean you are just taking from the camera the images and passing to the server right? So are you storing those images? Oh, yeah. Notice I have the remote unit actually saved the image there, and then uploads it. This is a normal upload. So security-wise, it's actually not that good, because you can actually go to the URL, slash if you know the feature name. Sorry. I can see all the images if I go to the URL. Yes, correct. So my question was if at all we save the image, right? What is the size of each image? I mean physical KBs, how many KBs each? Not too sure. I guess it's not that big. Probably below 100? Yeah. In your architecture, you have no JS running on the remote unit. I mean I don't know enough of no JS, but what function does that perform on the remote unit? Why do you need a server-to-server type of communication? What is your architecture doing? Oh, okay. Yeah, good question, because... Hang on, let me just show you. So... In the end, let me replace the remote unit with something else, other than a node. Just as long as it asks, okay. But it's just that I don't know other languages that can do that. The reason is because the server needs to talk to a computer that can communicate with the Arduino. And the way this setup is using node serial power. Yeah, that's all the question. Between the remote unit and server, what's happening? How is that going to get... No JS serial is happening between sensor unit and remote unit. Between remote unit to server, what... How is it communicating? Okay, so it's just socket. I also... Remote unit is just a return and send socket, and it's socket. And whenever the user click a button, then the server will emit something like hand lab. And then the remote unit will have something like this. So like on hand lab, go to the top of the Arduino, and then get the Arduino to turn right. There's actually a digest cycle on the remote unit there, because communication is not over serial, and we are communicating two different things basically. So pan the camera, and... pan camera right, right, and getting the sensor data. So there's these three things going in and out, and we can actually ensure that they won't clash unless we call some kind of intermediary or in between guy. So the way this is done is I have a function that runs every, I think every 500 milliseconds, and as there's a new request, there's a new socket request like pan camera right, that will add order, we push to an array of messages going to the Arduino, and every 500 milliseconds, one by one these messages is executed, and once it's executed, it's empty. So I won't have any opportunity or any possibility of clashing data in and out. So Arduino over Wi-Fi. Yes, there's actually hardware, you can do it hardware-wise, so there's a chip that you can add on to the Arduino, and I think they call it Wi-Fi shield or something. But I'm not familiar with that, or maybe it's something like Arduino, but the Arduino, it has the Z-SOM Linux, a small Linux computer side-by-side already, and you can put node on the Arduino, it's just that I haven't tried that. So they are there, and they are there after that. The sensor you need receives the information. Actually I assume that the node server is set up in the remote unit, right? So is there a node in the remote unit? Yes, yes. So from the time that the sensor you need receives the information, to the time that the remote unit in which node.js is ready to send out the packet later, have you ever tried to see what's the latency between, the latency over a time period? Below one second? One second is 1,050 seconds. Yeah, 1,050 seconds. Over my everything. I'm not talking about the fact that you need to go to the server, and then from the server, it needs to go to your phone. Just looking at the raw latency between the time that it receives the data to the time that it's ready to send out. So recently, do you check to see how much latency is there in there? Oh, okay. Yeah, I do check that. In fact, I don't know what tool I can use to check that. But I don't see any... Okay, so those are very close to the remote unit. How long do you listen to packet latency? Yeah, it feels pretty... I mean, feeling is just...feeling. Just asking to see how well it performs. Okay. That's fine. Kelvin, I think when you talk about the time that the node.js program takes, it's less than a millisecond. Less than a millisecond? Yes. Just for my MacBook, I run an application, and the problem is I can't push more data to it. Right? So it's not...it still has lapses where it's just idle in there. And I fire a couple of thousand per second at it. API calls per second on a MacBook. So it goes through socket IO and node V fast? I mean, unless you do some very complicated calculations in there which you shouldn't do a node.js, this is amazing fast. Okay. You can't measure it because it's usually less than a millisecond. I mean, on this one, there is not much happening, right? As you said, you can only do... Even if you keep your finger pressed on it, right, you will actually block it, right? Yes. And then there is the physical limit in how much the camera can actually move at the right. Yes. So what I was thinking, if I see... If node.js is there to receive as many API calls as possible, right? That's what it's been set up. And then you have one sensor. So is there a possibility actually to deploy that and have hundreds and thousands of sensors that you manage and you just, like the Internet of Things, you just take it and you are calculating something with it and you use it in that aggregated kind of view? Yeah, that would be an interesting project to try at this. That would be possible. So you could have, let's say, a couple of hundred sensors all over Singapore, which there is existing, like, for example, for traffic and other things, right? And you could just collect that data into your server that you have there, like communicating with all the different... Remote units. Remote units and sensors. Probably, like I said, this is less than a millisecond. It still doesn't lock your system down, right? Yeah. And then we're talking about that they are constantly firing it, which doesn't make much sense with the temperature being more or less constant, right? Yeah. So you can run a lot of sensors with this setup that you have. Yeah. Actually, the air pressure and temperature, I don't even infer any kind of filtering or data smoothing algorithm on the app. So whatever we see is whatever the Arduino detects, so you get all the fluctuations. And then I just signed up, actually, blocks it. I mean, not blocks it, but it only works once every 520 seconds. So the messages coming from Arduino to the remote unit is actually more than that. Several times before that 520 seconds is due. So it is something like, for example, I'm running a customer service and there's a customer calling me. Hey David, I want to order maybe a chocolate donut as always chocolate donut. And I pass a message to my delivery guy. Hey, this customer wants chocolate donut. And the customer says, hey David, I want strawberry donut this time. I call my delivery guy. Hey, he wants strawberry donut now. But my delivery guy says, hey, whatever you customer wants, I will go tomorrow morning. So I'm actually updating my delivery guy a few times before he actually goes out the next morning. And that is in the digest function there. You can see in the code, the code is in the 10 million. If you go to the repo, there's a folder, there's an Arduino code, there's the 10 unit which is for the remote unit and that's the server. And the 10 unit is where the remote unit code is. So... Can you just read through it? Yeah, sure. David, does the Arduino have a GPS component that you can put away? Yes, that's possible. I just don't have the budget to buy a GPS system. As I said, I'm thinking in a bigger picture. So looking at one of the major problems that we have, which is taxis for example, right? When you need one, you don't get one because it's raining, right? Everybody wants one. So if for example all the taxes will be employed with a small chip that is delivering that information to whoever is going to distribute the data, right? You can predict, and that's what people do, right? They're predicting where over time most of the people will probably ask for a taxi and they are just managing the demand and supply at the same time in the best possible way. That would be a good application to have this little microcomputer, right? Put it in a small socket and put it on the dashboard with a SIM card in there. Everything happens magically, right? You don't even have to charge the taxi driver for it, right? So let's say Comfort would be interested in better distributing their cars and allowing them to drive around empty last which is producing gasoline and all that stuff. That would be a good application, right? If that Arduino would be possible to do that and the cost obviously has been gone and the other thing was this Rahi project or something like that that Roland presented a couple of months ago, I think last year, right? To look at local weather and then use that in the crowdsourcing in order to come up with warnings maybe or an other stuff. Yeah, so that's definitely within the realm of possibility. It's very exciting. If anybody would be interested to, you know, give up this even further, maybe in 4K, I'd be more than happy to collaborate. Yeah, so definitely very exciting. That's like what that gentleman said. Okay, cool. So here's the digest function. Okay, so I have two arrays, two Arduinos and four Arduinos. So these are the arrays that I will populate as and when the socket IO message comes in. So I just push on to two Arduinos when the socket comes in. I push to two Arduinos and when there is a sense of data from Arduino coming in, I just populate from Arduino and I'm sorry to be about to find the code. Yeah, so that's the digest function. It's pretty safe also. It just fires every continuously every 500 milliseconds. Do you have to query the Arduino for its current sensors, readings, or do they just arrive at events and you have no control? Yeah, I have to query the Arduino one send any unless it receives a command over serial. In this case, I think 0, 1, and 2. 0 for pan-right, 1 for pan-right, and 2 for sensor data. So is it request response style? Yeah, you can think of it that way. Or do you block between asking and receiving data? It happens over serial, not serial code, actually, so we can do something like on data and blah, blah, blah. So why, since it's not, I guess the communication is happening a separate thread, why do you need a dinosaur to look from the server side messages? Why can't you just issue those immediately? There's no single threaded, right? Yeah, so if I don't put them in the dinosaur, there's a possibility that when the Arduino is sending the sensor data, there's something coming into the Arduino, the pan-right coming into the Arduino. But if you block while you're talking to the Arduino, then that event, the pan-right, will just sit in JavaScript's event loop, right, until you're finished, then handle it next. Unless I'm mistaken. Yeah, I mean, there's more than one way to put people in there, actually. It seems like, because I mean, the great thing about JavaScript is the fact that you have this send-in-spreaded event loop sourced up. So it sounds great to use for I.O. And if you're blocking anywhere, then there's no chance of sending a message but I guess so. You can talk about that later. Yeah, yeah, sure. This is what happens in my mind that I work on this one. It's about time to wrap up. Okay, cool, cool. So yeah, just send me an email if you have any questions or want to talk more. QuoraQuoraName at gmail.com K-R-A-K-R-A-D-A-B-E at gmail.com Thank you.