로봇 공학에서 실시간 프로그래밍은 얼마나 성숙합니까? [닫은]

편집 : 이유를 모르겠지만이 질문은 많은 사람들을 혼란스럽게합니다. 실시간 사용시기 / 장소 / 이유 / 방법을 알고 있습니다. 나는 실시간 작업을하는 사람들이 실제로 그것을 실시간으로 구현하기에 충분히 신경을 쓰는지 아닌지 알고 싶습니다.

로봇에 실시간 작업이 중요한 이유를 언급 할 필요는 없습니다. 그러나 내 질문은 실제로 로봇 공학에서 얼마나 많이 사용됩니까?

가지고 이 질문에 예를 들어. 실시간 기능을 갖춘 모든 플랫폼에 대한 답변은 단 한 가지뿐입니다. ROS는 실시간이 아닌 매우 인기있는 플랫폼입니다.

그러나 실시간 세계에서 RTAI ¹ 은 유일하게 작동 가능한 무료 실시간 플랫폼입니다. 그러나 Linux (문제 없음)로 제한되며 잘못 문서화되고 천천히 개발되었습니다.

그렇다면 로봇 개발자들 사이에서 실시간 행동은 얼마나 요구됩니까?문제는 실시간 동작이 실제로 필요할 때 개발자가 실시간 애플리케이션을 작성하려는 경향이 얼마나됩니까? 많지 않은 이유는 무엇입니까?

예를 들어, 촉각 데이터를 기반으로하는 재귀 동작은 실시간 속성을 잃을 수 있으므로 ROS를 통과 할 수 없습니다. 그러나 사람들은 실제로 실시간 속성을 무시하고 실시간 솔루션을 찾거나 ROS를 사용합니까?

¹ 또는 유사하게 Xenomai

가 있다는 것을 기억 리얼 타임을 하고있다 실시간가 .

하드 리얼 타임은 하드웨어 지원 또는 낮은 수준의 소프트웨어 지원없이 달성하기 어렵습니다,하지만 당신은 종종로 모든 것을하지 않아도 하드 리얼 타임이 가능. Soft & Firm Real Time 응답은 달성하기가 훨씬 쉽고 많은 응용 분야에 적합합니다.

또한 시스템의 다른 부분은 실시간 요구 사항 이 매우 다를 수 있습니다 . 소프트웨어 PID 루프를 실행하는 경우 실제로 실시간 응답 이 어려워 야합니다 (예를 들어 PID를 소프트 튜닝 또는 하드 튜닝 및 때때로 불안정하게 만드는 것을 선택하지 않아도 됨). 비전 시스템에는 확실한 실시간 응답 요구 사항이있을 수 있습니다. 다음 결정을 위해 이미지를 적시에 처리 할 수없는 경우 성능이 저하되지만 시스템 실행을 방해 할 필요는 없습니다 (이 경우 처리 할 수없는 경우). 부분 결과를 버리고 다음 프레임에서 분석을 시작하는 시간을 잃지 않는 것이 좋습니다. 마지막으로 전체 계획 및 조정 (아마도 가장 복잡한)로봇 시스템의 일부)를 종종 부드러운 실시간 영역에 단단히 고정시킬 수 있습니다 .

Windows PC의 영역에서도 실시간으로 어려운 성능을 얻을 수 있지만 커널에 제대로 연결되어있는 올바른 소프트웨어 만 있으면됩니다. Beckhoff 의 TwinCat 소프트 PLC는 Pentium의 기계주기의 절반을 슬라이스하여 나머지는 절반을 Windows NT에 제공함으로써 매우 높은 스캔 속도 PLC를 실행했으며,이 중 절반은 10 년 전이었습니다. Aerotech의 A3200 범위의 일부 옵션과 같은 최신 제어 시스템조차도 호스트 PC에서 거친 작업을 수행합니다. 낮은 수준의 커널은 어려운 실시간 요구 사항에 필요한만큼 많은 CPU 시간을 소비 하고 Windows 7의 나머지 CPU 사이클은 그대로 둡니다. 쓰다!

많은 (대부분의) 로봇 제어 시스템에는 실제로 실시간 시스템이 필요하지 않습니다. 지터가 적고 속도가 충분히 빠르며 너무 많은 사이클을 놓치지 않는 제어 루프가 있으면 로봇 제어 및 서 보링에 매우 적합합니다.

이것의 증거로 PR2와 Shadow Robot Hand를 소개하겠습니다.

이 로봇은 자유도가 약 20도이며 ROS의 메인 루프를 통해 서보됩니다. 또는 20 개의 DOF와 촉각 및 기타 센서 배열이 있으며 ROS의 메인 루프를 통해 서보되는 Shadow Robot Hand는 어떻습니까?

