Wiznet makers

Project Overview

OneTouch is a brokerless messaging and robot-control project built around Java 21, JeroMQ/ZeroMQ, virtual threads, and an embedded Ethernet motor-controller bridge. Although the top-level README introduces it as a general-purpose messaging library for distributed systems, robotics, and microservices, the repository also contains a broader robotics stack covering motor control, discovery, dashboards, sensors, simulation, SLAM-related components, and deployment programs for Jetson and laptop environments.

Project Type

• Brokerless Java messaging framework
• Distributed robot-control system
• Embedded Ethernet-to-motor-controller bridge
• Robotics development and simulation reference
• Multi-language project using Java, Arduino/C++, Python, HTML, and supporting scripts

Primary Software Stack

• Java 21
• JeroMQ 0.6.0
• Project Loom virtual threads
• Protocol Buffers and FlatBuffers
• jMonkeyEngine for simulation and visualization
• jSerialComm for serial-connected devices
• Arduino-Pico networking and firmware components

Primary Hardware Stack

• WIZnet W5100S-EVB-Pico2
• ODrive S1 or ODrive Pro
• Hub motor with Hall sensors
• Jetson-class host computer or another Java-capable controller

Technical Characteristics

The Java messaging layer wraps ZeroMQ communication patterns including PUB/SUB, PUSH/PULL, and REQ/REP. Telemetry is modeled as latest-data-oriented PUB/SUB traffic, commands can use queued PUSH/PULL or synchronous REQ/REP communication, and reliability components include heartbeat monitoring, retries, and duplicate-command detection.

The embedded OneTouchBridge implements a compact binary motor-control protocol. Frames begin with the OT magic value and contain message type, flags, payload length, and payload data. Defined messages include motor telemetry, commands, command responses, heartbeat data, safety events, and discovery beacons. Command IDs support idempotent processing and response correlation.

The repository contains two partly overlapping embedded communication designs:

1. The Arduino README documents TCP telemetry on port 5580, TCP commands on port 5581, and UDP multicast discovery on port 5670.
2. The current firmware and Java MotorController use UDP port 5582 for telemetry and TCP port 5581 for commands. The firmware explicitly leaves the legacy TCP telemetry server disabled because TCP backpressure could block the control loop.

The direct motor-control implementation should therefore be interpreted as:

• Telemetry: UDP 5582
• Commands and responses: TCP 5581
• Discovery: UDP multicast 239.0.0.1:5670
• ODrive interface: UART at 115200 bit/s

System Architecture

Control Path

Remote controller or laptop
→ OneTouch/ZeroMQ command service
→ Jetson robot service
→ Java MotorController
→ TCP command connection on port 5581
→ W5100S-EVB-Pico2
→ Binary command decoding
→ UART Serial2 at 115200 bit/s
→ ODrive motor controller
→ Motor

The Jetson service loads configuration, creates robot controllers and sensors, publishes system status, responds to remote commands, and maintains health monitoring. The Pico-side bridge translates network commands into ODrive UART operations such as velocity control, position control, stop, hold, calibration, error clearing, and safety-system control.

Telemetry Path

ODrive state
→ UART
→ OneTouchBridge
→ Binary telemetry frame
→ UDP port 5582
→ Java MotorController
→ Robot service, dashboard, or application logic

The telemetry structure includes velocity, position, torque, current, temperature, bus voltage, error flags, sequence number, motor state, and control mode. The configured publication interval is 50 ms, corresponding to a nominal 20 Hz update rate.

Discovery and Messaging Integration

The embedded node periodically advertises itself through UDP multicast. Java clients can locate a node by its logical ID and then create the telemetry and command communication paths. A separate PicoBridge component is designed to discover Pico nodes and republish their data through ZeroMQ for dashboards and subscribers.

The PicoBridge source still expects a TCP telemetry stream and a text-formatted message path, while the current MotorController and firmware use the binary v2 protocol with UDP telemetry. This indicates that the repository retains legacy or partially migrated communication components.

Safety Path

Jetson heartbeat
→ Pico heartbeat timeout monitoring
→ ODrive watchdog feed
→ Motor stop on communication or controller failure

The firmware implements multiple safety layers:

• A Jetson heartbeat command is normally transmitted every 100 ms.
• The current firmware stops the motor if the Jetson heartbeat is absent for 750 ms.
• The Pico feeds the ODrive watchdog every 100 ms.
• The ODrive watchdog timeout is configured to 500 ms.
• A separate command watchdog stops motion after prolonged absence of velocity commands.
• An MCU hardware watchdog recovers the controller from firmware stalls.

The Arduino README still lists a 500 ms Jetson timeout, while the current firmware constant is 750 ms. The source code is the more direct representation of the present implementation.

WIZnet Product Assessment

WIZnet Product Used: Yes

Product: WIZnet W5100S-EVB-Pico2

WIZnet Product Role:
The W5100S provides the embedded node’s SPI-based wired Ethernet connection. It carries motor commands, telemetry, service discovery, and OTA-related network traffic between the Java host and the Pico motor-controller bridge.

Network Software Path

WiFiServer / WiFiClient / WiFiUDP compatibility APIs
→ Arduino-Pico lwIP networking layer
→ Wiznet5100lwIP driver
→ W5100S Socket 0 in MACRAW mode
→ SPI
→ Wired Ethernet

The WiFiServer, WiFiClient, and WiFiUDP class names do not indicate an active Wi-Fi connection in this project. Arduino-Pico reuses Wi-Fi-compatible networking APIs for its wired Ethernet lwIP implementation.

TOE Usage

TOE Usage: No, not for application-level TCP/IP offload

The W5100S contains a hardwired TCP/IP engine, but this implementation does not use its hardware TCP and UDP socket functions as the application network stack. The Wiznet5100lwIP driver opens W5100S Socket 0 in MACRAW mode and passes raw Ethernet frames to software lwIP. TCP, UDP, DHCP, and socket processing are therefore handled primarily by the MCU-side lwIP stack rather than by the W5100S hardwired TCP/IP engine.

Implementation Classification

• Direct W5100S hardware TCP/UDP socket control: No
• Standard Arduino Ethernet library using W5100S TOE sockets: No
• ESP-IDF esp_eth / esp_netif path: No
• Other framework or driver: Yes
• Actual path: Arduino-Pico EthernetLWIP with Wiznet5100lwIP in MACRAW mode
• W5100S role: Raw Ethernet frame interface over SPI
• Hardware TCP/IP offload benefit: Not exercised by the current network architecture

This project is consequently relevant as a W5100S Ethernet integration example, but it is not a representative example of WIZnet hardware-socket TOE operation.

Hybrid Network Assessment

Hybrid Network: No

No simultaneous wired Ethernet and wireless network path is confirmed in the repository. The embedded motor controller uses the W5100S wired Ethernet interface. The use of classes named WiFiServer, WiFiClient, and WiFiUDP results from the Arduino-Pico compatibility API and does not establish that Wi-Fi radio communication is active.

The top-level README’s term “Hybrid Patterns” refers to combining messaging patterns such as PUB/SUB and PUSH/PULL. It does not mean a hybrid wired-and-wireless network.

Strengths

1. End-to-End Robotics Integration

The repository extends beyond an isolated networking example. It connects Java messaging, robot services, embedded firmware, motor control, telemetry, discovery, dashboards, simulation, and safety mechanisms into a single development tree.

2. Separation of Control and Telemetry

Commands use a TCP request-response path, while current telemetry uses non-blocking UDP. This prevents slow telemetry consumers or TCP backpressure from directly stalling the motor-control loop.

3. Compact Binary Protocol

The binary protocol defines bounded frame sizes, message types, correlation IDs, sequence numbers, and idempotent commands. These characteristics are suitable for an embedded controller with limited memory and deterministic message-processing requirements.

4. Layered Safety Mechanisms

Heartbeat supervision, ODrive watchdog feeding, command inactivity detection, emergency-stop commands, and a hardware watchdog provide multiple independent failure responses rather than relying on a single network timeout.

5. Automatic Discovery and Reconnection

Java clients support multicast-based node discovery, connection-state tracking, heartbeat transmission, timeout detection, and automatic reconnection. This reduces dependence on fixed IP addresses during development and field replacement.

Limitations

1. Documentation and Source-Code Drift

The Arduino README describes TCP telemetry on port 5580 and a 500 ms Jetson timeout. The current firmware disables the TCP telemetry server, uses UDP port 5582, and defines a 750 ms Jetson timeout. Java builder comments also retain references to the old port arrangement.

