gsCar_RTOS — RT-Thread-Based Competition Smart Car Control System with W5500 LAN Broadcast

Recommended Components

• WIZnet W5500
• STM32F407IG / STM32F4 series
• RT-Thread RTOS
• lwIP / SAL Socket Layer
• CAN / ZigBee / Wi-Fi / Infrared modules
• RFID RC522
• Ultrasonic sensor
• Motor driver
• Serial camera module
• HLK-RM08K router or local LAN router

PROJECT DESCRIPTION

📌 Overview

gsCar_RTOS is not a control system for a real road vehicle. It is an RT-Thread-based control system for a small autonomous model car used in smart car competitions or embedded education. According to the project documentation, it runs on an STM32F407IG MCU and integrates path tracking, RFID recognition, sensor data processing, motor control, and multiple communication protocols. The main technology stack includes RT-Thread 4.0.3, STM32F407IG, CAN, ZigBee, Wi-Fi, infrared, RFID, ultrasonic sensing, gyroscope, and a camera module.

The most interesting WIZnet-related part of this repository is the W5500-based LAN UDP broadcast communication. While the original smart car system already uses CAN, ZigBee, Wi-Fi, and infrared communication, this project adds W5500 Ethernet so the car can send UDP broadcast messages on a local network and receive responses from a host device or other LAN nodes.

In other words, this is not just an example of connecting W5500 to the internet. It shows how Ethernet communication can be added into an RTOS-based model car control system so the car can exchange command requests and responses over a local LAN.

📌 What is a “Smart Car” in this Project?

In this project, “smart car” does not mean a commercial vehicle or an ECU system currently used in real cars. It refers to a small autonomous model car / robot car used in smart car competitions, embedded systems education, or robotics control practice.

These model cars usually include motors, line-tracking sensors, RFID readers, ultrasonic sensors, gyroscopes, cameras, and communication modules. They move around a predefined track or competition field and complete missions such as following a line, reading RFID tags, avoiding obstacles, recognizing signs, and communicating with field devices such as traffic lights, garages, gates, and display panels. This project also lists line tracking, path planning, RFID processing, ultrasonic ranging, PWM/PID motor control, and communication with competition markers as key functions.

So this project should be understood as an RTOS-based embedded robot car control project, not as a production automotive system. The W5500 is used to add an Ethernet channel so the model car can exchange UDP broadcast commands with a PC or upper-level controller on a local network.

📌 What This Project Does

The main purpose of this project is to control a smart model car and execute competition-style missions. The documentation lists line tracking, path planning, RFID tag processing, ultrasonic distance measurement, obstacle avoidance, motor PWM control, PID speed control, and communication with field markers as major functions.

The added LAN function allows the car to connect to a local network and exchange commands with a host device or PC over UDP. car_lan_client.c implements UDP broadcast and unicast using an 8-byte frame format, while a separate receive thread listens for incoming UDP packets and passes valid data to the main logic through an RT-Thread message queue.

The LAN communication is also used in the actual car control flow. In USER.c, the main task sends a 0xA0 command request every 5 seconds to ask the host device for instructions. Depending on the response command, the car may stop, start the full mission, or enter a solar-panel-related mode. The code also checks for emergency broadcast data in a non-blocking way.

📌 Features

• RT-Thread-based multi-threaded car control
  The project uses RT-Thread threads, message queues, and the FINSH shell. The documentation lists a main task thread, camera data processing thread, CAN receive thread, and shell thread.
• Competition smart car hardware integration
  The system integrates motors, line tracking, RFID, ultrasonic sensing, gyroscope, infrared, camera module, and CAN/ZigBee/Wi-Fi communication inside one RTOS-based project.
• W5500 Ethernet extension
  The W5500 is connected over SPI. The repository includes W5500 register definitions, SPI read/write code, reset handling, MAC/IP/gateway/netmask configuration, and version register checking.
• LAN UDP broadcast communication
  The car sends UDP broadcast packets to 192.168.16.255:5678 and listens for responses on the same port. This allows a host PC or another LAN device to receive the car’s request and send back control commands.
• 8-byte frame format compatible with existing competition-style commands
  The LAN frame format is [0x55] [SRC] [CMD] [D1] [D2] [D3] [CHK] [0xBB]. This is similar to the project’s existing ZigBee / marker communication format, making it easier to extend existing command logic to LAN communication.

📌 System Architecture

The project can be understood as several layers: RT-Thread Kernel, Driver Layer, Hardware Abstraction Layer, Application Layer, and Communication Layer.