ROS 메인 루프는 때때로 100us 정도의 작은 지터를 겪으며 때로는 사이클을 놓치기도합니다. 그러나 99.9 %의주기가 성공적으로 실행되는지는 중요하지 않습니다.

호스트 PC 내에서 많은 코어를 사용한다는 것은 하나의 전체 코어가 메인 루프 실행에 전념하기 때문에 다른 작업에 의해 지연되는 경우는 거의 없습니다.

로봇 시스템에 실시간 OS를 사용하는 주된 이유는 안전을위한 것입니다. 로봇이 안전이 중요한 상황에서 작업하는 경우 100 % 제어 가동 시간을 보장하는 것은 귀하의 책임이며, 그 중 일부는 실시간 특성을 보장하는 것입니다.

실시간 OS 사용 여부에 관계없이 제어 루프가 완전히 종료되는 경우 서보는 안전한 작업을 수행해야합니다. 이 안전 시스템은 또한 비 실시간 OS가 사이클 이상으로 건너 뛰는 경우가 거의 없습니다. 예를 들어, Shadow Hand에서 제어 루프가 20주기 (20ms)를 초과하면 모터가 정지됩니다. 나는 이것이 일어나는 것을 본 적이 없다.

추가

그것에 대해 생각하는 또 다른 방법은 이것입니다 : 서보 시스템에는 실제로 어떤 업데이트 속도가 필요합니까? 그것이 게으른 팔이고 초 고성능, 고속 포지셔닝이 필요하지 않으면 500Hz로 충분할 수 있습니다. 주위를 돌아 다니려면 200Hz면 충분합니다. 두 경우 모두 루프가 실제로 1000Hz로 실행되는 경우 제어 알고리즘이 루프 사이의 실제 경과 시간을 고려하는 한 늦거나 누락 된 사이클은 전혀 문제가되지 않습니다.

소프트웨어의 목적에 따라 소프트웨어가 실시간이어야하는지 여부가 결정됩니다.

경로 계획 또는 로컬라이제이션이 목적인 경우, 종종 10Hz와 같이 저주파가 충분합니다. 이 경우 Linux에서 실행되는 플레이어 / 스테이지 설정이 좋습니다. 한 번의 단계가 조금 길거나 짧으면 문제가 거의 없음을 알 수 있습니다.

로봇 역학이 빠른 경우 엄격하게 실시간 동작이 필요합니다. 예를 들어, 로봇 팔을 움직여서 위치를 추적하거나 물체를 처리 / 잡아 이동시킵니다. 시간 단계를 놓치면 위치가 바람직하지 않게 초과 될 수 있으며보다 예측 가능한 동작을 원할 수 있습니다. 이 경우 최대 1kHz 이상의 주파수를 가질 수 있습니다. 운영 체제를 사용하는 경우 실시간 운영 체제를 원합니다.

타이머 및 인터럽트 (마이크로 컨트롤러에서 컴파일 된 C 코드)를 사용하여 임베디드 애플리케이션에서 실시간 동작을 수행 할 수 있습니다. 이 경우 정기적 인 샘플링 주파수를 유지할 수 있도록 처리 부하가 너무 높지 않아야합니다.

컴퓨터 / 마이크로 프로세서를 사용하는 로봇은 (더 많은 처리 능력이 필요하기 때문에) 높은 샘플링 속도를 보장하기 위해 실시간 운영 체제를 사용해야합니다.

따라서 실시간 동작이 필요한지 여부는 개발자가 용도에 따라 다릅니다.

당사는 PIC 마이크로 컨트롤러에서 실행되는 FreeRTOS를 사용하여 로봇을 구축합니다. 우리에게 FreeRTOS를 사용하는 주된 이유는 작업 우선 순위를 쉽게 재정렬하고, 여러 통신 회선을 동시에 처리하고, 인터럽트 처리기와 주요 작업간에 쉽게 통신 할 수 있기 때문입니다. 마이크로 컨트롤러는 우리가 생산하는 각 로봇에 전체 리눅스 머신을 설치하는 것보다 훨씬 저렴합니다.

실제로 실시간이 필요한 경우 실시간 운영 체제를 사용합니다. 안전 모니터링, 데이터 수집 및 일정한 샘플 속도 제어 루프는 실시간 스케줄링을 사용하는 일반적인 하위 시스템입니다.

프로그래밍의 실시간 부분은 일반적으로 가능한 한 작습니다. 디버그하기가 어렵고 코드의 정확성을 확인하기가 더 쉽기 때문입니다. 실시간 OS에 대한 문서는 일반적으로 매우 좋습니다 (RTAI / Xenomai 포함).

