Going WIFI - First WIFI enabled BrailleRAP

A project log for BrailleRAP DIY Braille embosser

An Open source Braille embosser in the spirit of RepRap

stephaneStephane 09/21/2023 at 09:340 Comments

Starting the ESP app

Now that we have enabled a second UART on the MKS controller board of a BrailleRAP, it's time to make a real thing. Wiring an ESP32 on the controller board, can we enable a WIFI access point and diffuse a mobile web application to emboss some Braille with a BrailleRAP ?

Enabling a WIFI access point with an ESP32 is not a big deal, there is full of examples around the internet about that. Starting a web server serving a react web application seam faisable. So we start a project with VS Code and Arduino ecosystem and a small react application with an input field and a print button.

Starting a wifi access point is just a line of code

 WiFi.softAP(ssid, password);

And starting a web server from files stored in SPIFFS seams easy 

AsyncWebServer server(80);

server.serveStatic("/", SPIFFS, "/").setDefaultFile("index.html");
server.serveStatic("/static/", SPIFFS, "/");

But it didn't work, SPIFFS in arduino environment is limited to 32 char for filename, this is not enough for a quick packaged react app. As we often do with lwip in microcontroller environment, we choose to embed all files in C data structures.  And it fail again, all seem to work well with small files, but with a few kilobytes js file something go wrong and hang. So we choose to fall back to ESP32-idf, the original toolchain for ESP32 from expressif.

And after a few tests we had a working WIFI access point with a react based web captive portal. 

For quickly translate the input text in Braille, we just copy paste our previous tbfr2007 translator written in javascript, this is not a "global" solution as there is nearly as many Braille standards as countries in the world, but this is good enough to give a try.


As we plan to use UART2 of the ESP 32 to talk with the controller board, we select the standard IO16 and IO17 as TX and RX on ESP side. So we just need to wire TX from ESP to RX on MKS and RX from ESP on TX on MKS, and link the GND of the ESP to the GND of the controller board.

Sending the GCODE

There is several solution s to send the GCODE to a board with Marlin firmware, one of the simplest is just sending GCODE commands without comment and waiting for a "ok" or "error" answer from the board. The more important problem is that it seem not a good idea to send the complete GCODE command file from the react app (which run on the mobile phone) to the ESP, the ESP32 is a comfortable MCU with thousands of kilobyte available, but GCODE files can often take a few megabytes, even for Braille single page. 

As we try to go fast, we first try sending GCODE command one at a time embedded in JSON POST requests to the ESP, it partially work but with poor performances.

So we decide to go websocket, when you click on print button, the react application open a websocket with the web server on ESP, then we send GCODE commands one a time to the ESP, the ESP then send the GCODE to the UART, wait for the controller answer and send the commande back to the react app via the websocket. We were able to print complete Braille page but with fair performances regarding what we achieve with AccessBrailleRAP connected to the controller with USB.

Final solution for the test

To improve performance, we implement a simple protocole with a fifo queue on the ESP32 side. The react app send GCODE commands one at a time, and the ESP answer immediately if there is space for more commands in the fifo. So the react app send all the GCODE as quick as it can, when the buffer is full, the react app wait for some space to send the next command. On the ESP side we start a FreeRTOS task waiting for GCODE commands available in the fifo, then sending it to the UART, wait for the controller answer, and send back a status to the react app. At the end of the print, we simple close the websocket. And it work just fine !

The code is available on GitHub :