esp8266 (esp-01) communication to esp32

Projects General Guidance
1

Hi, I want to make a RC lawnmower that is controlled over wifi. I have a 2.4ghz 2 stick controller from an old helicopter that I want to modify to connect to my wifi. The RC lawnmower will have an esp32 and I have an outdoor access point that covers my entire property.

Trying to use what boards and parts I already have, I was wondering if I could use an uno type board in the transmitter with an esp8266 esp-01 module to send stick positions to the esp32 over wifi. Would there be speed issues with the uno communicating with the esp-01 over serial versus getting another type of esp8266 board like a nodemcu/wemos d1/etc?

Thanks!

2

I am a big proponent of using MQTT communications over WiFi. If you are going to use WiFi, then you should use a board with WiFi. The ESP8266 has four GPIO pins, so why do you need the Uno?

3

SteveMann:
The ESP8266 has four GPIO pins, so why do you need the UNO?

Good question but - assuming the control stick is not analog, you would need a port expander.

4

You can get small ESP32 boards like this that give plenty of pins and can connect directly using ESP-Now so no need of Wifi if you don't want to.

5

SteveMann:
I am a big proponent of using MQTT communications over WiFi. If you are going to use WiFi, then you should use a board with WiFi. The ESP8266 has four GPIO pins, so why do you need the Uno?

Paul__B:
Good question but - assuming the control stick is not analog, you would need a port expander.

The sticks are analog. 4 pots total, 2 for each stick. Then for each pot there are 2 buttons for +/- trim adjustment plus 6 additional buttons that I will probably use for additional channels. So 4 AI, 14 DI.

I have some of these which at first I thought the pin setup would make it great for wiring the pots and buttons to. https://www.ebay.com/itm/313078280327
But all the pins would be quickly used up

Riva:
You can get small ESP32 boards like this that give plenty of pins and can connect directly using ESP-Now so no need of Wifi if you don't want to.

Thats cool, I didn't know about ESP-Now. I would assume that once your using ESP-Now it is not possible to connect to the ESP-32 via a wifi network. I do have 2 ESP-32 boards.

6

drummin89:
Thats cool, I didn't know about ESP-Now. I would assume that once your using ESP-Now it is not possible to connect to the ESP-32 via a wifi network. I do have 2 ESP-32 boards.

I reuse my ESP boards all the time. You just upload a new sketch to them from the Arduino IDE.

7

drummin89:
I didn't know about ESP-Now. I would assume that once your using ESP-Now it is not possible to connect to the ESP-32 via a wifi network. I do have 2 ESP-32 boards.

Having briefly looking at this just now it seems you can use ESP-Now and WiFi on the same device as long as ESP-Now is using the same channel as the Wifi access point. You may need to disconnect from Wifi to use ESP-Now and then connect to Wifi again but I'm not sure.
Further reading and testing with your 2x ESP32's will confirm this or you might decide to drop either Wifi or ESP-Now to simplify things.

8

SteveMann:
I am a big proponent of using MQTT communications over WiFi. If you are going to use WiFi, then you should use a board with WiFi. The ESP8266 has four GPIO pins, so why do you need the Uno?

I have never used MQTT, especially with Arduino, but I have heard alot about it in the industrial automation world.

My worry is having a quick enough update rate to make the controls not seem jumpy. Would that be an issue with MQTT?

So I would need a broker, which could possibly be a PI that's plugged into my network. The transmitter would be a client that just publishes messages (stick positions, button status's, etc) to a topic. The RC lawnmower would also be a client but it subscribes to a topic and the broker sends any new messages published to that topic.

My goal is to eventually make it autonomous via various sensors, so at some point in the future I may want to have some way to maybe set schedules, set mode between autonomous or radio control, etc so would MQTT be a good match for this? Seems like I would just have different topics for each function.

9

@Riva
ESP-Now looks very interesting.
Will it work with ESP8266 (NodeMCU)?
They have MACs, too.

10

runaway_pancake:
@Riva
ESP-Now looks very interesting.
Will it work with ESP8266 (NodeMCU)?
They have MACs, too.

A quick search and this demo seems to be using ESP8266, also I think Robin2 has written an ESP-now demo code on here somewhere.

11

drummin89:
My worry is having a quick enough update rate to make the controls not seem jumpy. Would that be an issue with MQTT?

