Close
0%
0%

IP control for inexpensive line following robots

A project for my grandchildren to first build line-following robots then convert them to being controlled by their phones and tablets.

jedjed
Similar projects worth following
I have nine grandchildren, ranging in ages from 5 to 17 and ranging in hacking ability from none to taking First Place in the STATE Science Olympiad.

I wanted a project that could be interesting to ALL of them. I wanted it to be short enough to complete for even the no-attention spans of our most connected youth.

I'm hoping this is it.

Project Goals:

. Interesting for at least most of the grandchildren
. Quick enough to be completed during our summer week together
. Not too expensive, since 9 * (expensive) = prohibitive and I need one for myself, too
. Simultaneous control to allow racing - necessary to get the interest of some

Simply building a line-following robot would probably interest between three and five of the nine grandchildren. Adding the ability to control them with a phone or tablet and then to RACE them against each other will probably get the rest involved.

So, what sort of control from the tablets and phones? First I considered Bluetooth, but I fear that the multiple robots being controlled by multiple phones over Bluetooth would interfere with each other. Since simultaneous control is a MAJOR goal, that is OUT.

I settled on trying short UDP datagrams that set the state of the robot, with the processor on the robot taking it from there. Any WiFi network could support more robots than could fit into a room, so this seemed a good target.


Digression: UDP - User Datagram Protocol is the text message of the TCP/IP world. No "phone call" , no connection, just squirt out a limited size transport-layer datagram with no promise of delivery. The minimal requirements and overhead are just right for this application.

Next I needed to decide on the hardware to be carried on the robot. To me the choice was obvious - some version of the ESP8266. It has all the capability I need in an inexpensive package. I can't use the smallest versions but some ESP8266 Mini NodeMCU version has all the power plus easy implementation that I could ask. I found a three-pack at Amazon for $13 with amazing one day shipping and I found many on eBay for less with not so amazing one month shipping.

Link to single example on Amazon

I purchased samples and started developing.

There are various versions of the mini NodeMCU but they all share an onboard 3.3 volt regulator, a USB<->serial conversion circuit, and the various other support circuitry so that they work right out of the box. The ESP8266-12 that they have onboard needs some pins tied high and others tied low before it will load software. It also needs a special "program" lead held high while reset is toggled. The NodeMCU package takes care of all of this for you. The version I use here is best documented at Wemos Electronics.

I use the Arduino IDE for ESP8266 development, so I just started my version 1.8.7 and selected the NodeMCU 1.0 as my target board. That let me look at the Examples and I found (under File>Examples>ESP8266WiFi) a "sketch" called Udp. I nabbed a little code from there and went into "software blacksmithing" mode. I heated it up and pounded on it a bit to beat it into my first test application.

All that application needed to do was:
1) connect to the WiFi network
2) get an IP address
3) display the IP address on the debug terminal
4) loop while
   5) listening for UDP packets and displaying them
   6) interpreting properly formatted packets and displaying the result

The result of this is called ESPlineUDP.ino and is the first program. Since this was only testing communication with the NodeMCU, I needed only to connect one to a USB port on my PC and proceed.

To send test UDP packets, I used a Linux system and the script sendudp.sh. That script is also in the program section, but is so short that it follows here:

cat bin/sendudp.sh  <-- Linux command to display the script

#!/bin/bash -x
IP=192.168.95.107
# test sending UDP packet (only in bash)
echo -n "996,025" >/dev/udp/$IP/4949
sleep 3
echo -n "096,955" >/dev/udp/$IP/4949
sleep 3
echo -n "000,000"...
Read more »

IP_Robot.zip

Eagle schematic and printed circuit board

x-zip-compressed - 9.15 kB - 07/17/2019 at 14:47

Download

ESPLineMApp.ino.ino

Program for ESP8266 running line-following robot. This program watches for 16 byte UDP packets and sets the PWM duty cycle for the two wheels. The message format was changed from ESPLineMouse.ino to work with the Android UDP Joystick app

ino - 5.21 kB - 07/05/2019 at 21:19

Download

ipinput.txt

really ipinput.html - used to set target IP address of a web page's UDP commands

