This week I focused heavily on the networking of our project and made really significant progress. During the last update, I had networking completed between two nodes using WiFi, with hardcoded MAC addresses, SSID and network password. I was really unhappy with this approach: it required that I determine the MAC addresses of all ESPs and manually added them into the code, which wouldn’t be feasible at scale. Additionally, it requires the SSID and password for the WiFi network to be stored on the board, and therefore each time the credentials change, the boards would need to be re-flashed. This would be a pain for sys-admins who are constantly changing the network configuration. Finally, specifically for when we are testing on CMU campus, each device would need to be registered to gain access to the CMU-DEVICE network. All of these annoyances led to me to spend several hours trying to figure out a better approach.
The first issue I wanted to address was the hardcoded MAC addresses. I researched sending signals to all devices on a network. I didn’t see any easy way of doing that, because it is not immediately clear to a device, what other devices are also on a network. I then decided to see how IoT devices do it, as they are often configured to interact in a mesh network. I realized that they tend to “broadcast” their signal, which is sending it to all available MAC addresses. In researching this, I came across something called ESP-NOW, which supports Pseudo-Broadcasting. During some further research into ESP-NOW, I realized that it is actually the perfect solution to networking for our capstone.
ESP-NOW is a connectionless WiFi communication protocol developed by Espressif specifically for their ESP32 and ESP8266 boards. It works by using the built-in WiFi module on the board to act as both a sending and receiving node. You can specify individual MAC addresses to send to, or you could send to FF:FF:FF:FF:FF:FF, which corresponds to the Pseudo-Broadcast mode and all ESPs that are listening within range will receive the message. Using ESP-NOW, there is no reliance on one centralized WiFi network, and we are able to broadcast to all nearby ESPs without needing to manually specify the MAC addresses; my main annoyances from last weeks approach have been completely solved. Another point of note is that ESP-NOW has a range that is nearly double what ZigBee supports: 220 meters vs 100 meters.
I didn’t find it sooner because it is not a general standard for wireless communication – it was developed by Espressif, specifically for their ESP32 and ESP8266 boards – and therefore isn’t as widely used as Bluetooth, WiFi, or ZigBee, but it happens to work perfectly for the boards that we ended up using for our capstone.
After finding this form of communication, I made a sketch to demonstrate multiple ESP32s talking to each other bi-directionally. This was relatively simple to set up with test data, as there is good documentation on the ESP-IDF website. It got difficult, however, when trying to send structs of data and keeping the data intact. There was a significant amount of casting and address re-interpretation required to actually get the data transferred, however, I was able to get it working.
I then decided to add authentication to the packets being sent – specifically HMAC’ing using the C library LibSodium – over the network to mitigate the worst-case scenario that we discussed during our ethics meetings. We were worried about people potentially acting as one of our nodes and responding that a node was safe to travel through, even though it wasn’t. Now, this would be impossible to do as all data is verified using the HMAC prior to taking it into consideration; so long as the attacker doesn’t have the symmetric key that is being used on the nodes, we can guarantee that the message originated from one of our own nodes.
As you can see from the video above, the ESP32 on the left is outputting that every message it receives is failing the HMAC verification. That is because that specific ESP32 has a different key, and therefore its version of the HMAC of the data differs from the HMAC it received.
To join everything into one concise demo, I have 2 LEDs per node wired up to respond to the temperature sensors on 2 of the 4 ESP32s respectively. When the temperature sensor of Board 2 (as specified by the labels on the board) exceeds the threshold, you can see all of the yellow LEDs activate; there is no physical wires between them, this information is being communicated over the ESP-NOW network. Similarly, when the temperature sensor of Board 3 exceeds the threshold, the green LEDs activate.
I am on schedule with my Gantt chart at the moment. I am really pleased with the the switch to ESP-NOW wireless communication. It provides all the benefits of ZigBee – mesh system where all nodes can talk directly to each other; no central point that could go down and disable the entire network – with none of the downsides – additional cost of XBee modules; external libraries to interface with these modules; additional wiring to connect the modules to the ESP32s.
Next week, I am going to focus on integration between my own parts, primarily pathfinding and networking, as well as integration between the parts from my teammates. I need to ensure that I am able to interface with the C++ code I wrote for pathfinding, and incorporate the network data that I am receiving from ESP-NOW. The other primary focus will be outputting the pathfinding information into data that Aidan and Neha can use on the display to accurately draw a path out of a floorplan.