Wiznet makers

Summary

NHKRobocon2025B는 고센 로보콘(전국 고등전문학교 로봇콘테스트) 2025에 출전한 **TMCIT Arakawa B Team(産技高専荒川 B팀)**의 로봇 시스템 결과물을 담은 메인 펌웨어 리포지토리입니다. 2025년 과제는 “Great High Gate”로, 로봇이 박스를 쌓아 게이트를 만들고 사람을 태운 대차와 함께 통과하며 점수를 겨루는 경기입니다. 이 레포는 그 로봇의 유선 제어 링크를 **WIZnet W5500 기반 Ethernet(UDP)**로 구성해, PC(ROS2 포함)에서 들어오는 조작 데이터를 고정 크기 바이너리 구조체로 받아 주행/기구 목표값을 갱신하는 방식을 중심으로 정리합니다.

What the Project Does

이 리포지토리는 로봇 기능을 보드 단위로 분리한 멀티 MCU 펌웨어 구성을 갖습니다. 메인 제어는 GN10Mainboard가 맡고, 차세대 메인보드로 보이는 mainboardv2, LED 전용 보드, ToF 센서 값을 CAN으로 변환해 올리는 브릿지 보드가 함께 들어 있습니다.

로봇의 상위 데이터 흐름은 단순합니다.

PC/ROS2 → (Ethernet UDP) → GN10Mainboard: 조작(속도/기구 목표값) 전달

GN10Mainboard → (CAN 등) → 하위 드라이버/보드: 모터/기구 구동

센서/상태 → GN10Mainboard → (Ethernet UDP) → PC/ROS2: 피드백 전달

이미지 출처 : AI 생성

Where WIZnet Fits

이 프로젝트는 WIZnet Makers 카드에서 W5500 을 사용하며 태그가 W5500/STM32, 분야가 Robotics로 표기돼 있습니다. 
W5500은 Hardwired TCP/IP 기반의 이더넷 컨트롤러로, MCU가 복잡한 네트워크 스택을 직접 다루기보다 소켓 중심(UDP 포함)으로 통신을 구성하기 쉽습니다. 또한 32KB 내장 버퍼와 8개 하드웨어 소켓, SPI(최대 80MHz) 같은 특성으로 “제어 패킷을 짧게, 반복적으로” 주고받는 로봇 제어 링크에 잘 맞습니다.

BLE 수동조작 로직은 코드가 존재하지만 기본은 컴파일 플래그로 비활성화되어 있고, 활성화하더라도 UDP 조작이 들어오지 않을 때만 BLE 입력을 적용하도록 조건이 걸려 있습니다. “유선이 우선, 무선은 백업”이라는 운영 의도가 코드로 고정돼 있는 셈입니다.

Practical Tips / Pitfalls

구조체 바이너리 방식은 빠르고 단순하지만, PC/MCU 양쪽이 같은 구조체 레이아웃을 공유해야 합니다(필드 추가/정렬 변경에 민감).

UDP는 유실이 가능하므로, 조작 데이터는 보통 “최신값 우선”으로 운영하고 송신 주기/타임아웃 정책을 함께 잡는 편이 안정적입니다.

헤더로 타입은 구분하지만, 장기 운영에서는 버전/시퀀스 같은 최소 메타데이터가 있으면 디버깅이 쉬워집니다(특히 대회 중 수정이 잦을 때).

“유선 우선 + BLE 백업”을 쓴다면, 실제 대회 환경에서 **UDP 미수신 상황(케이블 이탈 등)**을 가정한 전환 테스트를 반드시 해두는 게 좋습니다.

대회 동영상 : https://www.youtube.com/live/Rww-ndFlu7c?si=rnUFeJlKmlL_iWsL

FAQ

왜 이 프로젝트는 W5500을 선택했나요?
로보콘에서는 제어 링크의 예측 가능성이 중요합니다. W5500은 Hardwired TCP/IP 기반이라 MCU가 네트워크 스택 유지 부담을 줄이고 소켓 기반(UDP) 통신을 단순하게 구성하기 쉽습니다. 또한 32KB 내장 버퍼와 8 소켓 같은 특성은 반복적인 제어/피드백 패킷에 유리합니다.

W5500은 STM32 보드와 어떻게 연결되나요?
W5500은 SPI로 외부 MCU와 인터페이스하는 구조를 전제로 합니다. 이 프로젝트도 W5500/STM32 조합을 사용하며, 보드에서 W5500이 Ethernet(UDP) 링크를 담당하는 형태입니다.

이 프로젝트에서 W5500은 정확히 어떤 역할을 하나요?
PC(ROS2 포함)와 GN10Mainboard 사이의 유선 UDP 경로를 제공해, operation_data_t 같은 조작 패킷을 안정적으로 수신하고 로봇 제어 루프에 반영하게 합니다.