plain - 792.00 bytes - 07/05/2019 at 21:05

Download

setip.cgi

Simple script that saves target IP address in a table. This is called from ipinput.html, which is an option on mouse.html.

cgi - 1.30 kB - 07/05/2019 at 21:02

Download

ipdump.cgi

Simple script that lists whole IP address table. After one has set a target address, there is an option to run this program.

cgi - 771.00 bytes - 07/05/2019 at 21:02

Download

View all 13 files

  • 1 × Mini NodeMCU Lua hardware, for example WeMos D1 Mini Mini NodeMCU 4M Bytes WLAN WiFi Internet Development Board Base on ESP8266 ESP-12F. To match my pinout, the WeMos D1 Mini is required. Other like boards will have different pinout, so a different carrier would be needed.
  • 1 × 0.96'' OLED Display 0.96'' I2C IIC 128X64 Pixel OLED Display
  • 1 × Line following robot kit Smart Car Intelligent Robot Tracking Car D2-5 Soldering DIY Kit
  • 2 × LEDs with 3V3 current limiting resistor Any LEDs you have on hand with the correct resistors. If you have red LEDs, 150 ohm resistors will be fine.
  • 1 × USB Micro B cable USB 2.0 A-Male to Micro B Cable to attach NoteMCU to computer for programming