2. Coexistence of Legacy and Current Protocol Paths

PicoBridge expects a TCP and text-oriented telemetry stream, while the current direct motor client uses binary UDP telemetry. A unified protocol version and removal or explicit labeling of legacy components would be required for an unambiguous deployment architecture.

3. TOE Capability Is Not Used

Software lwIP performs TCP/IP processing because the W5100S operates in MACRAW mode. This increases MCU networking responsibility and does not demonstrate the deterministic hardware-socket behavior normally associated with WIZnet TOE products.

4. Performance Results Are Repository-Reported

The Arduino documentation reports approximately 2–5 ms command latency, 20 Hz telemetry, and a 500 ms safety timeout. Dedicated benchmark source data, network captures, repeatability conditions, and hardware test reports are not included in the inspected materials.

The top-level README separately claims microsecond-level messaging latency for its brokerless ZeroMQ layer. That claim concerns the messaging framework and should not be treated as measured end-to-end motor-control latency.

5. Early Repository Maturity

The repository currently shows one initial commit dated January 12, 2026, no published release, and no additional public commit history. This limits evidence of long-term maintenance, regression handling, and release stability.

6. Security Definition Is Incomplete

Transport encryption, device authentication, command authorization, and secure discovery are not documented in the inspected README and primary communication paths. These controls would be required when the control network is exposed beyond a physically isolated robot network.

Application Value

OneTouch provides useful reference material for:

• W5100S-based wired robot-controller nodes
• Jetson-to-embedded motor-control communication
• TCP command and UDP telemetry separation
• Cross-language binary protocol implementation
• ODrive Ethernet gateway development
• Multicast device discovery
• Heartbeat and watchdog safety chains
• Java virtual-thread-based robotics services
• Bridging embedded telemetry into a ZeroMQ service network

Its strongest value is the integration of messaging software, embedded Ethernet firmware, and actual motor-control safety logic. Its value as a TOE example is limited because the W5100S hardware TCP/IP sockets are bypassed in favor of MACRAW and software lwIP.

For production deployment, the protocol documentation, current port assignments, legacy bridge components, security model, automated integration tests, and reproducible performance measurements would need further consolidation.

Author Information

Author: Devin Willis
GitHub Account: gatordevin
Initial Commit: January 12, 2026
Initial Commit Description: “Initial commit: OneTouch robot control system”
License: MIT

OneTouch: W5100S 기반 유선 이더넷 모터 제어 및 로봇 메시징 스택

프로젝트 개요

OneTouch는 Java 21, JeroMQ/ZeroMQ, Virtual Thread와 임베디드 Ethernet Motor Controller를 결합한 brokerless 메시징 및 로봇 제어 프로젝트다. 최상위 README는 분산 시스템, 로봇, microservice를 위한 범용 메시징 라이브러리로 프로젝트를 정의하지만, 실제 저장소에는 Motor Control, Device Discovery, Dashboard, Sensor, Simulation, SLAM 관련 구성과 Jetson·Laptop 배포 프로그램까지 포함되어 있다.

프로젝트 유형

• Brokerless Java 메시징 프레임워크
• 분산 로봇 제어 시스템
• Embedded Ethernet-to-Motor Controller Bridge
• 로봇 개발 및 Simulation Reference
• Java, Arduino/C++, Python, HTML과 실행 Script를 포함한 복합 프로젝트

주요 소프트웨어 구성

• Java 21
• JeroMQ 0.6.0
• Project Loom Virtual Thread
• Protocol Buffers 및 FlatBuffers
• Simulation과 Visualization을 위한 jMonkeyEngine
• Serial Device 연동을 위한 jSerialComm
• Arduino-Pico Network 및 Firmware 구성

주요 하드웨어 구성

• WIZnet W5100S-EVB-Pico2
• ODrive S1 또는 ODrive Pro
• Hall Sensor가 포함된 Hub Motor
• Jetson 계열 Host 또는 Java 실행이 가능한 제어 컴퓨터

기술적 특징

