Archive

Archive for the ‘Node.js’ Category

Controlling an Off-the-Shelf RC Car with an Arduino

June 4th, 2015

Last month I bought my first Arduino (actually a SparkFun RedBoard) and started playing around with Johnny-Five to control it via JavaScript. Since then, I’ve learned the basics of electronics, microcontrollers, and how Johnny-Five works. This weekend, I decided to buy a cheap RC car and see if I could hack the remote so I could control the car with my laptop.

I picked up a 1/24 scale New Bright 2014 Silverado for about $10 at Target. I chose this model because of the truck bed, so I would have a place to mount a microcontroller in case I decided to mod the car itself later. I also made sure to check what kind of batteries the remote used to make sure I could power it from my RedBoard. The remote uses two AAs, which is a total of 3 volts, so I figured the 3.3v power pin would be perfect. The car itself uses three AAs, which is a total of 4.5 volts, so if I do go down the road of hacking the car, using the 5v power pin should be fine.

unmodified remote

The first thing I do whenever I dig into anything new is making sure that it works as I expect, so I can verify the behavior is the same after every step. After my kids played with the car for a bit, I knew everything was working, so it was time to start ripping things apart. The remote was just two pieces of plastic held together with two screws and a few plastic clips. As soon as I opened it, I found something unexpected. The joysticks were actually just two buttons for each axis, not a standard joystick with variable movement along the axes. In hindsight, this should have been obvious since the car didn’t have variable speed and the wheels snapped to a specific position when turning.

remote opened up

Now that I had the remote opened up, I had to get the circuit board out of the plastic. This was just a matter of pulling the battery leads straight out (while compressing the spring for the negative lead), then the circuit board came out very easily. I used some jumper wires to connect the 3.3v and GND pins from the Arduino to the battery contacts and pushed the forward button to make sure powering the remote was going to work. Once I had confirmed this worked, I hooked up two AAs so that I didn’t need to hold the wires in place as I did more testing. I then tested all four buttons just to make sure everything was still working.

The existing battery leads in the remote. The spring for the negative lead needs to be compressed to pull out the circuit board.

battery-holder

At this point, my plan was to replace the buttons with some other component that I could control from the Arduino. I wasn’t really sure what I could use for the replacement though. My only thought was to use a relay, but then I decided to try to trace the circuit and see if there was another way to hook in without desoldering the buttons. I noticed that there were seemingly random solder points connected to each of the buttons (these turned out to be test points for the board), so I decided to try applying voltage to the solder point for the forward button. I already had a script open that blinks an LED every second, so I just used that for my testing, since it would toggle between a HIGH and LOW signal on the pin. I was happy to find out that this worked (once I remembered to connect the GND pin as well to complete the circuit). I then tested the other three solder points to make sure I had identified the correct point for each button.

I was finally ready to start modifying the board. I plugged in my soldering iron and cut six pieces of hookup wire (one for each button and two for power) while the iron was heating up. First up was desoldering the battery leads and adding the new wire leads to connect to the Arduino. Then I soldered a wire to each of the four solder points that corresponded to the four buttons. This is where I made my biggest mistake. I didn’t realize how stiff the hookup wire was and how fragile the solder points would be. When I tried to bend all the wires to plug into my breadboard, I ended up ripping out the wire for reverse. I had to solder the wire directly to the button at that point, but I learned a valuable lesson: bend the wires into their desired shape prior to soldering.

The circuit board with new leads, connected to a breadboard.

Now that the board was modified, I was ready to write a script to control the car. I decided to keep it simple and just use the arrow keys. Rather than having to hold down the keys, I made each action “sticky” so pressing up once would make the car go forward until you either pressed up again to stop it or pressed down to make it go in reverse. This worked pretty well, but it was very awkward for turning. Modifying the script to treat left and right as momentary actions would make it easier to control. My next step will probably be exposing the controls via a web server so my kids can control the car with their iPads. I never thought I’d be able to do that with a cheap off-the-shelf RC car and just an hour or two of tinkering. After just a few weeks of playing with Johnny-Five, it all seems so simple :-)