초보자도 이 방식(구조체 기반 UDP)을 따라 할 수 있나요?
가능합니다. 다만 구조체 바이너리 프로토콜은 PC/MCU가 같은 정의를 공유해야 하므로, 초기에 “구조체 정의(헤더 포함)를 단일 소스로 관리”하고 테스트 도구(PC 송수신)부터 만드는 접근이 안전합니다.

Wi-Fi 대신 유선 UDP를 메인으로 두는 이유는 뭔가요?
대회 환경에서는 전파 혼잡, 연결 상태, 지연 변동이 운영 리스크가 될 수 있습니다. 이 프로젝트는 유선 UDP를 기본 조작 경로로 두고, BLE를 백업으로 설계해 “가능하면 유선으로 확실히”라는 운영 방향을 취하고 있습니다.

Summary

NHKRobocon2025B is the main firmware repository that captures the robot system outcome built by TMCIT Arakawa B Team (産技高専荒川 B Team) for Kosen Robocon (National College of Technology Robot Contest) 2025. The 2025 theme, “Great High Gate,” is a game where robots stack boxes to build a gate and then pass through it together with a cart carrying a person, competing for points. This repository focuses on how the robot’s wired control link is implemented using WIZnet W5500–based Ethernet (UDP): control inputs from a PC (including ROS2) are received as fixed-size binary structs, which are then used to update driving and mechanism targets.

What the Project Does

This repository uses a multi-MCU firmware architecture, splitting robot functions by board. GN10Mainboard serves as the primary controller, alongside mainboardv2 (a next-generation mainboard), a dedicated LEDBoard, and a bridge board that converts ToF sensor readings to CAN.

At a high level, the data flow is straightforward:

PC/ROS2 → (Ethernet UDP) → GN10Mainboard: sends operation commands (velocity + mechanism targets)

GN10Mainboard → (CAN, etc.) → downstream drivers/boards: drives motors and mechanisms

Sensors/state → GN10Mainboard → (Ethernet UDP) → PC/ROS2: sends feedback

Image source: AI-generated

Where WIZnet Fits

On the WIZnet Makers project card, this project is labeled as Robotics with tags W5500/STM32, indicating use of the W5500. The W5500 is a Hardwired TCP/IP Ethernet controller, which makes it easier to build socket-based communication (including UDP) without running a heavy network stack on the MCU. With features such as an internal 32KB buffer, 8 hardware sockets, and SPI (up to 80MHz), it suits robot control links where short control packets are exchanged repeatedly.

The BLE manual-control logic exists in the codebase, but it is disabled by default via a compile-time flag. Even when enabled, BLE inputs are only applied when UDP operation data is not being received. In other words, the code locks in the operating intent: wired control is primary, wireless control is a fallback.

Practical Tips / Pitfalls

A struct-based binary protocol is fast and simple, but both the PC and MCU must share the exact same struct layout (it is sensitive to field additions and alignment changes).

Because UDP can drop packets, it’s typically safest to operate on a “latest value wins” basis and define a clear transmit rate and timeout policy.

Even if a header distinguishes packet types, long-term maintenance is easier if you include minimal metadata such as a version and sequence number—especially when changes happen frequently during competition season.

If you use “wired primary + BLE backup,” you should run explicit switch-over tests under real match-like conditions, including UDP loss scenarios (e.g., cable unplugged).

Competition video: https://www.youtube.com/live/Rww-ndFlu7c?si=rnUFeJlKmlL_iWsL

FAQ

Why did this project choose the W5500?
In Robocon, predictability of the control link matters. Since the W5500 is based on Hardwired TCP/IP, it reduces the MCU burden of maintaining a full network stack and enables a straightforward socket-style (UDP) design. Its internal 32KB buffer and 8 sockets are also helpful for repetitive control/feedback packet exchange.

How does the W5500 connect to an STM32 board?
The W5500 is designed to interface with an external MCU over SPI. This project uses a W5500/STM32 combination where the W5500 handles the Ethernet (UDP) link for the board.

What exactly is the W5500’s role in this project?
It provides the wired UDP path between the PC (including ROS2) and GN10Mainboard, allowing operation packets such as operation_data_t to be received reliably and applied to the robot control loop.

Can beginners follow this approach (struct-based UDP)?
Yes. However, because a struct-based binary protocol requires the PC and MCU to share an identical definition, it’s safest to treat the struct definitions (including headers) as a single source of truth and build PC-side send/receive test tools early.

Why use wired UDP as the main link instead of Wi-Fi?
In competition venues, RF congestion, link quality, and latency variation can become operational risks. This project uses wired UDP as the primary control path and designs BLE as a backup channel, following the operating principle: use wired when possible for reliability.