다른 실제 로봇 프로젝트 에서 QNX 및 RTAI-> Xenomai를 사용 했습니다. QNX를 선호했지만 Xenomai는 그와 마찬가지로 효과적이었습니다.

Orocos 는 성숙한 실시간 로봇 제어 소프트웨어 프레임 워크입니다. 어려운 실시간 요구 사항으로 고속 로봇 조작기를 성공적으로 제어하는 ​​데 사용되는 것을 보았습니다. ROS, 통신, 구성, 직렬화 및 구성 요소 기반 패키징과 동일한 프레임 워크 레벨 구성 요소가 많이 있습니다.

다중 CPU 및 실시간 질문 이동 측면에서 로봇에 대해 생각하십시오. 2 륜 밸런서 또는 쿼드 콥터 스태빌라이저 또는 서보 펄스 출력과 같은 고속의 안정적인 피드백이 필요한 알고리즘이있는 경우 실시간이 매우 중요하지만 작업도 매우 제한적입니다.

이와 같은 제어 루프를 Arduino 급 장치에서 사용되는 저렴한 8 비트 AVR 또는 저가형 32 비트 ARM과 같은 전용 실시간 CPU로 오프로드 할 수 있습니다. 전용 제어 루프를 실행하는 수십 개의 소형 MCU를 추가하는 것을 막을 수있는 것은 없습니다. USB 장치 열거는 심지어 이것을 용이하게합니다.

전용 CPU로 타이밍에 민감한 제어 루프를 처리 했으므로 Linux의 ROS 또는 Windows 용 Kinect와 같은 구성 요소를 사용하여 고급 로직을 실행할 수있는 로봇의 '두뇌'의 실시간 요구를 완화 할 수 있습니다.

"언제 / 언제"실시간 시스템이 사용 된 경우 :

내 경험에 따르면 모션 제어는 실시간 시스템의 주요 응용 프로그램입니다. 모터를 제어하려면 고주파 (100hz, 1000hz 이상) 및 낮은 지터 (시간 변화)가 중요합니다. 안전은 여기에서 큰 포인트입니다. 인간 사이의 로봇을 고려하십시오. 예를 들어, 로봇 (팔)이 특정 시간 프레임 / 거리에서 정지되도록해야합니다.

경로 계획, 비전 처리 및 추론 실시간 시스템과 같은 다른 작업의 경우 개발 시간 및 하드웨어 비용의 오버 헤드로 인해 중요하지 않으며 종종 피할 수 있습니다.

오늘날 PR2와 같은 대형 로봇은 두 세계를 결합합니다. RT 지원 운영 체제 (예 : Linux + Xenomai) 모션 제어의 실시간 컨텍스트에서 비 실시간 부분 (사용자 영역)에서 비전 처리 및 계획은 ROS와 같은 시스템에 내장되어 있습니다. 둘 다 같은 컴퓨터에서 실행할 수 있습니다.

질문이 명확 해지면이 답변을 편집 해 드리겠습니다. :-)

예, 스케줄러가 프로세스와 스레드를 적절히 시퀀싱 할 수없는 경우 하드웨어 리소스가 타이밍 요구 사항 (충분한 처리 능력, 낮은 대기 시간)을 충족 할 수 있다고 가정하면 실시간 스케줄러를 사용합니다. 이것의 도전. 실시간 조건에 맞게 하드웨어 드라이버를 최적화 할 수도 있습니다.

예, 소프트웨어가 필요한 시간 제약 조건에서 작동한다고 보장 할 수없는 경우 실시간 접근 방식을 사용합니다.

좋은 해결책 중 하나는 둘 다하는 것입니다. 작은 마이크로 컨트롤러, 엄격한 서보 제어 루프 등에 "하드"실시간 기능을 사용하는 디자인입니다. 그런 다음 Linux 및 ROS를 실행하는 더 큰 CPU가 있습니다. ROS가 더 높은 수준의 작업을 처리하고 uP는 스테퍼 모터 제어 또는 PID 루프 실행과 같은 작업을 처리하도록했습니다.

다른 사람들이 위에서 말했듯이 비 실시간 OS가 1KHz 제어 루프를 실행하도록 허용 할 수 있지만 이것이 작동하려면 대부분의 시간을 유휴 루프에서 소비하는 과도한 오버 킬 크기의 컴퓨터가 필요합니다. 거의 100 % CPU 사용률로 Linux / ROS 컴퓨터를 실행하면 실시간 성능이 저하됩니다. 2 계층 설계를 사용하면 항상 우수한 RT 성능을 얻을 수 있으며 더 작고 전력 소비가 적은 컴퓨터를 사용할 수 있습니다 (Pi2 높은 수준의 작업 일 가능성이 있습니다). 현재 uP는 OS를 실행하지 않지만 FreeRTOS로 전환하고 있습니다.