본문으로 바로가기
NALDAFACTORY

HOME / COMMUNITY

TECHNOLOGY COMMUNITY

NALDA Factory Community

XR, Motion, Digital Twin과 Creative Technology의 질문과 답변을 공유합니다.

NALDA FACTORYXR · Motion · Digital Twin
Creative Technology

게시판 답변

15 글 보임 - 1 에서 15 까지 (총 20 중에서)
1 2
  • 글쓴이
    글

  • NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #677

    입문 단계에서는 완성형 플랫폼 하나를 찾기보다 Digital Twin을 구성하는 계층을 작은 도구로 분리해 보는 편이 구조를 이해하기 좋습니다. Blender는 단순화된 3D 자산과 좌표·Pivot을 준비하는 데 사용할 수 있고, Unreal Engine은 자산을 실시간 공간에 배치해 상태 변화와 UI를 표현하는 데 적합합니다. 두 도구 모두 실제 프로젝트 적용 전 현재 라이선스와 배포 조건을 공식 페이지에서 확인해야 합니다.

    센서 메시지 실습은 Eclipse Mosquitto 같은 MQTT Broker와 간단한 Publisher로 시작할 수 있습니다. Node-RED는 입력 메시지 변환, 규칙과 API 연결을 시각적인 Flow로 시험하기 편합니다. 시간에 따른 값을 저장한 뒤 Grafana OSS로 Dashboard를 구성하면 수집·이력·표현의 책임이 어떻게 나뉘는지 확인할 수 있습니다. Digital Twin 개념 자체를 다루는 공개 프레임워크를 탐색하려면 Eclipse Ditto의 Thing Model과 메시징 문서를 참고할 수 있습니다.

    첫 예제는 복잡한 공장 대신 가상의 온도 센서 한 개와 팬 상태로 충분합니다. Asset ID와 단위를 정하고, Timestamp가 포함된 메시지를 Broker로 보내고, Node-RED에서 범위를 검증한 뒤 저장·시각화합니다. 마지막으로 Unreal의 3D 객체 색이나 UI가 API 또는 메시지에 따라 변하도록 연결하면 전체 데이터 경로를 경험할 수 있습니다. 연결이 끊기거나 오래된 값이 들어올 때의 표시도 함께 구현합니다.

    무료·오픈소스는 운영 비용이 0이라는 의미가 아닙니다. 버전 호환성, 보안 업데이트, 플러그인 의존성, 백업, 사용자 인증과 장기 유지보수 책임을 평가해야 합니다. 학습용 구성은 외부에 노출하지 않고 테스트 데이터로 운영하며, 실제 설비 연결 전에는 네트워크 분리와 권한·암호화·장애 복구를 별도로 설계하십시오.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #639

    결론부터 말하면 Pixel Pitch는 작을수록 해상도 잠재력은 커지지만, 항상 최적이라는 뜻은 아닙니다. Pitch는 인접 LED 픽셀 중심 사이 거리이며 같은 물리 크기에서는 Pitch가 작을수록 가로·세로 픽셀 수가 늘어납니다. 그러나 실제 품질은 콘텐츠 해상도, LED 모듈의 균일도, 영상 프로세서, 관람·촬영 거리와 함께 결정됩니다.

    사람이 보는 전시는 목표 관람거리에서 픽셀 구조가 얼마나 드러나는지부터 판단합니다. 관객이 충분히 멀리 있다면 더 작은 Pitch에 지출해도 체감 이득이 제한될 수 있습니다. 반면 카메라 촬영에서는 육안 시청거리만으로 결정할 수 없습니다. 센서의 샘플링 격자와 LED 픽셀 격자가 간섭하면 Moiré가 생기므로 카메라 위치, 초점거리, 조리개, 초점면, 촬영 해상도와 LED Pitch를 함께 테스트해야 합니다.

    Pitch가 작아지면 같은 면적에서 처리할 픽셀과 데이터가 증가해 LED 프로세서 출력 수, 전송 대역폭, 렌더 해상도와 GPU 부하가 커질 수 있습니다. 모듈 수와 제품 등급에 따라 구매·임대 비용, 소비전력, 냉각과 유지관리 조건도 달라집니다. 따라서 먼저 화면 크기와 관람·촬영 범위를 고정하고, 필요한 실제 해상도를 계산한 뒤 후보 Pitch 두세 개를 실물 카메라 테스트로 비교하는 순서가 안전합니다.

    초기 비교에서는 NALDA LED Wall Calculator로 화면 크기와 Pitch에 따른 이론 해상도를 확인할 수 있습니다. 계산값은 제품 선정의 출발점이며 최종 결정 전에는 후보 패널, 실제 카메라와 렌즈, 목표 프레임레이트로 테스트 촬영을 진행해야 합니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #675

    IoT는 Digital Twin의 실시간 연결을 구현하는 중요한 수단이지만 모든 Twin에 반드시 필요한 단일 조건은 아닙니다. 핵심은 물리 대상과 디지털 표현 사이에 식별 가능한 관계가 있고, 목적에 필요한 상태가 정의된 절차로 갱신되며, 그 정보를 조회·분석·의사결정에 사용하는 것입니다. 갱신은 센서 스트림뿐 아니라 작업자가 입력한 점검 결과, 업무 시스템의 상태, Batch Import나 계산 결과로도 이루어질 수 있습니다.

    예를 들어 건물 자산 관리 Twin은 설비 위치와 사양, 점검 이력, 고장 Ticket과 교체 상태를 하루 또는 이벤트 단위로 반영해도 목적을 충족할 수 있습니다. 반면 회전체 이상 감지나 공정 제어처럼 초 단위 이하 변화가 중요한 목적에는 센서와 안정적인 통신이 필요합니다. 따라서 실시간이라는 표현보다 의사결정에 필요한 Freshness와 지연 허용치를 자산·속성별로 정의해야 합니다.

    센서가 없는 초기에도 Asset ID, 공간 계층, 속성의 단위·자료형·출처, Source Timestamp, 품질 상태와 갱신 책임자를 먼저 설계할 수 있습니다. 수동 입력과 CSV Import도 같은 API와 Validation을 통과하게 만들면 이후 IoT Gateway를 추가해도 표현 계층을 다시 만들 필요가 줄어듭니다. 3D 객체에는 표시 이름 대신 변하지 않는 Asset ID를 연결하고 데이터가 오래되었거나 없는 상태를 정상 상태와 구분해 표시해야 합니다.

    센서를 도입할 때는 수집 자체보다 Calibration, 보안, 장애·누락 처리, 저장 기간과 유지관리 비용을 함께 검토합니다. 가장 중요한 업무 질문 하나를 정하고 현재 데이터로 작은 End-to-end 흐름을 만든 뒤, 자동화 가치가 높은 속성부터 IoT로 전환하는 단계적 접근이 현실적입니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #673

    센서는 기술 이름이 아니라 관람객의 어떤 행동을 어떤 범위에서 구분해야 하는지부터 선택해야 합니다. 단순 접근·통과는 PIR, ToF 거리 센서, Photoelectric Sensor나 2D LiDAR로 구현할 수 있습니다. 바닥의 위치와 이동 경로는 Overhead Depth Camera, LiDAR 또는 Computer Vision을 검토하고, 손·신체 Gesture에는 Depth Camera나 RGB Camera 기반 Pose 추정을 사용할 수 있습니다. 물체 선택은 RFID·NFC, 버튼, Rotary Encoder, Load Cell과 Capacitive Touch가 명확한 입력을 제공합니다.

    비접촉 센서는 자연스러운 참여와 넓은 범위를 제공하지만 가림, 조명, 반사 재질, 군중 분리와 개인정보 설계를 고려해야 합니다. 직접 입력 센서는 의도가 분명하고 로직이 단순하지만 마모, 위생, 케이블과 파손 대응이 필요합니다. 압력 매트는 설치가 직관적이지만 하중 분포와 바닥 구조에 영향을 받고, 초음파는 부드러운 재질과 주변 음향·다중 센서 간섭을 시험해야 합니다.

    여러 사람이 참여하면 단순 Trigger 수보다 ID 유지와 상태 전이가 중요합니다. 진입·활동·이탈 조건, 최소 유지시간, Debounce, 동시 사용자 우선순위와 Timeout을 정의해야 화면이 빠르게 깜박이거나 이전 사용자의 상태가 남지 않습니다. 센서 데이터가 끊기면 안전한 기본 장면으로 돌아가고 운영자에게 상태를 표시하도록 설계합니다.

    현장에서는 FOV와 설치 높이, 조도, 네트워크·전원, 지연, 유지보수 접근성, SDK와 OS 지원 기간을 비교합니다. 실제 관람객 동선과 의상, 유모차·휠체어, 어린이 높이를 포함한 테스트가 필요합니다. 센서 하나로 모든 행동을 추정하기보다 중요한 이벤트에는 서로 다른 원리의 보조 입력이나 명시적 버튼을 두는 편이 안정적일 수 있습니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #671

    TouchDesigner는 실시간 영상·데이터·오디오와 외부 장치를 빠르게 연결하고 결과를 시각적으로 조정해야 하는 프로젝트에 잘 맞습니다. 카메라 영상 처리, Generative Visual, Projection Mapping, LED Pixel Map, 센서 기반 인터랙션, 공연용 실시간 그래픽과 프로토타입에서 노드 네트워크로 신호 흐름을 확인하며 개발할 수 있습니다. OSC, MIDI, DMX, Serial, Web과 다양한 미디어 입출력을 한 환경에서 연결하기 쉬운 점도 강점입니다.

    반면 복잡한 게임 규칙, 대규모 3D World, 다수 사용자의 Network Gameplay나 정교한 Character System이 중심이라면 Unreal 또는 Unity가 더 적합할 수 있습니다. TouchDesigner도 3D와 Python 확장이 가능하지만 모든 문제를 한 네트워크에 넣으면 의존관계와 상태 관리가 빠르게 복잡해집니다. 실제로는 TouchDesigner가 센서·영상 처리와 출력 합성을 맡고, 게임 엔진이 3D 장면과 상호작용을 담당하도록 프로토콜로 나누기도 합니다.

    도구 선택 전에 입력 수와 Format, 목표 해상도·Frame Rate, 출력 장치, 허용 지연과 장애 시 동작을 정합니다. GPU Memory, Codec Decode, TOP 해상도와 복사 구간을 측정하고 센서 입력이 끊겼을 때 Timeout과 기본 화면을 설계해야 합니다. 개발 화면에서 평균 FPS만 보는 대신 장시간 실행 중 Frame Drop, Memory 증가, 장치 재연결과 네트워크 복구를 기록합니다.

    운영 전시는 자동 시작, 프로젝트 버전 고정, 원격 상태 확인, 로그와 Watchdog, 현장 운영자가 사용할 단순한 Control Panel이 필요합니다. 콘텐츠 로직과 장비 주소·보정값을 분리하면 장소 변경과 유지보수가 쉬워집니다. 작은 입력→처리→출력 수직 Slice를 먼저 완성한 뒤 실제 해상도와 장비 수로 확장하는 방식이 안전합니다.

    관련 자료

    • 인터랙티브 전시 시스템의 기본 구성 (공개 예정)
    • 센서 → 미디어 서버 → 출력장치가 연결되는 과정 (공개 예정)
    • 공연·전시에서 실시간 렌더링을 활용하는 방법 (공개 예정)
    • Derivative: TouchDesigner Documentation

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #669

    Projection Mapping은 콘텐츠 제작보다 먼저 대상 표면, 관람 환경과 설치 가능 영역을 정확히 정의해야 합니다. 준비 자료의 출발점은 치수가 표시된 평면·입면·단면 도면과 현장 사진입니다. 투사 대상의 실제 가로·세로·깊이, 표면 색과 재질, 창문·조명, 기둥과 구조물, 관객 동선, 프로젝터를 고정할 수 있는 위치를 기록합니다. 도면이 없으면 기준 치수를 포함한 사진과 Laser Measure 실측표라도 필요합니다.

    다음으로 관람 거리와 시간대, 주변 조도, 목표 화면 영역과 콘텐츠 비율을 정합니다. 밝기는 ANSI Lumen 숫자 하나로 결정하지 않고 화면 면적, 표면 반사, 주변광, 겹침과 색 표현을 함께 시험해야 합니다. 후보 설치점에서는 Throw Ratio로 필요한 렌즈를 계산하고, Lens Shift 범위·초점거리·배기 방향·소음·정비 공간을 확인합니다. 관객이 광로를 가리는 경우 높이 조정, 단초점, 후면 투사 또는 여러 대 분할을 비교합니다.

    복수 프로젝터라면 Edge Blending과 Warp 영역, 동기 출력, 미디어 서버 해상도와 케이블 경로를 설계합니다. 전력 용량과 회로 분리, 구조물 하중, 안전 와이어, 방수·온도·환기, 네트워크와 운영자 위치도 장비 목록에 포함해야 합니다. 콘텐츠팀에는 대상의 UV 또는 3D 모델, 최종 Pixel Map, Safe Area와 테스트 패턴을 같은 버전으로 전달합니다.

    초기에는 NALDA Projector Calculator로 화면 폭·거리·Throw Ratio를 비교하고 XR Project Budget Estimator로 필요한 구성 범위를 점검할 수 있습니다. 최종 확정 전에는 실제 후보 프로젝터와 표면으로 밝기·색·초점 테스트를 하고, 설치·캘리브레이션·리허설·철거 시간을 포함한 실행 계획을 세워야 합니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #667

    Virtual Production의 Camera FOV는 화면 구도뿐 아니라 물리 LED가 카메라 프레임을 얼마나 채우는지와 가상 Frustum의 정확도를 동시에 결정합니다. 초점거리가 짧아 FOV가 넓어지면 LED Wall 가장자리, 천장, 바닥이나 스튜디오 장비가 프레임에 들어올 수 있습니다. 이를 피하려고 카메라를 가까이 이동하면 Tracking 정확도, 배우 동선, 초점과 Moiré 조건이 달라집니다.

    실시간 엔진은 추적된 카메라 Pose와 Lens Parameter를 이용해 해당 시점의 Perspective를 렌더합니다. 센서 크기, 실제 초점거리, Principal Point와 Lens Distortion 값이 부정확하면 카메라를 움직일 때 실제 세트와 가상 배경의 선이 미끄러지거나 축척이 어색해집니다. 단순 사양표의 Horizontal FOV만 입력하는 것보다 렌즈별 Calibration Profile을 만들고 Zoom·Focus 위치에 따른 변화를 관리하는 것이 중요합니다.

    물리 설계에서는 후보 카메라 위치마다 LED의 가로·세로 각도를 계산하고 목표 Aspect Ratio에서 안전 영역을 확인합니다. 배우와 소품이 LED에서 얼마나 떨어지는지, 카메라가 얼마나 Pan·Tilt·Dolly하는지 포함해 최악 구도를 그려야 합니다. 렌즈가 넓을수록 Tracking Marker나 반사 장비가 보일 가능성도 커지며, 좁은 렌즈는 배경을 채우기 쉬워도 카메라 거리가 늘고 공간 활용이 제한될 수 있습니다.

    NALDA Camera FOV Calculator로 센서, 초점거리와 거리별 촬영 폭을 비교한 뒤 실제 카메라와 렌즈로 Grid 촬영, Lens Calibration과 Tracking 정합 테스트를 진행하십시오. FOV만 맞춰도 동기 지연, LED Scan, Moiré와 색상 문제는 별도로 남으므로 대표 카메라 움직임과 촬영 설정을 포함한 통합 테스트가 필요합니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #665

    이론 해상도는 화면의 물리 길이를 Pixel Pitch와 같은 단위로 바꾼 뒤 나누어 구합니다. 가로 해상도는 가로 길이(mm) ÷ Pitch(mm), 세로도 같은 방식입니다. 예를 들어 8m는 8,000mm이므로 후보 Pitch로 나누면 대략적인 픽셀 수를 얻습니다. 다만 이 값은 비교용이며 실제 LED는 임의 길이로 자르는 화면이 아니라 Module과 Cabinet의 정수 개수로 조립됩니다.

    최종 해상도는 선택한 Cabinet 한 장의 픽셀 해상도에 가로·세로 Cabinet 수를 곱해 확정합니다. 물리 크기도 Cabinet 외형 치수의 합으로 다시 계산해야 합니다. 따라서 목표 크기에서 Pitch를 나눈 값과 실제 조립 해상도가 다르면 제품 구성표가 우선입니다. 곡면이나 모서리, 반쪽 Cabinet, 특수 Module이 포함되면 영역별 해상도와 배선을 별도로 정리합니다.

    LED 프로세서에서는 전체 화면을 하나 이상의 Output Port와 Receiving Card에 매핑합니다. 최종 픽셀 수가 프로세서의 총 처리 용량과 포트별 Load, 케이블 토폴로지 안에 들어가는지 확인해야 합니다. 렌더 Canvas는 LED Native Resolution과 꼭 같을 필요는 없지만 비율과 Scaling 정책을 명시하지 않으면 글자와 선이 흐려지거나 좌표 기반 콘텐츠가 맞지 않을 수 있습니다. 여러 렌더 노드라면 각 노드 담당 영역과 Overlap도 계산합니다.

    NALDA LED Wall Calculator는 화면 크기와 Pitch로 이론 해상도를 빠르게 비교하는 도구입니다. 그 다음 제조사의 Module·Cabinet Data Sheet, Processor Mapping과 콘텐츠 서버 출력 제한을 차례로 대조하십시오. 최종 문서에는 물리 크기, Cabinet 배열, Native Resolution, 입력 Canvas와 Scaling 주체를 함께 기록해야 현장 설정 오류를 줄일 수 있습니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #663

    사각지대는 단순히 카메라 영상이 닿지 않는 영역뿐 아니라, 추적에 필요한 시점 수와 교차각이 부족한 영역까지 포함합니다. 평면 FOV 도면은 첫 단계이지만 사람과 소품의 높이, 구조물과 다른 배우가 만드는 3차원 가림을 보여주지 못합니다. 공간을 여러 높이의 단면으로 나누고 각 지점에서 대상이 몇 대의 카메라에 어떤 각도로 보이는지 확인해야 합니다.

    카메라를 같은 높이와 같은 방향으로 배치하면 대상 한쪽이 가려질 때 여러 시점이 동시에 사라질 수 있습니다. 높낮이와 방위각을 분산하고, 빠른 회전이나 바닥 동작이 있는 구역에는 상부 시점을 보강합니다. 지나치게 넓은 렌즈는 면적을 늘리지만 대상의 픽셀 크기를 줄여 검출 거리를 떨어뜨릴 수 있으므로 FOV와 필요한 공간 해상도를 함께 비교해야 합니다. 카메라가 서로를 정면으로 보거나 강한 조명·반사체를 마주보는 배치도 피합니다.

    설치 전에는 무대 장치, LED 벽, 기둥과 관객을 포함한 3D 모델에서 시야선을 검토하고 케이블·정비 접근성까지 확인합니다. 이후 임시 설치로 캡처 볼륨 전체를 격자 형태로 이동하며 관측 카메라 수, 잔차, ID 교환과 복구 시간을 기록합니다. 대표 소품과 실제 의상을 사용해 회전·교차·웅크림 같은 최악 동작도 시험해야 합니다.

    카메라 추가는 마지막 수단이 아니라 배치 대안 중 하나입니다. 위치 조정, 렌즈 교체, 마커 배치 변경이나 IMU 등 보조 센서와 결합하는 편이 더 효과적일 수 있습니다. NALDA Camera FOV Calculator로 각 후보의 촬영 폭과 높이를 먼저 계산한 뒤 제조사 캘리브레이션 도구와 실제 추적 품질 지표로 확정하는 것이 좋습니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #661

    Sampling Rate가 높으면 더 빠른 변화를 관측할 가능성은 커지지만, 정확도와 전체 반응성이 자동으로 좋아지는 것은 아닙니다. 먼저 측정하려는 신호의 유효 주파수 대역을 알아야 합니다. 관심 신호보다 충분히 빠르게 샘플링해야 Alias를 피할 수 있지만, 센서 앞단의 Anti-alias Filter와 실제 대역폭이 낮다면 숫자만 높은 출력은 새로운 정보를 추가하지 못할 수 있습니다.

    높은 Rate는 데이터량, 버스 점유율, CPU 처리, 저장 공간과 전력 소비를 늘립니다. 센서 내부 필터나 Averaging 설정에 따라 출력 주기가 빨라도 실제 응답 대역이 좁을 수 있고, 노이즈 샘플도 더 많이 들어옵니다. 반대로 강한 Low-pass Filter는 신호를 매끄럽게 하지만 위상 지연을 만들므로 인터랙션의 체감 반응을 늦출 수 있습니다. 데이터시트에서 Output Data Rate와 Sensor Bandwidth를 구분해 확인해야 합니다.

    전체 시스템은 센서→드라이버→네트워크→처리→렌더의 각 주기가 연결됩니다. 1kHz로 측정해도 네트워크가 20Hz로 묶어 보내거나 화면이 60fps라면 모든 샘플을 개별 시각화할 수 없습니다. 그렇더라도 제어·충돌 검출이나 정확한 적분을 위해 내부에서는 높은 Rate를 유지하고, 화면에는 다운샘플 또는 보간한 값을 보낼 수 있습니다. 각 단계에 원본 Timestamp를 유지해야 지연과 순서를 올바르게 처리할 수 있습니다.

    선택 방법은 대표 동작의 최대 변화 속도와 허용 지연을 정한 뒤 낮은 Rate부터 올리며 누락, Noise, CPU와 End-to-end Latency를 측정하는 것입니다. Packet Loss와 Jitter 상황도 시험하고, 기록 목적과 실시간 제어 목적의 데이터 경로를 분리하면 필요 이상의 Rate로 전체 시스템을 부담시키지 않을 수 있습니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #659

    MQTT와 OPC UA는 경쟁 관계라기보다 서로 다른 문제를 해결하므로 함께 사용하는 구성이 흔히 가능합니다. MQTT는 Broker를 중심으로 Topic에 메시지를 Publish·Subscribe하는 가벼운 전송 패턴을 제공합니다. Payload의 의미와 데이터 모델은 애플리케이션이 정합니다. OPC UA는 산업 자산의 구조, 데이터 타입, 상태, Method와 보안 등을 표현하고 접근하는 표준화된 정보 모델과 서비스가 강점입니다.

    한 가지 구성은 현장 Gateway가 OPC UA Server에서 필요한 Node를 구독하고, 값을 정규화해 MQTT Topic으로 발행하는 방식입니다. 이때 단순히 숫자만 보내지 말고 Asset ID, 원본 Node 식별자, 단위, Source Timestamp, 품질 상태와 Schema Version을 함께 보존해야 합니다. 반대 방향의 명령은 조회 데이터와 분리된 Topic, 권한과 확인 응답을 설계하고, 네트워크가 끊긴 동안의 재전송과 중복 처리 정책도 정해야 합니다.

    다른 선택지는 OPC UA PubSub 자체의 MQTT Transport Mapping을 사용하는 것입니다. OPC Foundation 규격은 MQTT Topic과 JSON 또는 UADP 메시지 매핑을 정의합니다. 다만 사용하는 장비와 SDK가 해당 프로파일을 실제로 지원하는지 확인해야 하며, 임의 JSON Gateway와 표준 OPC UA PubSub는 상호운용 범위가 다릅니다.

    설계 시에는 먼저 소비자가 필요한 의미와 갱신 특성을 정하고, Edge와 Cloud 사이의 책임을 구분합니다. TLS, 인증서 또는 자격 증명, Topic·Node별 권한, Broker와 OPC UA Endpoint의 방화벽 범위를 각각 구성해야 합니다. 기록 데이터로 연결 끊김, 순서 역전, 오래된 값과 중복 메시지를 시험하면 Digital Twin 화면이 잘못된 최신 상태를 표시하는 위험을 줄일 수 있습니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #657

    RS485의 핵심은 두 선 사이 전압 차이를 읽는 균형 차동 신호입니다. 외부 잡음이 꼬임선 두 도체에 비슷하게 유입되면 수신기는 공통 성분을 상당 부분 제거하고 두 선의 차이를 판별할 수 있습니다. 단일 기준선에 대한 전압을 읽는 일반 UART 배선보다 잡음 환경과 긴 케이블에 유리한 이유입니다. 다만 가능한 거리는 케이블, 속도, 트랜시버와 환경에 따라 달라지므로 고정된 최대 숫자로 설계하면 안 됩니다.

    RS485는 주로 물리 계층을 정의하며 메시지 주소와 데이터 의미까지 정하는 프로토콜은 아닙니다. Modbus RTU, BACnet MS/TP 또는 자체 프레임이 RS485 위에서 동작할 수 있습니다. 따라서 장치가 모두 RS485 단자를 갖고 있어도 Baud Rate, 데이터 비트, Parity, 주소와 상위 프로토콜이 맞지 않으면 통신하지 않습니다.

    배선은 가능한 한 하나의 선형 Bus로 구성하고 긴 Star 분기는 피합니다. 케이블의 특성 임피던스에 맞는 종단을 버스 양 끝에 배치하며, 유휴 상태가 불안정하지 않도록 Bias 회로가 어느 장치에 있는지 확인합니다. Stub 길이와 통신 속도가 커질수록 반사가 문제가 되므로 길이가 늘면 속도를 낮추는 Trade-off를 고려합니다. A/B 표기 관례가 제조사마다 혼동될 수 있어 데이터시트의 극성을 기준으로 확인해야 합니다.

    장치 간 접지 전위차가 큰 현장에서는 차동 신호만 믿지 말고 공통 기준, 차폐, Surge 보호와 Galvanic Isolation을 검토합니다. 설치 전 케이블 전체 길이와 분기, 종단 위치를 도면화하고 오실로스코프 또는 통신 오류 로그로 최악 조건을 확인하는 것이 안전합니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:19 오후 #655

    LiDAR와 Depth Camera는 모두 깊이를 측정할 수 있지만 하나의 고정된 기술 이름과 제품군으로 단순 비교하기는 어렵습니다. LiDAR는 보통 레이저를 방사하고 반사 신호의 비행시간이나 위상 차이를 측정해 거리 샘플을 얻습니다. 회전형·고정형, 2D·3D 제품에 따라 결과가 스캔 라인 또는 Point Cloud로 제공됩니다. Depth Camera는 Stereo, Structured Light, Time-of-Flight 등 서로 다른 방식으로 픽셀별 깊이 맵을 만들며 RGB 영상과 정렬된 데이터를 함께 제공하기도 합니다.

    LiDAR는 비교적 넓은 거리와 공간 윤곽 측정에 유리한 제품이 많지만 각도 해상도, 최소거리, 반사율과 스캔 패턴을 확인해야 합니다. Depth Camera는 가까운 범위에서 사람의 형태와 손·신체 영역을 조밀하게 얻기 편하지만 FOV 밖으로 벗어나거나 사람끼리 가릴 때 데이터가 사라집니다. Stereo 방식은 표면 무늬와 조명 조건, 능동 적외선 방식은 햇빛과 다른 적외선 장치의 간섭, ToF는 다중 경로 반사와 재질 영향을 받을 수 있습니다.

    선택 기준은 센서 이름보다 필요한 출력입니다. 단순 입장 감지인지, 사람 중심점 추적·Skeleton·정밀 표면 복원인지 정의하고 거리, FOV, 업데이트 주기, 지연, 공간 해상도와 허용 누락률을 정합니다. 유리·거울·검은 천·반짝이는 금속, 안개와 강한 조명은 실제 장소에서 반드시 시험해야 합니다. 여러 센서를 쓰면 서로의 능동 광원이 간섭하는지도 확인합니다.

    마지막으로 SDK 지원 운영체제, 타임스탬프, 좌표계, 네트워크 대역폭, 발열과 장시간 안정성을 검토합니다. 대표 동선과 혼잡 상황을 기록해 원시 Depth·Point Cloud와 최종 추적 결과를 함께 비교하면 센서 하드웨어의 한계와 인식 알고리즘의 문제를 구분할 수 있습니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:18 오후 #653

    Blender는 3D 자산을 만들고 정리하는 DCC 도구, Unreal Engine은 그 자산을 실시간으로 실행하고 상호작용시키는 엔진으로 구분하면 이해하기 쉽습니다. Blender에서는 모델링, UV, 텍스처 제작, 리토폴로지, 애니메이션과 메시 정리를 수행합니다. Unreal에서는 실시간 렌더링, 레벨 구성, 조명, 사용자 입력, 센서 데이터 연동, UI와 실행 파일 배포를 담당합니다.

    CAD 기반 자산은 그대로 가져오면 폴리곤 수, 작은 부품, 중복 메시와 복잡한 재질 때문에 실시간 성능이 떨어질 수 있습니다. 원본 CAD는 별도로 보존하고 Blender 또는 전용 변환 단계에서 불필요한 내부 형상 제거, 메시 결합·분리, 노멀과 UV 정리, LOD 준비를 진행합니다. Unreal에서는 화면 크기와 중요도에 따라 LOD·가시성·Collision을 적용하고, 반복 자산은 Instancing을 검토합니다.

    왕복 수정에서 가장 중요한 것은 파이프라인 규칙입니다. 단위를 미터 또는 센티미터 중 하나로 정하고 좌표축 변환, 객체 원점과 Pivot, 이름 규칙, 재질 슬롯과 애니메이션 프레임레이트를 문서화합니다. 내보내기 전에 Transform 적용 여부를 통일하고, Unreal에서 수동으로 바꾼 재질이나 배치를 재임포트가 덮어쓰지 않도록 원본 자산과 엔진 오버라이드의 책임 범위를 나눕니다.

    FBX, glTF, Datasmith 등 형식마다 전달할 수 있는 카메라·재질·애니메이션 정보가 다르므로 작은 기준 자산으로 먼저 왕복 테스트해야 합니다. Blender와 Unreal 중 하나를 선택하는 문제가 아니라 자산의 원본 편집과 실시간 실행을 분리하고, 변경 이력을 안정적으로 전달하는 과정이 핵심입니다.

    관련 자료

    NALDA Factory 운영자 답변

    root
    8월 13, 2026 9:18 오후 #651

    Unreal Engine은 Digital Twin의 강력한 3D 표현·상호작용 계층이 될 수 있지만, 일반적으로 전체 플랫폼을 혼자 대체하지는 않습니다. 엔진은 공간 모델, 재질과 조명, 애니메이션, 실시간 UI, 사용자 입력과 시뮬레이션을 처리하는 데 적합합니다. 반면 장비 연결, 메시지 수집, 데이터 정규화, 시계열 저장, 사용자 인증, 감사 기록과 업무 규칙은 별도 백엔드가 담당하는 편이 구조를 분리하기 쉽습니다.

    권장 흐름은 센서·PLC·기존 시스템에서 데이터를 수집한 뒤 Gateway 또는 Broker가 프로토콜과 단위를 정리하고, Backend가 자산 ID·상태·이력을 관리한 다음 API나 실시간 메시지로 Unreal 클라이언트에 필요한 상태만 전달하는 방식입니다. Unreal에서는 수신 값을 특정 Actor와 연결하고, 보간·임계값·시각 상태를 적용합니다. 이때 3D 객체 이름을 장비 주소로 직접 사용하기보다 안정적인 Asset ID와 별도 매핑 테이블을 두는 것이 좋습니다.

    프로토타입에서 모든 로직을 Blueprint에 넣으면 빠르게 화면을 만들 수 있지만 장비가 늘 때 데이터 처리와 UI 코드가 얽힐 수 있습니다. 연결 계층, 도메인 모델과 표현 계층을 나누고 재연결, 누락값, 오래된 데이터, 시간대와 단위 변환을 명시적으로 처리해야 합니다. 실시간 화면도 모든 센서 원시값을 그대로 보내기보다 목적별 업데이트 주기와 변화량 기준을 정해 대역폭과 렌더 부하를 제어합니다.

    시작할 때는 대표 자산 한두 개로 수집→저장→상태 판정→3D 표시의 전체 경로를 먼저 완성하고, 재생 가능한 기록 데이터로 장애 상황을 시험하는 것이 좋습니다. Unreal 버전, 배포 대상, 플러그인 유지보수와 데이터 보안 요구도 초기 아키텍처에 포함해야 합니다.

    관련 자료

  • 글쓴이
    글
15 글 보임 - 1 에서 15 까지 (총 20 중에서)
1 2