The Application Layer includes files such as main.c, USER.c, Task_Program.c, Car_drive.c, and CarRecognition.c. This layer handles vehicle movement, mission execution, Wi-Fi/camera data processing, and communication with competition field markers. The Hardware Layer includes modules for motors, RFID, ultrasonic sensing, infrared, gyroscope, camera, and CAN communication.

The W5500 LAN path works like an additional Ethernet communication layer. In main.c, the system initializes the basic hardware, waits about two seconds, starts the W5500 through rt_hw_wiznet_init(), and then starts the LAN broadcast client through car_lan_init(). After that, the main task thread and camera processing thread are launched.

LAN communication uses a background receive thread and a message queue. When UDP data is received, the frame format and checksum are checked first. Only valid packets are passed into the lan_rx message queue. The main loop then reads responses or emergency commands from that queue and applies them to the car’s behavior.

📌 Role and Application of the WIZnet Chip

WIZnet chip used: W5500

In this project, the W5500 adds a wired LAN communication path to the smart model car. The existing car system already uses communication methods such as CAN, ZigBee, Wi-Fi, and infrared, but by adding W5500 Ethernet, the car can communicate more directly with a host PC, router, or control server over IP networking.

The LAN setup example shows the STM32 connected to W5500 over SPI, and the W5500 Ethernet lines connected to the LAN port of an HLK-RM08K router. The documented network is 192.168.16.0/24, with the car using broadcast address 192.168.16.255 and port 5678.

The W5500 driver code directly implements SPI register access. w5500_spi.c reads and writes W5500 registers using a 16-bit address and control byte, performs hardware and software reset, checks the VERSIONR register, and provides functions for setting the MAC address, IP address, gateway, and netmask.

📌 Network Stack Note

The W5500 path in this project is best understood as an RT-Thread SAL + lwIP network interface implementation, not as a direct TOE/socket-library implementation.

rtconfig.h explicitly enables RT_USING_SAL, SAL_USING_POSIX, SAL_USING_LWIP, RT_USING_LWIP, RT_USING_LWIP212, RT_LWIP_UDP, RT_LWIP_TCP, RT_USING_NETDEV, RT_USING_WIZNET, and PKG_USING_WIZNET. This means the application uses POSIX-style socket APIs, while lwIP handles the TCP/IP stack underneath.

wiznet_init.c also initializes W5500 and then registers it as an lwIP network interface using netif_add() with ethernet_input. This shows that the W5500 is being attached to the RT-Thread/lwIP network stack as a network interface.

The upper-level LAN communication code does not directly call WIZnet ioLibrary-style APIs such as WIZnet send() or recv(). Instead, it uses RT-Thread SAL/POSIX socket APIs such as socket(AF_INET, SOCK_DGRAM, 0), setsockopt(), bind(), sendto(), and recvfrom().

So this project should be described as a RT-Thread example that registers W5500 as an Ethernet interface and implements UDP broadcast on top of lwIP sockets, rather than as a direct W5500 hardwired socket engine example.

📌 Hybrid Network Status

In a broad sense, this is a smart car project with multiple communication channels. The project documentation includes CAN, ZigBee, Wi-Fi, infrared, and W5500 LAN.

However, it should not be interpreted as a wired/wireless hybrid network router. The project does not bridge W5500 Ethernet and Wi-Fi, nor does it combine them into one routed network.

A more accurate description is that this is an RTOS smart car project with multiple control communication paths. CAN is used for internal device communication, ZigBee and infrared are used for field markers or nearby devices, Wi-Fi is used as an existing upper-level communication path, and W5500 Ethernet is added as a LAN broadcast command channel.

📌 Implementation Notes

The most important files to check first are rtconfig.h and LAN_UDP_BROADCAST.md. rtconfig.h contains SAL, lwIP, UDP/TCP, DHCP, WIZnet, and SPI settings, while LAN_UDP_BROADCAST.md explains W5500 wiring, SPI pins, LAN broadcast frames, and test commands step by step.

One thing to note is that the documentation mixes board references. The main project document describes an STM32F407IG-based smart car system, while the LAN UDP broadcast guide uses an STM32F103VC + W5500 example. When adapting the project, users should adjust the SPI pins and RT-Thread BSP settings according to their actual board.

The W5500 SPI setup in w5500_spi.c looks for a device named spi10, configures SPI mode 0 at 20 MHz, and reads the W5500 version register. If the version register reads as zero, the code prints a message telling the user to check the SPI wiring. This is useful during W5500 bring-up.

LAN communication testing is also available through FINSH shell commands. car_lan_test sends a test broadcast and waits three seconds for a response. LAN_UDP_BROADCAST.md also lists commands such as car_net_info, car_lan_test, ifconfig, and list_thread for debugging.

