- Fri Nov 03, 2017 7:37 am
#71483
Hello, I'm developing a project that helps to collect and centralize environment data. I am at the point where I need to implement a Mesh Network solution that will cover my curent needs and some specific ones in the future. The project atm. has ESPs as sensing nodes, Raspberry PI as a gateway and a cloud VM as a central server.
A node can connect to the Access Point of the RPI or to a set of pre-defined WIFIs and connect directly to the central server and info can go both ways.
The problem is that the range depends on the RPI, so i looked into ESP mesh projects :
- https://gitlab.com/BlackEdder/painlessMesh
- https://github.com/martin-ger/esp_wifi_repeater
- and even http://espressif.com/en/products/software/esp-mesh/overview
Sadly, I mostly flashed the ESP using Arduino, just recently managed to flash Blinky using esp-open-sdk, so I could only experiment with PainlessMesh.
For my future plans, most of these libs are lacking some features, or are over-qualified in some aspects:
- the mesh does not need to be distributed, it depends on a RPI, so most of the topology could be stored on the "beefier" device, so it can just be centralized with communication being mostly node<->root, not node<->node
- if I update a lib/component (eg. the reading algo of the sensors is changed), all the nodes using that component will eventually receive an over-the-air (over-the-mesh) update (the only knowledge I have of OTA updates is pure theoretical)
- MOST of the nodes will be static in the home/warehouse, so a great part of the topology will be fixed
- besides the static nodes, I would like to have bots that "patrol" the ground, to gather sensor data and eventually map the location (I experimented with ROBOT OS and ESP-ROS), these nodes should connect to the closest AP when navigating and could receive OTA Updates when closer to the RPI
I tried a demo structured like RPI <-> ESP_1 <-> ESP_2, with the gateway of the ESP_1, the IP of the RPI, hoping at least to get ESP_2 to Ping the RPI but to no use (in rpi, I can see ESP_1's ping using tcpdump, but the Arduino LwIP does not have 'L2 bridging'). That's when I found esp_wifi_repeater, which could work perfectly for my needs if I were to add the capability to connect the nodes to each other.
PainlessMesh also works great, but it passes custom packets, probably making it difficult/slow to integrate with OTA updates and ROS Navigation.
And then there is esp-mesh, which seems to be an option, but not really.
I will open Issues on the painlessMesh and esp_wifi_repeater repos to discuss these features with the local communities, until then what would be the best course of actions: add OTA update and bridge-ing (for RPI) to PainlessMesh, adapt esp_wifi_repeater to be a mesh library (harder for me) or write my own centralized mesh lib?
If needed I could provide more info about the project, it isn't a secret or something, but at the moment I can't make it public (indexable) because I use it for an university project.
A node can connect to the Access Point of the RPI or to a set of pre-defined WIFIs and connect directly to the central server and info can go both ways.
The problem is that the range depends on the RPI, so i looked into ESP mesh projects :
- https://gitlab.com/BlackEdder/painlessMesh
- https://github.com/martin-ger/esp_wifi_repeater
- and even http://espressif.com/en/products/software/esp-mesh/overview
Sadly, I mostly flashed the ESP using Arduino, just recently managed to flash Blinky using esp-open-sdk, so I could only experiment with PainlessMesh.
For my future plans, most of these libs are lacking some features, or are over-qualified in some aspects:
- the mesh does not need to be distributed, it depends on a RPI, so most of the topology could be stored on the "beefier" device, so it can just be centralized with communication being mostly node<->root, not node<->node
- if I update a lib/component (eg. the reading algo of the sensors is changed), all the nodes using that component will eventually receive an over-the-air (over-the-mesh) update (the only knowledge I have of OTA updates is pure theoretical)
- MOST of the nodes will be static in the home/warehouse, so a great part of the topology will be fixed
- besides the static nodes, I would like to have bots that "patrol" the ground, to gather sensor data and eventually map the location (I experimented with ROBOT OS and ESP-ROS), these nodes should connect to the closest AP when navigating and could receive OTA Updates when closer to the RPI
I tried a demo structured like RPI <-> ESP_1 <-> ESP_2, with the gateway of the ESP_1, the IP of the RPI, hoping at least to get ESP_2 to Ping the RPI but to no use (in rpi, I can see ESP_1's ping using tcpdump, but the Arduino LwIP does not have 'L2 bridging'). That's when I found esp_wifi_repeater, which could work perfectly for my needs if I were to add the capability to connect the nodes to each other.
PainlessMesh also works great, but it passes custom packets, probably making it difficult/slow to integrate with OTA updates and ROS Navigation.
And then there is esp-mesh, which seems to be an option, but not really.
I will open Issues on the painlessMesh and esp_wifi_repeater repos to discuss these features with the local communities, until then what would be the best course of actions: add OTA update and bridge-ing (for RPI) to PainlessMesh, adapt esp_wifi_repeater to be a mesh library (harder for me) or write my own centralized mesh lib?
If needed I could provide more info about the project, it isn't a secret or something, but at the moment I can't make it public (indexable) because I use it for an university project.
