Wiznet makers

Overview

GHRA is structured as a distributed motion-control system for a motorized trolley running on an I-beam. Its core idea is to split the system into a host-side ROS2 control layer, an Ethernet-connected motor controller, a Wi-Fi remote node, and a browser-based dashboard rather than placing all logic inside a single PLC-like controller.

The design is notable because it mixes industrial-style actuation paths with software-defined orchestration. A VFD receives the actual speed reference through a 0-10V analog signal, while direction is handled through relay-driven terminal inputs. Position feedback comes from a UART laser distance sensor, and supervisory logic sits in ROS2 rather than in the VFD itself.

Main Content

System Context

The target machine is an AC motor-driven trolley on an IPE 140 rail. The host platform is an Ubuntu 22.04 x86 system, while edge control is distributed across ESP32 boards. One ESP32 is placed in the motor box and handles Ethernet communication, DAC output, laser input, and relay control; another ESP32 acts as a wireless button remote.

This separation matters because the system is not treating the UI, remote input, and motor interface as equal peers. The host-side control node mediates commands and applies positional limits, while the motor-side ESP32 is closer to the hardware and executes actuation-facing functions. That makes the dashboard and handheld remote operational entry points, but not the final source of authority.

Architecture / Design Considerations

The wired control path is anchored by a WIZnet W5500 Ethernet module attached to the motor-side ESP32 over SPI. In this design, WIZnet Ethernet is not a decorative connectivity choice. It provides the wired transport for the ESP32 node that carries motor commands and reports position feedback back into the ROS2 environment through the micro-ROS agent.

A key design distinction from simpler hobby motor systems is that speed and direction are deliberately separated. Speed is converted from ROS2 commands into a 0-10V analog output through the GP8211S DAC, while direction is switched through relays connected to the VFD FWD and REV terminals. This avoids overloading one interface with two control meanings and keeps the actuation path aligned with how the VFD expects to be driven.

Another important structural choice is the use of micro-ROS as the bridge between low-cost microcontrollers and the host ROS2 graph. The motor ESP32 publishes carriage position and speed feedback while subscribing to speed, direction, and enable commands. The remote ESP32 only publishes button events, and the Python control node translates those events into motion commands with positional boundary checks.

Security is treated as a system property rather than a web-only feature. The plan places SROS2 on ROS2 traffic, HTTPS and basic authentication on the dashboard, and separates the control network from the internet-facing network through distinct interfaces and dedicated local infrastructure.

The highest-cost decision point in this architecture is the boundary between sensed position and motion permission. The control node stops or blocks movement based on carriage position, and the motor ESP32 turns those commands into analog and relay outputs. If position feedback is wrong, stale, or absent, the supervisory layer can approve unsafe movement or fail to stop it in time. This is an interpretation based on the documented position-limit checks and the role of /carriage/position in the control loop.

A second high-risk area is direction switching. The firmware explicitly inserts a both-off relay interlock delay before changing FWD and REV states, which indicates that simultaneous or rapid contradictory direction signals are treated as hazardous conditions.

Possible Implications

This architecture is likely to be more maintainable than a monolithic controller because transport, UI, control policy, and hardware adaptation are separated into visible layers. The cost is that correctness now depends on topic contracts, network behavior, and the quality of the sensing path, not only on local GPIO logic. This is an interpretation from the documented topic map, node roles, and split deployment model.

The system also appears intentionally positioned as an orchestrated control stack rather than a fully self-contained safety controller. The future emergency-stop hardware is explicitly listed as out of scope, which implies that the current design is a functional motion-control framework but not the entire final safety envelope.

If the WIZnet W5500 Ethernet path were removed, the system would change character in a meaningful way. It would stop being a mixed wired-wireless control architecture and become more dependent on wireless transport for operational traffic, reducing the separation between critical motor control communication and convenience-oriented access paths. This is an interpretation based on the documented role of the W5500-linked motor node and the separate Wi-Fi remote/dashboard access model.

Conclusion

GHRA is best understood as a layered motor-control architecture that combines ROS2 orchestration, micro-ROS edge nodes, a WIZnet W5500-based wired motor interface, and a web-accessible operator surface. Its most important design choices are the separation of speed and direction control, the placement of motion policy in the host-side control node, and the use of wired Ethernet for the motor-side edge node rather than relying entirely on Wi-Fi.

Its main engineering value is not novelty for its own sake, but the explicit structuring of roles and boundaries: UI and remote input request motion, the control node decides within limits, and the motor-side node converts those decisions into physical signals the VFD can use.

전체 개요

ghra는 단순한 모터 구동 예제가 아니라, 레일 위를 움직이는 AC 모터 기반 트롤리를 ROS2 중심으로 제어하려는 시스템 설계안에 가깝습니다. 공개 저장소 기준으로 보면, 완성품 설명서라기보다 시스템 계획서 + 초기 구현 스켈레톤이 핵심입니다. 하드웨어, 펌웨어, 웹 UI, ROS2 제어 노드, 보안 구성이 한 묶음으로 제시되어 있습니다.