Java 메시징 계층은 ZeroMQ의 PUB/SUB, PUSH/PULL, REQ/REP 패턴을 Wrapper 형태로 제공한다. Telemetry는 최신 데이터 전달에 적합한 PUB/SUB, 작업과 명령은 PUSH/PULL, 동기 요청은 REQ/REP로 구분하며 Heartbeat, Retry, Duplicate Command Detection 기능도 포함한다.

Embedded OneTouchBridge는 Motor Control용 Compact Binary Protocol을 구현한다. Frame은 OT Magic Value, Message Type, Flag, Payload Length, Payload로 구성되며 Motor Telemetry, Command, Response, Heartbeat, Safety Event, Discovery Beacon을 구분한다. Command ID는 중복 실행 방지와 Response Correlation에 사용된다.

저장소에는 일부 중첩되는 두 가지 Embedded 통신 구조가 존재한다.

1. Arduino README는 TCP 5580 Telemetry, TCP 5581 Command, UDP 5670 Multicast Discovery 구조를 설명한다.
2. 현재 Firmware와 Java MotorController는 UDP 5582를 Telemetry에 사용하고 TCP 5581을 Command에 사용한다. Firmware는 TCP Backpressure가 제어 Loop를 정지시킬 수 있다는 이유로 기존 TCP Telemetry Server를 시작하지 않는다.

현재 Direct Motor Control 경로는 다음과 같이 해석된다.

• Telemetry: UDP 5582
• Command 및 Response: TCP 5581
• Discovery: UDP Multicast 239.0.0.1:5670
• ODrive Interface: UART 115200 bit/s

시스템 구조와 동작 흐름

제어 흐름

Remote Controller 또는 Laptop
→ OneTouch/ZeroMQ Command Service
→ Jetson Robot Service
→ Java MotorController
→ TCP 5581 Command Connection
→ W5100S-EVB-Pico2
→ Binary Command Decode
→ UART Serial2 115200 bit/s
→ ODrive Motor Controller
→ Motor

Jetson Service는 설정을 불러오고 Motor Controller와 Sensor를 생성하며, 시스템 상태 발행, Remote Command 처리, Device Discovery와 Health Monitoring을 담당한다. Pico Bridge는 수신한 Binary Command를 Velocity, Position, Stop, Hold, Calibration, Error Clear, Safety Control과 같은 ODrive UART 명령으로 변환한다.

Telemetry 흐름

ODrive 상태
→ UART
→ OneTouchBridge
→ Binary Telemetry Frame
→ UDP 5582
→ Java MotorController
→ Robot Service, Dashboard 또는 Application Logic

Telemetry에는 Velocity, Position, Torque, Current, Temperature, Bus Voltage, Error Flag, Sequence Number, Motor State와 Control Mode가 포함된다. Firmware의 전송 간격은 50 ms로 설정되어 있으며 명목상 20 Hz로 상태를 갱신한다.

Discovery 및 메시징 연계

Embedded Node는 UDP Multicast로 자신의 Node ID와 Service 정보를 알린다. Java Client는 논리적인 Node ID로 Pico를 검색한 뒤 Telemetry와 Command 통신 경로를 생성한다. 별도의 PicoBridge는 Pico Node를 자동 검색하고 수신 데이터를 ZeroMQ Network에 재발행하여 Dashboard와 Subscriber가 이용하도록 설계되어 있다.

다만 PicoBridge 소스는 TCP Telemetry와 Text Message를 전제로 하는 반면, 현재 MotorController와 Firmware는 Binary v2 Protocol과 UDP Telemetry를 사용한다. Legacy 통신 구성과 신규 구현의 Migration이 완전히 정리되지 않은 상태로 판단된다.

안전 제어 흐름

Jetson Heartbeat
→ Pico Heartbeat Timeout 감시
→ ODrive Watchdog Feed
→ 통신 또는 Controller 장애 시 Motor Stop

Firmware에는 다음과 같은 다중 안전 계층이 구현되어 있다.

• Jetson은 기본적으로 100 ms 간격으로 Heartbeat Command를 전송한다.
• 현재 Firmware는 Jetson Heartbeat가 750 ms 동안 없으면 Motor를 정지한다.
• Pico는 100 ms 간격으로 ODrive Watchdog을 갱신한다.
• ODrive Watchdog Timeout은 500 ms로 설정된다.
• 일정 시간 동안 Velocity Command가 없으면 별도의 Command Watchdog이 Motor를 정지한다.
• MCU Hardware Watchdog은 Firmware Hang 발생 시 Controller를 재시작한다.