Note: This script uses the keypress module.

Arduino, Johnny-Five, Node.js

Long polling in Node.js

May 21st, 2010

Note: Node is currently under heavy development and the API is in a state of flux. This article was written to be compatible with v0.1.95, the most recent version of Node at the time. The examples in this article may not work with future versions.

Many web developers seem to think there is some sort of black magic behind long polling, either because the language or web server they use doesn’t support it or because they correlate it with server push technology. In this article, we’ll show how to implement long polling in Node.js and explain why you don’t need to do anything special on the client to support it.

Request types

We’re all familiar with standard web requests: the client requests a resource, the server responds synchronously, then the page is displayed. We’re also familiar with the concept of ajax requests in which the client requests a resource asynchronously and is notified when the server responds. Typically the server doesn’t treat ajax requests asynchronously; a request comes in and the server immediately (and synchronously) processes the request and responds. The asynchronous part just happens on the client where the browser doesn’t block while it waits for the server to respond.

Long polling is an ajax request in which the request and response are both treated as asynchronous operations. Rather than accepting the request and immediately processing to return a result, the server accepts the request and holds on to it until some other event occurs, providing data to send as a response to the original request. Most scripting languages don’t support holding on to requests for long periods of time because the script runs from top to bottom and then immediately responds. Trying to hold on to requests in these languages would require creating a blocking loop that waits for the relevant event to occur and that would quickly kill your server as requests build up. Node scripts run in an event loop, making them ideal for holding on to requests without blocking other processes.

Handling requests in Node

Because Node is specifically built to provide non-blocking I/O, even the Hello World example from the docs shows off an asynchronous response to an HTTP request.

When a request comes in, the server will wait two seconds and then respond with “Hello, World!”. The important thing in this example is that the script is not blocking while it waits two seconds. This means that other requests can come in during that two second period and be handled immediately. In this case, those additional requests would also wait for two seconds before getting a response, but the response would come two seconds after the request was initiated, not two seconds after the previous request is closed.

Let’s split the response generation out of the main function to get a better idea of what’s really going on here.

There are a few differences between this example and the first example. Right away, we can see that when a request comes in we don’t make any attempt to respond to it, we just throw the response object into an array and seemingly ignore it. Next we have a function that runs every two seconds and responds to all the requests that we’re holding on to. Since this interval is based on when the script was started, the request may be held for anywhere between one millisecond and two seconds, depending on how close the request comes in to the next run of the interval. This better represents the standard model for a long polling implementation in which some event not directly related to the request occurs on the server and triggers a response.

A more complex example

Let’s build a script the pipes stdin to HTTP requests. When an HTTP request comes, we’ll check to see if we have any data already stored from stdin. If we do, we’ll just respond to the request immediately; if we don’t, we’ll hold on to the request and respond whenever we detect some action from stdin. Likewise, when we receive data from stdin, we’ll check to see if we have a pending HTTP request. If we do, we’ll respond to the request with the data that just came in; if we don’t, we’ll store the data and respond whenever a request comes in.

Preventing timeouts

One problem you might run into with long polling is holding on to the request too long. If you take too long to respond, the request will eventually time out. To prevent this from occurring, you can keep track of when the requests come in, and send an empty response if the request is still open after a certain period of time. When the client receives the empty response, it will start the next long poll request. This can easily be accomplished with a slight tweak to the code above that uses an interval to respond to requests. Instead of just responding to all requests, we would check if the request has been pending for too long, and close it out if it has.

Long polling on the client

As mentioned above, there’s nothing special that needs to be done on the client for long polling. The general concept is just to make an ajax request and when you get a response, handle it and make the ajax request again. This process just loops over and over, handling data whenever the server responds.

Node.js , ,