이 시스템의 요점은 “모터를 돌린다”가 아닙니다. 어느 계층이 무엇을 결정하고, 어느 계층이 물리 신호로 바꿔 실행하는가를 분리해 두었다는 점이 핵심입니다. 이 분리가 보이면 설계 의도가 보이고, 안 보이면 그냥 부품 나열처럼 보이게 됩니다. 인간이 만든 시스템 설명문이 늘 그렇듯, 중요한 건 표보다 경계입니다.

문제의식과 기술적 맥락 재구성

이 설계가 다루는 문제는 비교적 명확합니다. 레일 위를 움직이는 트롤리를 원격 입력과 웹 UI로 제어하되, 단순 무선 장난감처럼 만들지 않고 호스트 측 로직, 현장 액추에이션, 센서 피드백, 네트워크 보안을 분리하려는 것입니다. 문서상으로는 Ubuntu x86 호스트가 중심이 되고, ESP32들이 현장 입출력을 담당하며, VFD가 실제 모터 구동을 맡습니다.

기존 접근과의 차이는 여기서 나옵니다. 흔한 접근은 마이크로컨트롤러 하나에 버튼, 센서, 모터 제어를 전부 몰아넣는 방식입니다. 반면 이 구조는 정책 판단을 ROS2 측으로 올리고, ESP32는 하드웨어 적응 계층처럼 쓰고 있습니다. 이 차이는 유지보수성과 확장성에는 유리하지만, 네트워크와 메시지 계약이 흔들리면 시스템 전체가 흔들릴 수 있다는 비용을 함께 가져옵니다. 이 부분은 추론임이며, 토픽 구조와 노드 역할 분리를 근거로 한 해석입니다.

기술 흐름 설명

신호 흐름은 다음처럼 읽는 것이 가장 자연스럽습니다.

1. 사용자는 두 경로 중 하나로 입력합니다.
   하나는 ESP32 기반 4버튼 무선 리모컨, 다른 하나는 Vue.js PWA 대시보드입니다. 리모컨은 버튼 이벤트를 /remote/button_event로 보내고, 대시보드는 속도·방향·활성화 신호를 ROS2 측에 전달합니다. 
2. 중앙의 Python control_node가 이 입력을 받아 해석합니다.
   특히 리모컨 입력은 여기서 속도와 방향으로 변환되며, 현재 위치 /carriage/position를 기준으로 전진/후진 한계를 검사합니다. 즉, 사용자의 입력은 곧바로 물리 출력이 되지 않고, 한 번 정책 판단을 거칩니다. 
3. 모터 박스 쪽 ESP32가 최종 실행을 담당합니다.
   이 노드는 /motor/speed_cmd, /motor/direction, /motor/enable을 구독하고, DAC를 통해 0-10V 아날로그 속도 기준 신호를 만들고, 릴레이를 통해 VFD의 FWD/REV 단자를 제어합니다. 동시에 레이저 센서에서 위치를 읽어 /carriage/position을 다시 올립니다. 
4. VFD는 실제 전력 변환과 모터 구동을 담당합니다.
   다시 말해, ROS2나 ESP32가 전력을 직접 다루는 것이 아니라, VFD를 제어하는 신호를 만들어 주는 계층으로 동작합니다. 이 때문에 시스템은 소프트웨어 중심처럼 보이지만, 실제 물리 동작의 마지막 관문은 여전히 VFD입니다. 

왜 이런 구조가 나왔는지에 대한 해설

이 구조에서 가장 눈에 띄는 선택은 속도와 방향을 분리했다는 점입니다. 속도는 GP8211S DAC로 0-10V를 직접 만들어 VFD의 AVI/ACM에 넣고, 방향은 릴레이로 FWD/REV 단자를 닫는 방식입니다. 이것은 한 인터페이스에 두 의미를 억지로 실어 보내지 않겠다는 설계로 읽힙니다. VFD가 기대하는 입력 모델을 존중한 구조라고 보는 편이 맞습니다.

또 하나 중요한 선택은 WIZnet W5500 Ethernet을 모터 제어 측 ESP32에 붙였다는 점입니다. 여기서 W5500은 그냥 “유선도 됩니다” 수준의 부품이 아닙니다. 모터 측 노드를 제어망의 유선 끝단으로 고정하여, 현장 액추에이션 경로를 Wi-Fi에 전적으로 의존하지 않게 만드는 역할을 합니다. 즉, 이 시스템에서 W5500은 편의 기능이 아니라 제어망의 성격을 규정하는 부품에 가깝습니다.