View all 6 components

  • 21 August - PCBs arrived, some failures to report

    jed10 hours ago 0 comments

    The PCB boards from OSH Park arrived promptly, but I was out of town. I ordered 16 July and they arrived about 27 July, using only the free shipping option. I assembled one and everything went smoothly UNTIL I tried to use it. The components all fit properly and soldered easily. The boards were exactly as I tried to design them and a delight. A few dollars and a few days let me avoid the all the troubles of etching my own. Again showing that just because you CAN do it yourself does NOT mean that you SHOULD. The knowledge to do it also gives you the knowledge to understand when you shouldn't.


    One change between the stripboard prototype and the PCB, that I mentioned in passing but didn't really explain, was the added jumpers. This picture shows the problem - different suppliers of the OLED displays have VCC and GND pins switched. The jumpers allow me to select which display I'll use this time.


    My first problem with the PCB was that the display was flaky. That turned out that the components on the back of the display were touching the ESP8266 case beneath it. A strip of electrical tape quickly cured that.

    The second problem is more difficult. Most UDP messages are NOT getting through. My first guess is that the display is now closer than in the stripboard prototype. The shorts requiring electrical tape showed that. Perhaps it is interfering with the WiFi reception by being so close. To test that, I need to mount the display higher with longer jumpers. I'll do that next and report here.

    Another failure was in planning the assembly of the "tracking cars". I've found it takes about two hours of concentration for any of the inexperienced grandchildren to assemble a car and that's TOO LONG for some. It took even longer for the first ones, but I have a better procedure now. Also, I should have brought a VOM along to diagnose problems. One car had a joint so overheated that the traces around one lead broke on BOTH sides. I couldn't identify the problem without tools. That was poor planning.

     A positive thing was the weather. Our week together had perfect weather for being outside and ZERO days to be inside. That meant this inside project wasn't needed to fill a rainy day. Since it was NEVER a priority project for our week, that isn't much of a disapointment.

    We ended our week together with three assembled cars, of which two worked correctly. They were assembled in the evenings by those most interested. The third car was fixed with a jumper wire across the two broken traces as soon as we got home.

    We have postponed any races until our next get-together.

    It's been very busy around here, so I'm behind on things - including updating this project. I'm trying to catch up.

  • 16 July - OSHPark order

    jed07/17/2019 at 14:46 0 comments

    One great thing about OSH Park Here is that they take Eagle PCB files directly. There is no need to generate the Gerber files most others require.

    I've uploaded my board and generated an order. My order of 9 copies of my PCB costs $21.15.

    I'm now going to upload the Eagle files here, too.

  • 15 July - Take prototype to PCB with Eagle

    jed07/15/2019 at 21:40 0 comments

    My favorite PCB creation tool for hobbyists is Eagle, now from Autodesk.

    Eagle Overview

    Imagine my surprise when the Eagle I have installed, 5.11.0, has been superseded by 9.4.2. My how versions fly! I downloaded and installed the new version and started to get used to the new interface. Then I took my notebook page (as shown in the last log) and drew the schematic in Eagle. The only hitch was the NodeMCU pinout.

    Fortunately, some kind soul has thought of other Eagle users and published a library containing various ESP8266 layouts. The last update is even the one I want. The commit log says "esp8266modules.lbr    Added WeMos D1 mini module - 3 years ago" and that is EXACTLY what I want.

    ESP8266 Eagle Library download

    I've downloaded that library and used Eagle's library manager to "use" it. Then I finished drawing the schematic to match my notebook and used that schematic to construct a board layout.

    The board matches my stripboard prototype with the addition of two jumpers that allow use of OLED modules that switch their V+ and Gnd leads.

    Once the PCB looks done, I print it actual size and try the parts on it. This lets me check some obvious things like clearances and some less obvious like part mistakes.


    The IC socket is a stand-in but tests fit. I'm happy with it.

  • 9 July - Add the circuit to the robot

    jed07/10/2019 at 04:28 0 comments

    I need to go back and describe the circuit tailored to ride on the line-following robot. After I proved the concept and selected the alkaline cells to power it, I needed something that could ride on the robot. It needed to connect to the IC socket for its power and to control the motors, and it had to be able to hold the display. I decided to use a strip board and to stack the OLED on top of the NodeMCU. The strip board would plug into the IC socket and the other parts would plug into it. The wiring is pretty simple, so I planned it on in a notebook then wired it all up. Note the OLEDs in my stash sometimes swap the positions of the V+ and Gnd connections. Watch for that.

    I used stripboard with male header pins to extend into the IC socket and five wires. Two red are V+, two black for Gnd and a green for a signal wire. The stripboard helped make the connections and saved me a few horizontal wires that are on the drawing. Note the socket on the left, for the OLED, has a second socket plugged into the first. This stacks the OLED above the NoteMCU.

    Once I had it properly installed into the robot's single IC socket, we have this familiar picture:

  • 5 July - Adapting to UDP Joystick's format

    jed07/05/2019 at 20:53 0 comments

    So I found an Android app that will send UDP to my address based on the position of an on-screen joystick. That is GREAT! See previous (4 July) entry for details.

    The problem with the app is that it sends its own range of numbers with no tailoring except direction and centering. That means that the program that runs in the ESP8266 NodeMCU needs to change. The "complete" ESPLineMouse.ino turns into ESPLineMApp.ino. The process of turning the joystick position numbers into PWM duty cycle numbers for the motors also needs to move there. The monitoring code left in the application means that I can test at my desk without the robot. I go back to this configuration:


    This gives me everything I need to develop and test. The brightness of the LEDs shows the duty cycle that the motors would see, so I can even test that!

    A bit of work and ESPLineMApp.ino is performing well. I'm posting it now.

    Now that I've changed the protocol that the target NodeMCU expects to match what the Android UDP Joystick app sends, I also need to change my test shell script AND my web page's backing CGI script. To make this easier, I find CGI.pl and add it to my Pi's library. It just takes "apt-get install cgi.pm" and apt-get figures it all out.

    While I'm at it, I enhance the CGI to retrieve the target IP from a table based upon the IP of the requestor. I also add a simple page to set that target and another to list all the table entries. Old fashioned Perl CGI.pl makes it easy, for an old fashioned programmer.
    The original sendudp.sh becomes sendudp2.sh below

    #!/bin/bash -x
    IP=192.168.95.111
    # test sending UDP packet (only in bash) in UDP Joystick format
    # halfway up right side
    echo -n "1996162515001500" >/dev/udp/$IP/4949
    sleep 3
    # top near center
    echo -n "1596195515001500" >/dev/udp/$IP/4949
    sleep 3
    # joystick neutral position
    echo -n "1500150015001500" >/dev/udp/$IP/4949
    #
    

    Mouse.html only changes the name of the cgi it calls to set the IP address of the target. This is now filled in with something real - ipinput.html. Once an IP is input, ipinput.html uses setip.cgi to add it to a table and return a screen. After setting, you have a chance to list the whole table using ipdump.cgi. To get all this to work, I added a directory for the datafiles called /var/www/cgi-bin/datafiles and changed its ownership with chown  www-data.www-data datafiles. That permits the CGI scripts to write there.

    Now to post the new and changed files.

  • 4 July - I found an app!

    jed07/04/2019 at 15:35 0 comments

    As I mentioned before, I'd like to find an app for android already available that I could use to control these robot cars. I think I've found one! When I searched the Play Store for UDP joystick, I found several possible solutions. I installed a couple, then this one:

    Since my current mouse program still has all the debug console print statements in it, I plugged it into the Arduino IDE and, under tools, started the serial monitor. When I reset the NodeMCU it showed:

    Connecting to HomeToo
    .
    WiFi connected
    IP address: 192.168.95.111
    UDP connected

    Then I installed this app on a tablet and set the Destination IP to 192.168.95.111, the port to 4949, the Send Delay [ms] to 200,  and turned the OFF button to ON. I started to receive packets like these:

    Received packet of size 16
    1500150015001500
    
    Received packet of size 16
    1500150015001500
    
    Received packet of size 16
    1500150015001500
    
    Received packet of size 16
    1500150015001500
    

    I can deal with these! I turned the app back off.

    The app has more options. Under Settings, I checked all the boxes for "Center On Release".  Next, I turned the app on and pressed the JOYSTICK button. It showed me the screen with two simple joysticks. The values they were sending were displayed at the top. As I moved the joysticks around, those values changed and I could see in my serial monitor that the NodeMCU was seeing those same values:

    Received packet of size 16
    1500150015001500
    
    Received packet of size 16
    1511148115001500
    
    Received packet of size 16
    1510138915001500
    
    Received packet of size 16
    1510132015001500
    
    Received packet of size 16
    1493122915001500
    
    Received packet of size 16
    1503117315001500
    
    

     The center position sends 15001500 for each joystick. The values vary from 1000 to 2000 in each direction. There are buttons under settings to change directions. I'll make the maximum 2000 and the minimum 1000 in both directions. The top will be 2000, as will the left. That should be easiest to keep straight in my head.

    Now all I need do is change ESPLineMouse.ino into ESPLineMApp.ino and process and display these packets. I'm freed of the need to write my own app!


    Independence Day!

  • July 2 - First phase of project mostly complete

    jed07/03/2019 at 05:54 0 comments

    Today I've posted the code that runs the line-following robot, called ESPLineMouse.ino. I've also updated sendudp.cgi to make sharper turns. Now I can drive my mouse quite well on a bare floor using only a web browser.

    That makes this phase of the project a success! I still need to enable multiple concurrent cars to be driven by allowing some way to specify the IP address of the target car. At boot, the cars DO display their IP address (THE major reason each needs a display), but as of yet there is no way to USE that IP except to edit the cgi script on the server.

    I can think of two ways to fix this - my original plan was to store the IP in a hidden field of the web page and send it with the touch coordinates each time. It looks like that won't work - I don't see how to process both the coordinates AND read the IP. A second way is to have the cgi routine use the IP address of the requestor to look up the address of the target. The requestor would set that address and the cgi routine would remember it. That seems pretty easy, now that other things are working.

    Now for the problem - once our week together is done, my grandchildren will go to home. That's bad enough, but they won't have a web server to run the cgi and let them drive their cars. THAT is unacceptable! Six of them live over 500 miles away, too. I need a way for them to drive the cars at home. This is the problem that I alluded to earlier and still needs to be solved.

    It looks like I need a hand-held UDP source. I again have two solutions in mind. 1) an app, either one I can find (better) or one I write (not my favorite). 2) another piece of simple hardware, perhaps a joystick attached to another NodeMCU. It would need a power source and a display and everybody would need one. Approximate cost: NodeMCU $5, display $3, case, battery and holder, joystick $2 = about $15 each. I'd rather not spend the money.

View all 7 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates