Wiznet makers

What the Project Does

This project enables an embedded microcontroller (ESP32-S3) to function as a native ROS 2 node communicating directly with a ROS 2 host over Ethernet.

Instead of relying on:

• Wi-Fi (which introduces latency and instability), or
• micro-ROS Agent (which requires an intermediate PC),

the system uses:

• mROS 2 (embedded ROS 2 runtime)
• RTPS over UDP/IP
• W5500-based wired Ethernet

As a result, the ESP32:

• participates directly in ROS 2 Pub/Sub
• subscribes and publishes topics
• operates as an independent network node

In practical terms, this means:

• A ROS 2 PC publishes data → ESP32 receives it directly
• No bridge, no agent, no Wi-Fi dependency

System Architecture

At a high level, the system is structured as a layered network stack running on the ESP32-S3:

Generated By Gemini

Application (ROS 2 Node)
    ↓
mROS 2 API
    ↓
embeddedRTPS (Discovery + Data)
    ↓
UDP/IP (lwIP)
    ↓
ESP-IDF Ethernet Driver
    ↓
SPI Interface
    ↓
W5500 (WIZ850io)
    ↓
Ethernet Network
    ↓
ROS 2 Host (Ubuntu)

This structure clearly separates:

• application logic (ROS 2)
• middleware (RTPS)
• transport (UDP/IP)
• physical interface (Ethernet via W5500)

System Block Diagram

[ROS 2 Host PC]
        │
        │ Ethernet
        ▼
   [Router / Switch]
        │
        ▼
[WIZ850io (W5500)]
        │  SPI
        ▼
   [ESP32-S3 MCU]
        │
        ▼
[mROS 2 Node Application]

The key takeaway is that WIZnet sits at the network boundary, bridging the MCU and the physical Ethernet network.

Where WIZnet Fits

This project uses the WIZnet W5500, embedded in the WIZ850io module.

Hardware Role

The W5500 is connected to the ESP32-S3 via SPI and provides:

• Ethernet PHY + MAC
• RJ45 connectivity
• External network interface

Software Role

W5500 is integrated at the ESP-IDF Ethernet driver layer:

esp_eth_mac_t *mac = esp_eth_mac_new_w5500(&w5500_config, &mac_config);
esp_eth_phy_t *phy = esp_eth_phy_new_w5500(&phy_config);

These functions:

• instantiate the W5500 MAC/PHY drivers
• register it as the system’s Ethernet interface

After initialization:

• DHCP assigns an IP address
• The IP is passed to RTPS via:

This step is critical:
it connects the ROS 2 communication stack to the physical Ethernet network via W5500.

Data Flow in the System

At runtime, communication follows a deterministic pipeline:

ROS 2 Message (Host)
    ↓
RTPS (Discovery + Data)
    ↓
UDP Packet
    ↓
lwIP Stack
    ↓
ESP-IDF Ethernet Driver
    ↓
W5500 (SPI)
    ↓
Ethernet Cable
    ↓
ESP32 Callback Execution

Incoming data is received through:

• RTPS discovery (SPDP, SEDP)
• UDP unicast payload
• callback execution in the application layer

This enables true end-to-end ROS 2 communication without intermediaries.

Why WIZnet is Used in This Project

The choice of W5500 is not incidental—it directly addresses the limitations of Wi-Fi-based embedded ROS systems.

1. Deterministic Communication

Wi-Fi introduces variable latency due to interference and contention.
Ethernet provides stable and predictable timing, which is critical for robotics.

2. Reliable Connectivity

Wired connections eliminate:

• signal drops
• reconnection issues
• RF interference

3. Clean Architecture

By separating:

• computation (ESP32)
• networking (W5500)

the system becomes:

• more modular
• easier to debug
• easier to scale

4. Practical Robotics Fit

The project explicitly targets ROS 2 environments where:

• real-time messaging matters
• network stability is more important than mobility

Key Takeaway

This project is not just an Ethernet add-on.

It demonstrates a complete architecture where:

• ESP32-S3 acts as a native ROS 2 node
• W5500 provides a stable wired network interface
• RTPS runs directly over Ethernet without middleware bridges

In short:

WIZnet W5500 enables embedded devices to participate in ROS 2 networks as first-class nodes, using reliable wired communication instead of unstable wireless links.