This software is a simple, low-cost control system for the cardboard BattleBot community project. The project must support all skill levels, from young students to advanced adult makers. Therefore, the chosen platform and technologies are common and well-documented: Arduino, HTML5 and javascript. The hope is to leverage common maker skills or build them in inexperienced participants.
The goal is to keep the cost of a base "kit" to under 20USD.
To aid in ideation and your designs, reference CAD files are provided for standard Kit of Parts hardware and a handful of reference designs:
This section describes the minimum steps needed to load this firmware onto your NodeMCU. The firmware should work out of the box for a basic robot setup. Subsequent sections describe the development environment for customizing the firmware.
BattleBot-Control.ino
in the Arduino IDE.After the default firmware is loaded, the robot should be drivable. In the default configuration, the robot creates a WiFi access point (AP). If you connect to this network and enter the URL of the robot, a user interface will be served up in the browser, allowing you to drive.
http://battlebot.local/
.http://192.168.4.1/
(in the default AP mode only). When connected to an external WiFi network, use an mDNS app like ZeroConf Browser to find the IP address of the robot. TODO: add notes for connecting from Windows (involves installing mDNS / Bonjour for Windows).http://
before the URL or IP to connect, as some browsers will assume https://
, which is not supported.Connecting to the robot access point is inconvenient for development, since it generally precludes using the internet at the same time. For development, an alternative configuration is provided. In this setup, the robot will connect to an existing WiFi network. The development machine also connects to this network, making the robot and internet available at the same time.
To prevent hard-coding the network credentials in the source code, WiFi configuration is accomplished via a configuration file uploaded to the robot file system in the data/
directory of this project.
data/wifi.config:
network_ssid:password
That is, the SSID of the network to connect to and the password, on one line, separated by a colon. This file should be created in the data/
directory of this project. A .gitignore
is present to prevent the file from being checked in to source control inadvertently.
The robot will attempt to connect to the configured network for 10 seconds. If the connection can't be established it will fall back to AP mode. See the Status LED section below.
You can also force the robot to use AP mode by grounding pin D5 during startup (i.e. connect pins 'D' and 'G' of column 5 on the GPIO header strip and press RESET). This feature is useful if you inadvertently connect to a network, only to discover it has firewall rules preventing machine to machine communication.
To load the file on the robot, you can either reload the entire file system with the "ESP8266 Sketch Data Upload", or follow an alternative faster procedure:
$ ./upload.sh wifi.config
This command will upload any file (relative to the root of the data/
directory) to the robot file system.
When complete, reset the robot. The robot should now connect to the WiFi network specified in the file. To return to access point mode, simply delete the configuration file and reload the file system, or use the abbreviated command (as above):
$ ./delete.sh wifi.config
This command will delete a file from the robot file system.
Note that the upload.sh
and delete.sh
can also be used to update the HTML resources on the robot during development. If upload.sh
is run with no argument, it will upload all files in the data/
directory. This is slow, but is still significantly faster than reloading the entire file system.
The default firmware assumes a certain robot hardware / wiring configuration.
Get this wrong and the robot will not drive as expected with the default control interface.
The NodeMCU has two blue LEDs. One (the "front") LED is directly on ESP8266 board, near the antenna. The second (the "middle rear") LED is on the NodeMCU carrier board, closer to micro-USB connection. Due to the pin usage on the motor driver board, the connection to front LED is shared with the direction signal for the B motor channel. Therefore, this LED will be illuminated whenever the left motor is travelling in the reverse direction.
Luckily, the middle rear LED is connected to a dedicated line and can be used for general status. The default firmware utilizes different blink patterns on this LED to indicate various robot states. These states are:
wifi.config
loaded).Note, if the robot is in the driving state and the client becomes disconnected, the robot will stop and revert to the idle state after 2.5 seconds. This is a safety measure to prevent the robot from getting stuck on the last command it received and running away in the event of connection trouble.
The robot emits various debugging messages over the USB serial connection. These can be observed from the Arduino IDE or in a dedicated serial terminal. The baud rate is 115200.