My goal is to eventually make it autonomous via various sensors, so at some point in the future I may want to have some way to maybe set schedules, set mode between autonomous or radio control, etc so would MQTT be a good match for this? Seems like I would just have different topics for each function.

I don't know if MQTT will be fast enough (or is really suitable for remote control) but to try you could setup a broker on a RPi, subscribe to a topic and then publish a message to that topic. If you note the average time difference of the publish to the subscribe callback receiving the message you will have a rough idea of the lag.

12

Hey, that ESP Now demo worked.
But, I had a problem at first. I could only get a packet, sometimes, if I kept pressing the receiver module's reset.
After going through the comments at RNT I found the solution - the addition of
WiFi.disconnect();
in setup ( ).

void setup() 
{
  Serial.begin(115200);
  Serial.print("\r\n\r\n");
  Serial.println("ok");
  
  WiFi.mode(WIFI_STA);
  WiFi.disconnect(); // Thanks Marek!!

  if (esp_now_init() != 0) 
  {
    Serial.println("Error initializing ESP-NOW");
    return;
  }
}

void loop() 
{
  esp_now_set_self_role(ESP_NOW_ROLE_SLAVE);
  esp_now_register_recv_cb(OnDataRecv);
}

Maybe (??) it's a version thing, Rui (RNT) didn't need it but mine needed it.
Works great.

I have no idea how well this will work in an "RC mower" application (any noise vs. 2GHz). Could be fun.

13

I got the referenced demo code to run between two WeMS D1 esp2866 boards. I'd like to be able to connect a pot(s) to the send wemos and have the receive wemos control a servo(s). A basic RC setup.

14

drummin89:
I have never used MQTT, especially with Arduino, but I have heard alot about it in the industrial automation world.

My worry is having a quick enough update rate to make the controls not seem jumpy. Would that be an issue with MQTT?

So I would need a broker, which could possibly be a PI that's plugged into my network. The transmitter would be a client that just publishes messages (stick positions, button status's, etc) to a topic. The RC lawnmower would also be a client but it subscribes to a topic and the broker sends any new messages published to that topic.

My goal is to eventually make it autonomous via various sensors, so at some point in the future I may want to have some way to maybe set schedules, set mode between autonomous or radio control, etc so would MQTT be a good match for this? Seems like I would just have different topics for each function.

I've never measured the lag time from publishing a message to the receiving node receiving it. Ont he other hand, I've never observed a delay long enough to notice it. In most cases, I send a message to turn on a light, and the light comes on virtually immediately.

I have a fairly busy MQTT broker- if I subscribe to #, data just goes screaming by on the terminal.

The MQTT protocol has a user-determined QOS that ranges from send and forget (QOS=0) to send, wait for ACK, send again. repeat indefinitely until an ACK is received. (QOS=2).

No matter how you control the lawn mower, you should build in independent failsafes. Things like kill bumpers where if they bump into something, the power shuts down. A GPS for geofencing. You don't want to realize it's quiet in the back yard as your mower merrily drives itself down the street.. Maybe monitor the motor current. If the motor wheel stalls as if the mower is unable to move it should draw more current than the others. Or none if the motor died.

15

SteveMann:
I've never measured the lag time from publishing a message to the receiving node receiving it. Ont he other hand, I've never observed a delay long enough to notice it. In most cases, I send a message to turn on a light, and the light comes on virtually immediately.

I have a fairly busy MQTT broker- if I subscribe to #, data just goes screaming by on the terminal.

The MQTT protocol has a user-determined QOS that ranges from send and forget (QOS=0) to send, wait for ACK, send again. repeat indefinitely until an ACK is received. (QOS=2).

No matter how you control the lawn mower, you should build in independent failsafes. Things like kill bumpers where if they bump into something, the power shuts down. A GPS for geofencing. You don't want to realize it's quiet in the back yard as your mower merrily drives itself down the street.. Maybe monitor the motor current. If the motor wheel stalls as if the mower is unable to move it should draw more current than the others. Or none if the motor died.

Thanks. that sounds promising. and I plan to use a RPi on my network for the broker that will be used just for this.

Yes, will definitely have failsafes as well as various other means to shut it down. Plan to do much testing before any blades start spinning.