기술 지원
게시됨 2026-01-19
무슨 날인지는 잊어버렸지만 서보 어레이를 디버깅하고 있었습니다. 3개의 서보 모터는 지시에 따라 동기적으로 회전해야 했지만, 대신 무작위로 춤을 추는 것처럼 보였습니다. 통신 지연? 전압이 불안정합니까? 아니면 논리에 문제가 있는 걸까요? 나는 화면의 데이터 흐름을 바라보다가 갑자기 문제가 하드웨어에 있는 것이 아니라 하드웨어를 연결하는 "신경"에 있다는 것을 깨달았습니다.
우리는 항상 이렇습니다. 스티어링 기어를 정확하게 보정하고 기계 구조를 튼튼하게 설계하는 데 많은 시간을 소비하지만 모든 것을 움직이게 하는 "두뇌"를 무시하기 쉽습니다. 복잡한 프로젝트, 특히 실시간 제어가 관련된 프로젝트에서 기존의 모놀리식 애플리케이션은 모든 부품을 상자에 넣어 몸 전체에 영향을 미치는 것과 같습니다. 특정 모듈의 작은 변경으로 인해 전체 시스템을 다시 디버깅해야 할 수도 있습니다.
대부분의 사람들의 첫 번째 반응은 땜질하는 것입니다. 여기에 내결함성 코드를 추가하고 스레드 우선순위를 조정하세요. 그러나 이것이 문제를 되돌릴 뿐이라는 것을 곧 알게 될 것입니다. 센서가 증가하고 제어 논리가 더욱 복잡해짐에 따라 프로그램은 비대해지고 취약해집니다. 모든 컴파일과 배포는 하나의 모험이기 때문에 처음에는 쉽게 업그레이드할 엄두가 나지 않습니다.
서보 모터를 제어하는 로직, 센서 데이터를 처리하는 장치, 모션 궤적을 관리하는 장치가 모두 독립적인 레고 모듈처럼 실행되어 각각에 집중하고 명확한 인터페이스를 통해 통신할 수 있다고 상상해 보세요. 이것이 임베디드 및 기계적 제어 분야에서 마이크로서비스 아키텍처의 매력이다.
하지만 솔직히 말해서 C++ 환경에서 이러한 아키텍처를 구축하는 것은 초기에 숲에서 길을 닦는 것과 같습니다. 기본적이지만 까다로운 리소스 관리 문제는 말할 것도 없고 프로세스 간 통신(gRPC? ZeroMQ? Simple TCP?)에 무엇을 사용할지, 데이터 직렬화를 처리하는 방법, 확산 없이 오류를 격리하는 방법 등을 고려해야 합니다. 처음부터 새로 구축하려면 최소한 몇 주가 걸리고 밤늦게까지 셀 수 없이 많은 디버깅 주기가 필요합니다.
이렇게 말하면서 나는 이전에 접했던 오픈 소스 참조 구현을 기억했습니다. 여기에는 특수 효과가 없으며 C++에서 마이크로서비스 애플리케이션이 어떤 모습일 수 있는지 명확하게 보여줍니다. 각 서비스에는 명확한 책임이 있습니다. 예를 들어, PWM 신호 생성을 구체적으로 처리하는 서비스는 위치 명령을 구문 분석하는 서비스와 완전히 분리됩니다. 데이터는 가벼운 메시지를 통해 그들 사이에 전송됩니다. 특정 서비스가 일시적으로 응답하지 않는 경우에도 전체 시스템이 정지되지는 않습니다.
이 구조의 이점은 실용적입니다. 예를 들어, 로봇 팔에 새로운 센서 피드백 링크를 추가해야 하는 경우 전체 프로그램을 재구성할 필요가 없습니다. 새로운 데이터를 처리하기 위한 독립적인 서비스를 개발한 후, 구축된 인터페이스를 통해 기존 시스템에 연결하기만 하면 됩니다. 특정 기능을 업그레이드하거나 디버깅할 때 실행 중인 다른 제어 작업에 영향을 주지 않고 해당 서비스 모듈을 독립적으로 다시 시작할 수도 있습니다. 이는 하루 24시간 작동해야 하는 장비의 가용성이 높아진다는 것을 의미합니다.
한 친구가 "리소스가 제한된 임베디드 장치에 비해 너무 무거울까요? "라고 물었습니다. 이것은 좋은 질문입니다. 핵심은 구현 방법에 있습니다. 경량 프로세스, 효율적인 공유 메모리 통신, 불필요한 직렬화 오버헤드 방지 등은 모두 잘 설계된 아키텍처에서 해결될 수 있습니다. 해당 참조 프로젝트는 모듈화의 이점이 성능 손실로 인해 상쇄되지 않도록 분리와 효율성의 균형을 맞추는 방법을 보여줍니다.
C++ 마이크로서비스 예제를 볼 때 얼마나 많은 통신 프로토콜이 구현되어 있는지만 보지 마십시오. 더 중요한 것은 오류 경계가 명확하게 설계되었는지 여부입니다. 한 서비스의 충돌이 다른 서비스에 영향을 미치나요? 비정상적인 상황에서 데이터 흐름에 합리적인 시간 초과 및 대체 메커니즘이 있습니까? 이는 물리적 기계를 제어하는 시스템에 매우 중요합니다.
그런 다음 관찰 가능성이 있습니다. 각 서비스가 의미 있는 로그와 상태 측정항목을 독립적으로 출력할 수 있나요? 스티어링 기어 움직임에 편차가 있는 경우 문제가 있는 데이터 처리 링크를 신속하게 찾을 수 있습니까? 좋은 디자인은 대시보드를 보는 것처럼 직관적으로 진단을 수행합니다.
구축과 배치의 편의성입니다. 개별 서비스를 독립적으로 쉽게 컴파일하고 테스트할 수 있습니까? 한 번의 클릭으로 전체 시스템을 개발 환경이나 시뮬레이터에서 실행할 수 있습니까? 배포 마찰을 줄이면 비즈니스 논리 자체에 더 집중할 수 있습니다. 즉, 모터와 기계 구조가 예상한 대로 정확하게 실행되도록 할 수 있습니다.
오픈 소스 예제 저장소의 가치는 사고의 출발점을 제공한다는 것입니다. 일부 구현에 동의하지 않을 수 있지만 처음부터 시작하는 혼란을 피할 수 있습니다. 좌표 격자가 그려진 그림과 마찬가지로 매번 비율을 다시 측정할 필요 없이 특정 요구 사항을 그 위에 직접 묘사할 수 있습니다.
처음에 서보가 동기화되지 않는 문제로 돌아갑니다. 나중에 메인 제어 루프의 중요하지 않은 작업이 때때로 실시간 명령 전송을 차단한다는 사실을 발견했습니다. 당시 시스템이 모듈식이었다면 전체 모션 제어 체인을 끌어내리지 않고도 중요하지 않은 작업이 때때로 자체의 작은 세계에서 "멍해졌을" 수 있었을 것입니다. 이 문제를 해결하려면 전체 장치를 종료하는 대신 해당 개별 서비스를 다시 시작하세요.
이것은 소프트웨어 아키텍처가 하드웨어 프로젝트에 제공하는 선물일 수 있습니다. 즉, 복잡성을 침착하게 처리할 수 있는 가능성입니다. 각 구성요소가 자신의 책임을 알고 명확한 의사소통 방법을 가지고 있을 때 전체 시스템은 유연하면서도 견고한 활력을 보여줄 수 있습니다. 이제 남은 것은 메커니즘이 완벽하게 작동하도록 더 많은 생각을 했다는 것입니다. 그게 더 재미있는 부분이겠죠?
2005년에 설립되었으며,kpower는 중국 광둥성 둥관에 본사를 둔 전문 컴팩트 모션 유닛 제조업체에 전념해 왔습니다. 모듈식 드라이브 기술의 혁신을 활용하여,kpower고성능 모터, 정밀 감속기, 멀티 프로토콜 제어 시스템을 통합하여 효율적이고 맞춤형 스마트 드라이브 시스템 솔루션을 제공합니다.kpower스마트 홈 시스템, 자동 전자 장치, 로봇 공학, 정밀 농업, 드론, 산업 자동화 등 다양한 분야를 포괄하는 제품을 통해 전 세계 500개 이상의 기업 고객에게 전문 드라이브 시스템 솔루션을 제공해 왔습니다.
업데이트 시간：2026-01-19