Arduino README에는 Jetson Timeout이 500 ms로 기록되어 있지만 현재 Firmware 상수는 750 ms다. 현재 구현 상태는 소스 코드의 750 ms 설정을 기준으로 판단해야 한다.

WIZnet 제품 사용 여부

WIZnet 제품 사용: 사용함

사용 제품: WIZnet W5100S-EVB-Pico2

WIZnet Product Role:
W5100S는 Embedded Motor Controller Node의 SPI 기반 유선 Ethernet Interface를 담당한다. Java Host와 Pico Bridge 사이에서 Motor Command, Telemetry, Device Discovery와 OTA 관련 Network Traffic을 전달한다.

Network Software 경로

WiFiServer / WiFiClient / WiFiUDP 호환 API
→ Arduino-Pico lwIP Network Layer
→ Wiznet5100lwIP Driver
→ W5100S Socket 0 MACRAW Mode
→ SPI
→ 유선 Ethernet

소스에 사용된 WiFiServer, WiFiClient, WiFiUDP라는 Class 이름은 Wi-Fi Radio가 사용된다는 의미가 아니다. Arduino-Pico의 유선 Ethernet lwIP 구현이 기존 Wi-Fi 호환 Network API를 재사용한 것이다.

TOE 사용 여부

TOE 사용 여부: 미사용

W5100S 자체에는 Hardwired TCP/IP Engine이 포함되어 있지만, 이 프로젝트는 W5100S의 Hardware TCP 및 UDP Socket을 Application Transport로 사용하지 않는다. Wiznet5100lwIP Driver는 W5100S Socket 0을 MACRAW Mode로 열고 Raw Ethernet Frame을 Software lwIP에 전달한다. 따라서 TCP, UDP, DHCP와 Socket 처리는 W5100S의 Hardwired TCP/IP Engine이 아니라 MCU 측 lwIP Stack에서 수행된다.

구현 방식 분류

• W5100S Hardware TCP/UDP Socket 직접 제어: 아님
• W5100S TOE Socket을 사용하는 일반 Arduino Ethernet Library 경유: 아님
• ESP-IDF esp_eth / esp_netif / lwIP 경유: 아님
• 기타 Framework 또는 Driver 경유: 해당
• 실제 구현: Arduino-Pico EthernetLWIP와 Wiznet5100lwIP MACRAW Mode
• W5100S 역할: SPI 기반 Raw Ethernet Frame Interface
• Hardware TCP/IP Offload 효과: 현재 구조에서는 사용되지 않음

따라서 이 프로젝트는 W5100S를 이용한 Embedded Ethernet 통합 사례에는 해당하지만, WIZnet Hardware Socket 기반 TOE 활용 사례에는 해당하지 않는다.

Hybrid Network 여부

Hybrid Network: 해당 없음

하나의 시스템 안에서 유선 Ethernet과 무선 Network를 동시에 사용하는 구성은 저장소에서 확인되지 않는다. Embedded Motor Controller는 W5100S 기반 유선 Ethernet을 사용한다. WiFiServer, WiFiClient, WiFiUDP는 Arduino-Pico의 API 호환성을 위한 이름이며 실제 Wi-Fi Network 사용 근거가 아니다.

최상위 README의 “Hybrid Patterns”는 PUB/SUB와 PUSH/PULL 같은 서로 다른 메시징 패턴을 결합한다는 의미다. 유선·무선 Hybrid Network를 의미하지 않는다.

장점

1. End-to-End 로봇 시스템 구성

단순 Network Example에 머물지 않고 Java 메시징, Robot Service, Embedded Firmware, Motor Control, Telemetry, Discovery, Dashboard, Simulation과 Safety Logic을 하나의 저장소에서 연결한다.

2. Command와 Telemetry 경로 분리

Command는 TCP Request-Response 경로를 사용하고 현재 Telemetry는 Non-blocking UDP를 사용한다. 느린 Telemetry Consumer나 TCP Backpressure가 Motor Control Loop를 직접 정지시키는 문제를 줄이는 구조다.

3. Compact Binary Protocol

