ESP32-CAM with SDcard configuration

There's only so far you can go with recompiling code for every eventuality so I determined to move to SDcard based configuration for the ESP32-CAM. This initially was just for WiFi configuration, recompiling just to change networks is really a non-starter for workshop days, and then added additional useful bits. The main thrust, is is my usual direction, is to wring as much useful work out of the minimum hardware.

As stated elsewhere on this website Random Nerd Tutorials are a great resource for learning about this platform and I recommend you look at their work. Anything here is additional and different, I make no attempt to duplicate their excellent work.

In this case I've kept the original Expressif web server code provided for the ESP32-CAM, and then added the other parts I wanted. The code is on github but some basic explanations follow. 

The SD card can contain up to 5 files which make up the configuration.

config.txt contains information for the overall configuration of the card for use 

wifi.txt contains the SSID and password to be used for the wifi access. Name set in config.txt

.html is the web page pointed to from the config.txt file and is the page served up by the webserver

startup.txt is a script file executed when the ESP32 has initialised. It is intended as an initialisation script

main.txt is a script file executed after the startup.txt file and is intended as the core functionality

Experiments have found that only 6 GPIO pins are available for any use without interfering with the ESP32-CAM operation, others almost always resulting in a crash and reboot. 

GPIO33 in the onboard 'builtin' LED, useful for status indication

GPIO04 is the onboard high brightness flash LED. This can be used for other functions but be aware that it has an LED connected to it using more current than a normal pin.

GPIO12 and GPIO13 are available and can be used for most GPIO purposes

GPIO1 and GPIO3 are in use as serial ports but could be used for most GPIO purposes if required

It's around these components that the code has been written to configure the ESP32-CAM from the card and get a whole series of useful robot configurations out of it at minimal cost. I know that I could fit a Raspberry Pi Zero W or a Pico W, but they would be more expensive and potentially more complex. The great thing here is that it gives the opportunity for first person views for the operator, or can be just as easily configured as a webcam with a custom web page.

This name is fixed though can be changed in the source code and uploaded. The format of the file is simple and as follows.

Robot_1                 <------name of the ESP32-CAM, will be used as network host name and in webpage enquiries

STA                        <------define if wifi will be setup as a client or an access point using the wifi credentials

wifi.txt                    <------name of the file containing wifi credentials 

newbasic.html     <------index or home webpage which the webserver will load

38180                    <------webserver port number

38181                    <------camera streaming port number. 

Only include those lines required and in sequence. If the file doesn't exist then an attempt to use the default wifi.txt name for connectivity will be used

The text on each line is deemed to be complete when a space or new line is encountered. 

The hostname is the name which will be used to identify this instance of the controller.  It will be registered in DNS if an webpage script enquires (see example page) then it will be returned. 

The next line must be coded as STA or APT, STA for running wifi in client mode, APT for running the ESP32-CAM in access point mode.

The next line provides the name containing the wifi credentials, SSID and password. If this file does not exist on the SDcard or is invalid then the default SSID and password in the source code will be used.

The fourth line provides the name of the index or home webpage which the webserver will provide. It is loaded when the controller boots and is the only page served by the controller. Links on the webpage must be served from other servers.

The fifth and sixth lines provide the webserver port numbers for the web page and for the camera streaming output. If not coded then these are 80 and 81 but these are provided here so that alternative ports can be provided to facilitate access via a firewall/router, either locally or over the internet.

wifi.txt is just the default name for the wifi credentials file and it can be any valid name specified in the config.txt file. It contains only two lines, the SSID name and the password.

default_ssid

default_password

There's nothing more to this, and as with the config.txt file, the text is deemed to have ended when a space or new line is encountered.

This must contain a valid webpage which will be served by the controller on request as the index or home page. It can contain links to pages on other servers and run scripts to control or automate the ESP32-CAM. A simple webpage with four buttons is described below. If unsure, consult a web page design instructional such as W3schools for further information on the content.

These are basic instructions to the ESP32-CAM controller to carry out some operation and can be sourced from the web page or from a file. They consist of a single capital letter followed by a string of up to 32 additional characters which form the command. The initial character may be one of the following.

Commands beginning with L are local and the rest of the line is the command to be executed by the ESP32-CAM. An example would be LRESET, which when executed would reboot the ESP32.CAM, or LFLASHON which would illuminate the onboard flash LED.

Local commands include

LSTOPFILE  stops any command file which is currently executing

LRESET reboots the controller

LFLASHON illuminates the onboard flash LED

LFLASHOFF turns off the onboard flash LED

LDRIV12ON turns on GPIO12 if configured for basic I/O

LDRIV12OFF turns off GPIO12 if configured for basic I/O

LDRIV13ON turns on GPIO13 if configured for basic I/O

LDRIV13OFF turns off GPIO13 if configured for basic I/O

LSTOP turns off both GPIO12 and GPIO13  if configured for basic I/O

LDRIV turns on both GPIO12 and GPIO13 if configured for basic I/O

These basic commands are included to support the L0Cost line follower adaption and indicate turn left, turn right, forward and stop actions. The source code can of course be adapted to add many more.

Commands beginning with X have the leading character stripped off and are sent to the serial interface for execution on a co-processor controller. The execution of the command is entirely the responsibility of the co-processor. This could be very complex but an example might be XDRIV0099009900500999 which sends a command to a co-processor to drive forward with 99% drive on both wheels with 50% acceleration smoothness for 999 milliseconds. A command such as XRESET might be an instruction to reboot the co-processor.

Commands beginning with F indicate that a command stream should be loaded from a file, the name of which immediately follows the F. An example would be Fspinround.txt which might include a sequence of commands to instruct the robot to spin around, either issuing local or transmitted commands to accomplish it. For examples of command files see the section on startup.txt and main.txt

This causes the default index or home page to be replaced by the webpage in the file name placed afterwards. An example might be "Hadvanced.html" which might change the default webpage to a page with many more controls and details. This is not a web link as the default page is changed and there is no page to go back to. If there is an error reading the webpage then there is no change.

The purpose of these two files is to provide a basic default scripting function to the ESP32-CAM.

The file contains instructions in the following formats.

The startup.txt file is executed after all the setup for the ESP32-CAM is complete and is intended to provide additional configuration either to the ESP32-CAM or to an attached controller. This could be sending default parameters which will be repeated for each reboot or could be a single run sequence where the main.txt file isn't run.  

The main.txt file is intended to provide a default operation to the robot and when executed is run repeatedly unless an LSTOPFILE command is encountered which stops any running command file executing. This would need to be the last command in the file usually but could be anywhere in the file for testing.