반면 리모컨 ESP32는 Wi-Fi를 사용합니다. 이것은 “모든 경로를 다 유선으로 만들겠다”가 아니라, 핵심 제어 경로와 사용자 입력 경로를 다르게 취급한다는 신호로 볼 수 있습니다. 다시 말해, 사용자의 입력은 무선이어도 되지만, 모터 박스와 호스트 사이의 제어 연계는 더 고정적인 유선으로 두려는 의도가 읽힙니다. 이 부분은 추론임이지만, 시스템도와 모터 ESP32의 W5500 연결 구조를 보면 상당히 설득력 있습니다.

설계 선택의 배경, 제약 조건, 대안 가능성

이 설계는 ROS2를 쓴 만큼 분산 시스템의 장점을 얻습니다. 웹 UI, 리모컨, 제어 노드, 센서, 액추에이션을 토픽 중심으로 엮을 수 있고, 각 모듈을 따로 바꾸기 쉽습니다. 예를 들어 리모컨 방식을 바꾸거나, 대시보드를 다른 프런트엔드로 교체하거나, 호스트 제어 노드에 더 복잡한 안전 정책을 넣는 것이 비교적 자연스럽습니다.

하지만 대가도 분명합니다. 네트워크, 에이전트, 토픽 명세, 인증 키스토어, WebSocket 프록시, 컨테이너 실행 방식까지 모두 맞물려야 합니다. 즉, 이 시스템은 단일 MCU 프로젝트보다 디버깅 축이 훨씬 많습니다. 모터가 안 도는 이유가 GPIO가 아니라 DDS 보안, rosbridge, agent 연결, 혹은 위치 경계 로직일 수도 있습니다. 이 부분은 문서와 코드 구조를 바탕으로 한 추론임입니다.

대안도 생각할 수 있습니다.
하나는 PLC 또는 전용 산업용 컨트롤러 중심 구조입니다. 이 경우 네트워크 분산 복잡도는 줄지만, 웹 대시보드와 소프트웨어 확장성은 떨어질 수 있습니다.
다른 하나는 ESP32 하나에 모든 기능을 몰아넣는 방식입니다. 구현은 단순해질 수 있지만, 역할 분리와 정책 계층이 무너져 전체 시스템이 더 강하게 결합됩니다. 이 비교는 추론임입니다.

생소한 개념에 대한 풀어쓴 설명

micro-ROS는 작은 MCU를 ROS2 생태계에 연결해 주는 얇은 다리로 보시면 됩니다. ESP32가 리눅스처럼 풀 ROS2를 직접 돌리는 것이 아니라, agent를 통해 ROS2 그래프에 참여하는 방식입니다. 그래서 MCU는 센서·버튼·DAC·릴레이 같은 현장 I/O에 집중하고, 무거운 정책 로직은 호스트로 올릴 수 있습니다.

VFD는 모터에 바로 “빨리 돌아라”라고 명령하는 칩이 아닙니다. 전력과 주파수를 조절해 AC 모터를 제어하는 장치입니다. 이 설계에서는 DAC가 0-10V 기준을 만들고, 릴레이가 방향 입력을 결정하므로, 소프트웨어는 결국 VFD가 이해할 수 있는 형태로 명령을 번역하는 셈입니다.

SROS2는 ROS2 통신에 인증과 암호화를 붙이는 층입니다. 문서상으로는 keystore를 생성하고, 인증되지 않은 노드를 거부하는 enforce 모드까지 계획되어 있습니다. 즉, “웹만 HTTPS면 된다”가 아니라 ROS2 내부 통신 자체도 보호하려는 방향입니다.

시스템 구성 및 선택지 해석

시스템을 역할 기준으로 나누면 다음과 같습니다.

• 입력 계층: PWA 대시보드, 4버튼 무선 리모컨 
• 정책 계층: Python control_node, 위치 기반 제한, enable 상태 관리 
• 실행 계층: 모터 ESP32, DAC, 릴레이, 레이저 센서, W5500 Ethernet 
• 전력/구동 계층: VFD와 AC 모터 

여기서 중요한 해석 포인트는 보조 수단과 본체의 구분입니다. 대시보드와 리모컨은 명령을 넣는 수단이지, 시스템의 최종 판단 주체가 아닙니다. 최종적으로는 제어 노드가 한계 조건을 걸고, 모터 ESP32가 물리 신호로 바꾸며, VFD가 실제 동력을 만듭니다. 그래서 웹 UI는 있어도 좋지만, 시스템의 본질은 아닙니다.

또 하나의 핵심 논지는, 특정 구성요소 제거 시 시스템 성격이 바뀐다는 점입니다.
W5500을 빼면, 이 시스템은 더 이상 “핵심 제어 경로는 유선, 사용자 입력은 무선”이라는 성격을 유지하기 어렵습니다. 그러면 제어망의 안정성과 분리 철학이 약해지고, 전체가 더 Wi-Fi 의존적인 구조로 이동합니다. 이것은 공개 문서 기반의 추론임입니다.