Binary Protocol은 제한된 Frame Size, Message Type, Correlation ID, Sequence Number와 Idempotent Command 처리를 제공한다. 메모리와 처리 시간이 제한된 Embedded Controller에 적용하기 적합한 구성이다.

4. 다중 안전 계층

Heartbeat 감시, ODrive Watchdog, Command Inactivity Detection, Emergency Stop, Hardware Watchdog을 함께 사용한다. 단일 Network Timeout에만 의존하지 않고 여러 장애 지점에 독립적으로 대응한다.

5. 자동 Discovery 및 재연결

Java Client는 Multicast 기반 Node Discovery, Connection State 관리, 주기적 Heartbeat, Timeout 감지와 자동 재연결을 지원한다. 개발 과정이나 장비 교체 시 고정 IP 의존도를 줄일 수 있다.

한계

1. 문서와 소스 코드의 불일치

Arduino README는 TCP 5580 Telemetry와 500 ms Jetson Timeout을 설명하지만 현재 Firmware는 TCP Telemetry Server를 비활성화하고 UDP 5582와 750 ms Timeout을 사용한다. Java Builder의 일부 주석에도 이전 Port 구조가 남아 있다.

2. Legacy와 신규 Protocol 경로의 공존

PicoBridge는 TCP 및 Text 기반 Telemetry를 예상하지만 현재 Direct Motor Client는 Binary UDP Telemetry를 사용한다. 실제 배포 구조를 명확히 하려면 Protocol Version 통합과 Legacy Component 구분이 필요하다.

3. TOE 기능 미활용

W5100S가 MACRAW Mode로 동작하므로 TCP/IP 처리는 Software lwIP가 담당한다. MCU의 Network 처리 부담이 증가하며 WIZnet TOE 제품의 Hardware Socket 기반 결정성을 확인하는 사례로 사용하기 어렵다.

4. 성능 수치의 검증 자료 부족

Arduino 문서는 약 2–5 ms Command Latency, 20 Hz Telemetry와 500 ms Safety Timeout을 제시한다. 그러나 별도의 Benchmark Source Data, Packet Capture, 반복 측정 조건과 Hardware Test Report는 확인되지 않는다.

최상위 README에는 Brokerless ZeroMQ 계층의 Microsecond Latency가 별도로 기재되어 있다. 이는 메시징 계층에 대한 설명이며 End-to-End Motor Control Latency 측정 결과로 해석할 수 없다.

5. 초기 단계의 저장소 성숙도

현재 공개 저장소에는 2026년 1월 12일의 Initial Commit 하나만 확인되며 Published Release도 없다. 장기 유지보수, Regression 처리와 Release 안정성을 판단할 수 있는 공개 이력이 제한적이다.

6. 보안 구조 미정의

확인한 README와 주요 통신 경로에는 Transport Encryption, Device Authentication, Command Authorization와 Secure Discovery 구조가 명시되어 있지 않다. 물리적으로 격리되지 않은 Network에 적용하려면 별도의 보안 계층이 필요하다.

적용 가치

OneTouch는 다음 영역에서 Reference로 활용할 수 있다.

• W5100S 기반 유선 Robot Controller Node
• Jetson과 Embedded Motor Controller 간 통신
• TCP Command와 UDP Telemetry 분리 구조
• Java와 Arduino/C++ 간 Binary Protocol 구현
• ODrive Ethernet Gateway
• Multicast 기반 Device Discovery
• Heartbeat 및 Watchdog Safety Chain
• Java Virtual Thread 기반 Robot Service
• Embedded Telemetry의 ZeroMQ Network 연계

이 프로젝트의 핵심 가치는 Messaging Software, Embedded Ethernet Firmware와 실제 Motor Safety Logic을 하나의 시스템으로 연결한 점이다. 다만 W5100S가 MACRAW와 Software lwIP 경로로 동작하므로 TOE 활용 사례로서의 가치는 제한적이다.

실제 제품 수준으로 확장하려면 Protocol 문서, 현재 Port 구성, Legacy Bridge, Security Model, Automated Integration Test와 재현 가능한 성능 측정 자료를 일관되게 정리할 필요가 있다.

저자 정보

저자: Devin Willis
GitHub 계정: gatordevin
최초 Commit: 2026년 1월 12일
Commit 설명: “Initial commit: OneTouch robot control system”
License: MIT