📌 Why This Project Is Useful

This project is a useful example of using W5500 not just as a simple Ethernet add-on, but as a LAN command channel for a robot / smart model car control system.

In many robot or model car projects, UART, CAN, Wi-Fi, or ZigBee are used first. But if a host PC, local server, or router is available, Ethernet-based UDP broadcast can be a simple and clear way to send and receive control commands. This project places that idea directly inside an RT-Thread-based vehicle control system.

UDP broadcast is especially useful when:

• the car does not know the host PC IP address in advance
• the system needs to discover a command server on the same LAN
• multiple devices need to hear the same command
• quick control frames need to be exchanged with minimal overhead
• the car is operating in a competition field or lab LAN

Another useful point is that the LAN frame format is similar to the existing ZigBee / vehicle command frame. That means the command system can be extended to LAN without redesigning the entire protocol.

📌 Additional Insight for W5500 Makers

The key insight from this project is the combination of W5500 + RTOS + lwIP + UDP broadcast. Instead of using W5500 only for a web server or TCP echo demo, this project connects W5500 communication with RT-Thread threads and message queues inside a vehicle control flow.

The W5500 bring-up path is also educational. The project separates SPI register read/write, reset, version check, MAC/IP configuration, lwIP network interface registration, and socket-based UDP broadcast into understandable stages. This makes it useful for learning how to add Ethernet to an RTOS-based embedded system.

Makers could adapt this structure for applications beyond smart cars:

• LAN-based robot control nodes
• UDP broadcast-based device discovery
• RT-Thread sensor or actuator controllers
• embedded networking training with wired Ethernet
• local control networks for labs or competition fields where Wi-Fi is unreliable

This is not the right example for users who specifically want to use the W5500 internal hardwired socket API directly. It is better described as an example of using W5500 as an RT-Thread/lwIP network interface and accessing it through POSIX socket APIs.

📌 Things to Know Before Building

This project is not a single-board demo. It adds W5500 LAN communication into a larger smart car control system, so several details should be checked before building.

Important checks include:

• whether the target MCU/BSP is STM32F4-based, or whether the STM32F103VC example must be adapted
• whether SPI1 pins and W5500 CS/RST/INT pins match the actual wiring
• whether SAL, lwIP, UDP, DHCP, WIZnet, and SPI are enabled in rtconfig.h
• whether the spi10 device is actually registered
• whether the W5500 VERSIONR value can be read correctly
• whether the LAN subnet is really 192.168.16.0/24
• whether the host PC is listening on UDP port 5678

The documentation also includes flows for testing broadcast reception from the PC side and debugging through the FINSH shell.

📌 Summary

gsCar_RTOS is not a real road-vehicle project. It is an RT-Thread-based competition / educational autonomous model car control system. It uses STM32F407IG, CAN, ZigBee, Wi-Fi, infrared, RFID, ultrasonic sensing, gyroscope, and a camera module to complete smart car competition missions.

The key WIZnet-related feature is the LAN UDP broadcast extension using W5500. The car connects to a local network through W5500 Ethernet and can send 8-byte command frames to 192.168.16.255:5678, or send unicast packets to a specific IP address.

The network stack is RT-Thread SAL + lwIP, not direct W5500 TOE socket usage. W5500 is registered as an lwIP network interface, and the application handles UDP broadcast through POSIX socket APIs.

📌 FAQ

Q1. Is this project for a real vehicle?
No. It is a small autonomous model car / robot car control project for smart car competitions or embedded systems education.

Q2. Which WIZnet chip is used?
The project uses WIZnet W5500. It is connected over SPI and used as an Ethernet interface for LAN UDP broadcast communication.

Q3. Does it directly use the W5500 TOE/socket engine?
No. Based on rtconfig.h and the initialization code, it uses the RT-Thread SAL + lwIP network interface path. The application uses POSIX socket APIs.

Q4. What is UDP broadcast used for?
It allows the car to send command requests to a host PC or control device on the same LAN and receive responses that can change driving state or mission mode.

Q5. What does the communication frame look like?
It uses an 8-byte frame: [0x55] [SRC] [CMD] [D1] [D2] [D3] [CHK] [0xBB].

Q6. Is this a wired/wireless hybrid network example?
Broadly, it is a smart car project with multiple communication paths: CAN, ZigBee, Wi-Fi, infrared, and W5500 LAN. However, it is not a Wi-Fi/Ethernet bridge. It is better understood as an RTOS vehicle-control project with multiple communication channels.

Q7. What should be checked before building?
Check W5500 SPI wiring, spi10 registration, SAL/lwIP/WIZnet configuration, LAN subnet, and UDP port 5678 settings first.