내부 관점에서의 시사점

내부 검토 관점에서 가장 먼저 봐야 할 것은 “이게 동작하느냐”보다 어디서 크게 망가질 수 있느냐입니다. 그 지점은 문서상 분명히 두 군데입니다. 첫째는 위치 피드백과 이동 허용 판단의 경계입니다. 제어 노드가 위치를 보고 방향/속도를 허용하는 만큼, 센서 값이 틀리면 정책 계층 전체가 잘못된 결정을 내릴 수 있습니다. 둘째는 방향 전환 릴레이 제어입니다. 그래서 펌웨어가 둘 다 끄고 50ms 기다리는 인터락을 명시하고 있습니다.

또한 현재 공개 범위만 보면, 이 설계는 완전한 안전 시스템이라기보다 기능 중심 제어 스택입니다. 비상정지 회로는 future/out of scope로 밀려 있고, 위치 경계는 소프트웨어 정책에 의존합니다. 따라서 실제 장비 적용 단계에서는 소프트웨어 경계와 별개로 하드웨어 안전 체인을 반드시 분리 검토해야 합니다. 이 판단은 일부는 문서 사실이고, 일부는 추론임입니다.

FAQ

1) 기존 MCU 단독 제어 방식과 가장 큰 차이는 무엇입니까?

가장 큰 차이는 정책 판단과 하드웨어 실행이 분리되어 있다는 점입니다. 이 구조에서는 ESP32가 모든 판단을 하지 않고, ROS2 제어 노드가 버튼 입력을 해석하고 위치 제한을 적용한 뒤 명령을 내립니다.

2) 왜 속도와 방향을 따로 제어하도록 만들었습니까?

VFD가 기대하는 인터페이스에 맞추기 위한 선택으로 보입니다. 속도는 0-10V 아날로그 기준으로, 방향은 FWD/REV 단자 제어로 나누면 의미가 명확해지고, 한 신호에 여러 역할을 억지로 실지 않게 됩니다. 마지막 문장은 추론임입니다.

3) 이 시스템에서 핵심 신호 흐름은 어떻게 됩니까?

입력은 리모컨 버튼 이벤트 또는 대시보드 명령으로 들어오고, control_node가 이를 속도/방향 명령으로 바꾸며 위치 제한을 검사합니다. 그 뒤 모터 ESP32가 DAC와 릴레이를 구동하고, 레이저 센서 값은 다시 ROS2 쪽으로 올라와 폐루프 비슷한 감시 구조를 만듭니다.

4) W5500은 왜 필요한 구성으로 보입니까?

문서상 W5500은 모터 박스 ESP32의 유선 네트워크 인터페이스 역할을 합니다. 그래서 단순히 Ethernet 기능 추가가 아니라, 핵심 제어 경로를 Wi-Fi와 분리하는 축으로 읽히며, 제거 시 시스템 성격이 달라질 가능성이 큽니다. 마지막 문장은 추론임입니다.

5) 실패 비용이 가장 큰 판단 지점은 어디입니까?

공개 정보 기준으로는 위치 피드백을 기반으로 이동 허용 여부를 결정하는 구간이 가장 위험해 보입니다. 제어 노드가 위치를 보고 정지 또는 허용을 결정하므로, 센서 오동작이나 거리 해석 실패는 곧바로 잘못된 움직임 판단으로 이어질 수 있습니다. 이 평가는 추론임입니다.

6) 웹 대시보드는 시스템의 중심입니까, 보조 수단입니까?

구조상으로는 보조 수단에 가깝습니다. 대시보드는 명령 입력과 상태 표시를 담당하지만, 최종 정책 판단은 ROS2 제어 노드가 하고, 실제 물리 신호 변환은 모터 ESP32와 VFD가 담당합니다.

저자 정보 (Author Information)

공개된 정보 기준으로 확인 가능한 것은 GitHub 계정 KMDE-10이 이 저장소를 공개 상태로 보유하고 있다는 점 정도입니다. 프로필 페이지에는 개인인지 조직인지에 대한 충분한 설명, 소속 기관, 연구 배경, 상세 소개가 거의 보이지 않습니다. 따라서 작성 주체의 공학적 배경이나 소속 성격을 구체화하는 것은 정보 제한입니다.

한편 공개 저장소 목록에 fieldkit-pwa, DIC, HYDROGEN, DESY 같은 다른 프로젝트가 보이므로, 소프트웨어 실험 또는 기술 프로젝트를 병행하는 계정일 가능성은 있습니다. 다만 이것만으로 특정 기관 소속이나 전문 분야를 단정하는 것은 어렵고, 그 이상은 추론임입니다.