Product Suggestion: ESP32-Now on a Breakout Garden?

Support
1

A few weeks ago I discovered the magic of ESP32-Now, which allows ESP32 boards to seamlessly and easily communicate with each other up to 200m away over a mesh network. I’ve got an ESP32 board on my robot and am communicating with it via a small handheld ESP32. It works great and the code is only a few lines long.

The problem is then taking whatever messages are received by the ESP32 over to the Raspberry Pi. Yes, there’s UART (complicated and not entirely reliable) and there’s a serial port, and there’s the GPIO pins. But none of these are as simple (for the user) and as plug-and-play as a Breakout Garden board.

So I thought: what about an ESP32 mounted on a Breakout Garden board with an I2C interface? It would be similar to the IO Expander (whose MS51 is unfortunately inaccessible and 8051 assembly is an alien language to most) but, if there was a way to access the ESP32 via some pins on the board or maybe a USB port, then there’d be a general-purpose way to communicate between an ESP32 and the Raspberry Pi, as well as potentially use the ESP32 in a more general-purpose way, with communications (read and/or write) between it and the Raspberry Pi over the I2C bus. The parts for this are quite cheap and the benefit would be quite substantial.

An additional suggestion would be to add a single row of holes/connectors for just a few IO pins, e.g., TX (D43), RX (D44), and maybe a couple of GPIO pins, many of which can support either digital or analog IO.

I’ve suggested a product before and you guys built it (the PAA5100JE), so I know this is possible. I’d say an ESP32 on a Breakout Garden board would have even more functionality, and open up CircuitPython and MicroPython development on a Raspberry Pi subprocessor. I’d certainly be using a few of them on my next robot.

Thanks for considering this…

2

Do you know about this project: GitHub - thomasfla/Linux-ESPNOW: An attempt at implementing a direct link between a linux station and an ESP module using ESPNOW protocol for real time robot control?

3

Hi, thanks, that’s an interesting idea, sending WiFi packets from the ESP32 to the Pi. But that does introduce a different form of complexity than say, a UART, and doesn’t have any of the benefits of a wired connection. My thought is that if there’s an ESP32 sitting right next to the Raspberry Pi, what’s the most reliable way to intercommunicate? Certainly a wire (or two).

4

Oh, I misunderstood because you were talking about ESP-Now.

Of course a wire is the best solution if they are next to each other. I would opt for UART, because this is really simple compared to I2C. Of course if you hide the complexities of I2C behind a very good library, you won’t see anything of it from a user-perspective. But the same holds true for UART.

Plug-and-play is more a question of hardware design. It is no problem to create plug-and-play solutions for UART.

5

I’ve had very mixed experience with UARTs on a Raspberry Pi, and while the newer models like the Pi 4 and 5 have four, the older models such as the Pi 3 B+ or any of the Zeros have only one real UART. I’ve had to use a UART (which doesn’t work very well, maybe it’s just my code but I’ve tried it multiple times) simply because I’ve not been able to figure out how to make an I2C slave using an ESP32. I guess the reason I’m requesting an I2C-based product would be quite literally to hide the complexities of I2C behind a good library, as is the case with most of the existing Breakout Garden boards. I’m arguing for the convenience of an I2C product as demonstrated by the success (ease of use, convenience) of the Breakout Garden boards.

6

I still don’t fully understand the need for the ESP32 together with the Pi.

Does your ESP32 do more than being a communication interface for your handheld ESP32? If not, I would really try to skip the ESP32 and communicate directly with the Pi.

Otherwise: a programmer that could deal with implementing I2C slave mode in a “good library” would certainly also be able to hide the UART-implementation in a “good library”.

IMHO the main problem with this suggestion is that you are asking for a product that adds an interface for a MCU with WLAN/BT/GPIO capabilities to a product that already has all of these features. I can imagine that this maybe would make it easier to solve your problem, but I can’t imagine that Pimoroni will spend time and money for something like this.

7

It’s an extremely common paradigm, not only in robotics, but certainly in robotics. A master controller, and lots of smaller subprocessors, or slaves. That’s the basic idea behind both the Breakout Garden and Yukon series, i.e., you have a master (a Raspberry Pi in the case of Breakout Garden, an RP2040 in the case of Yukon), and one or more slave processors doing work. The IO Expander is, as an example, a subprocessor using an 8051 processor to handle IO, then communicating that back to the Pi.

So I have no idea why you think this is an unusual request. I have several robots, all controlled by Raspberry Pis, and I’d like to offload as much of the processing as possible, and certainly all of the real-time sensitive processing, to subprocessor boards. I’m currently building a Mars rover, which has six motors, six steering servos, and six sets of sensors (motor encoders as well as current/stall sensors), one for each assembly. I’d ideally like to have one subprocessor for each of those. So far, I’ve had to either connect via UART or GPIO, neither are so great and have very real limitations as I’ve described. The Pi doesn’t support six UARTs.

A subprocessor could be based on an ESP32, STM32, RP2040, etc. The benefit of the ESP32 is that it also has the ESP32-Now mesh network capability. This means that if Pimoroni were to make an IO Expander-like board with an ESP32 on board (and a USB connector to permit programming it), you’d have a massively functional IO Expander that could act as a subprocessor on a Raspberry Pi, and communicate with other ESP32s via Now. You could even use this to easily intercommunicate between Raspberry Pis over the mesh network. I don’t know why that’s a hard sell, but you clearly think I’m wrong so I’ll drop it.

PS. To answer your first question, there’s no way to use the ESP32-Now mesh network to communicate with the Raspberry Pi, only other ESP32s. So I need a transmitter and receiver, the latter on the robot with the Pi. So yes, I’m currently using the ESP32 receiver to receive messages from the transmitter, but I’m also using it to host a VL53L5CX ToF sensor. It could clearly do lots more, anything an ESP32 can do, which is why I suggested a USB connector so that it can be programmed, and not relegated solely to communicating ESP32-Now messages. I agree, if that’s all it was doing that would seem like quite a waste.