답변:
나는 컴퓨터로 돌아왔다!
이 의견 에서 말했듯 이 ROS는 일반적으로 필수는 아닙니다. ROS는 많은 플랫폼 중 하나이며, 대부분의 ROS 모듈을 작성한 사람에게 특정 시점에 무료 로봇을 제공하는 Willow Garage로 인해 유명합니다. 즉, 가능한 최고의 플랫폼이 아니며 지나치게 특별하지는 않습니다. 특히,이 콘테스트는 단지 숫자를 높이기 위해 많은 저품질 모듈을 만들었습니다.
시간이 지남에 따라 ROS 모듈의 품질이 향상되었으며 많은 모듈도 있습니다. 따라서 ROS를 사용하면 이미 수행 한 많은 작업을 재사용 할 수 있다는 이점이 있습니다. ROS를 사용하고 싶은 몇 가지 이유를 여기에서 읽을 수 있습니다 .
이를 염두에두고 부작용도 찾아봐야합니다.
ROS를 사용하면 네트워크를 통해 서로 통신하는 많은 노드가 있습니다. 이것은 때때로 좋고 쉬운 일이지만 일반적으로 메시지 수신이 크게 달라집니다. 결과적으로 모든 메시지가 도착할 수 있도록 제어 지연이 커야합니다. 즉, 이벤트에 빠르게 반응 할 수 없으므로 해당 이벤트를 놓치지 않도록 로봇을 더 느린 속도로 이동해야합니다.
믿거 나 말거나 사람들은 실제로 ROS를 통해 로봇 제어를 수행합니다 ( MoveIt! 는 관련 구성 요소 세트의 이름입니다). 느린. 위험한. 하지만 쉬워요!
배포되지 않은 경우에도 ROS는 실시간 플랫폼이 아닙니다. 즉, Linux 커널에 대한 판단에 따라 언제든지 작업을 예약 할 수 있습니다. 일부 응용 프로그램에는 문제가 없지만 다른 응용 프로그램에는 문제가 없습니다. 따라서 자신의 요구 사항을 살펴 봐야합니다. 당신은이해야합니까 보장 귀하의 작업이 알려진 시간 내에 끝낼 것입니까? 그렇다면 실시간 시스템이 필요합니다.
고려해야 할 또 다른 요점은 ROS는 일반적인 통신 프로토콜이지만 호스트 환경에서만 기본적으로 지원된다는 것입니다. Hosted 는 코드가 하드웨어에서 직접 제어하는 (예 : 마이크로 컨트롤러) 독립형 이 아니라 커널 위에서 실행 되는 것을 의미합니다.
로보틱스 응용 프로그램이 하드웨어 가까이에서 실행되므로 마이크로 컨트롤러에서 실행되는 프로그램이 필요한 경우 ROS는 도움이되지 않습니다.
마지막으로 ROS 용으로 개발하면 플랫폼이 잠 깁니다. 이는 미래에 어떤 이유로 든 OROCOS, YARP 등과 같은 다른 로봇 플랫폼을 기반으로 작업을 수행하기로 결정한 경우 매우 치명적임을 의미합니다.
또한 Linux에 다소 잠겨 있습니다. 의심 할 여지없이 Linux가 가장 좋지만 언젠가는 QNX, VxWorks 등과 같은 다른 시스템을 지원해야 할 수도 있습니다. 문제가있을 수도 있습니다.
마이크로 컨트롤러를 작성하는 경우 ROS를 잊어 버리십시오. 고급 모듈을 작성하는 경우 휴대용 코드를 작성하는 것이 좋습니다. 예를 들어, 새로운 센서를 개발했으며 CAN 버스를 통해 컴퓨터에 연결된이 센서에서 데이터를 수집하는 모듈을 작성하려고한다고 가정하십시오.
이 상황에서 할 수있는 일은 센서로 작업하고 데이터를 수집 할 수있는 기능으로 독립 라이브러리를 작성하는 것입니다. 주기적으로 데이터를 수집하고 큐에 넣는 라이브러리에서 스레드를 생성하는 것을 생각할 수도 있습니다.
이 헬퍼 라이브러리가 있으면 CLI, GUI, ROS 모듈, OROCOS 모듈, YARP 모듈을 작성하거나 Matlab에 연결하거나 센서와 상호 작용하는 데 사용하려는 모든 것을 자유롭게 작성할 수 있습니다.
마지막 참고 사항 : 여기서 말한 내용은 일반적으로 ROS뿐만 아니라 모든 로봇 플랫폼에 적용됩니다.
"ROS"는 상대적인 용어이며, APM은 쿼드로 콥터 제어를 위해 특별히 설계된 완전한 사용자 지정 코드를 실행합니다. 반면에 사용자 지정 ROS가 충돌하지 않도록하는 것이 좋습니다. 반면 Navio +는 Linux 커널에서 실행되고 자동 조종 장치 이외의 코드를 실행합니다. 여전히 충돌하지 않도록 관리합니다. 대부분의 ROS는 OS를 처음부터 작성하는 대신 기존 OS 위에있는 일련의 기능입니다. 무엇이든, 그것은 달려 있습니다.
면책 조항 :이 답변은 Shahbaz의 게시물에 대한 반응이므로 pro-ROS 편견이 있습니다.
ROS가 필수라고 생각하지는 않지만 훌륭한 출발점이며 투자 할 가치가 있습니다. Willow Garage에서 시작했지만이 회사는 사라졌고 ROS는 여전히 살아 있고 사용 및 개발되었습니다. 대부분의 ROS는 완전히 오픈 소스이며 상업적으로도 사용할 수 있으므로 회사가 더 이상 관심이 없다면 ROS가 사라질 방법은 없습니다. 물론 코드 품질은 핵심 모듈과 일부 박사 과정 학생이 논문으로 발표 한 최첨단 알고리즘의 구현에 따라 다릅니다.
ROS는 산업 환경에서 점점 더 많은 속도를 얻고 있습니다 (로봇을 사용하지 않는 로봇 공학 스타트 업의 상당 부분이 전세계에 있다면 놀랍습니다). ros-industrial 컨소시엄이 일부 알고리즘을 추가로 유지 보수하고 개발할 예정이며 회원을 살펴보면 ROS가 업계의 표준이 될 것입니다.
http://rosindustrial.org/ric/current-members/
ROS를 사용하는 분산 방식은 특히 팀 내에서 새로운 패키지를 작성하고 유지 관리하는 데 도움이됩니다. 메시지 및 동작 정의는 하드웨어 및 알고리즘을 빠르게 교환 할 수 있도록 인터페이스를 정의하는 데 많은 도움이됩니다. 또한 새로운 노드가 충돌하는 경우 (모든 RAM을 사용하지 않는 한) 다른 노드를 노드로 가져 오기 때문에 새로운 팀 구성원을 통합하는 데 도움이되므로 부분적으로 작동하는 노드를 실행중인 시스템에 통합하는 것이 안전합니다. 효과가 제한됩니다. 통신은 로컬 컴퓨터에서 안정적이고 빠른 TCP를 사용하므로 메시지 전달이 매우 빠릅니다 (제어 루프의 경우 수백 Hz가 가능함).
비 실시간
ROS는 현재 실시간이 아닙니다. 대부분의 알고리즘은 실시간이 필요하지 않습니다. 감지 또는 계획에는 대부분의 경우 실시간 제약이 없습니다 (고속 차량을자가 운전하는 사람은 몇 명입니까?). 최종 제어 루프가 실시간으로 실행되면 충분하며, 대부분의 경우 모터에서 직접 수행 할 수 있습니다 (예 : CAN을 통해 최종 위치가 전송 됨). 그러나 실시간은 ROS2 ( https://github.com/ros2/ros2/wiki/Real-Time-Programming ) 의 핵심 목표 중 하나 이므로 향후 전체 시스템에 필요한 경우라도 ROS는 .
임베디드를 실제로 실행하려면 arduino에 연결되어 있으므로 arduino에 ROS 메시지를 직접 작성하여 직렬 연결을 통해 보낼 수 있습니다.
Windows에서 ROS를 실행하는 것은 현재 다소 고통 스럽지만 Windows가 Linux에 가까워지면서 (bash 같은 것을 시작하기도 함) 가능할 때까지는 시간 문제 일뿐입니다. (그러나 어쨌든 누가 창으로 로봇을 실행하고 싶습니까?)
하드웨어 인터페이스 및 알고리즘 :
이것이 실제로 ROS의 장점이라고 생각합니다. 많은 상용 로봇에 이미 ROS 인터페이스가 제공되거나 누군가 인터페이스를 구현하는 데 시간을 투자했습니다. 대부분의 상용 팔은 MoveIt에서 사용할 수 있습니다. 따라서 특정 팔로 응용 프로그램을 실행하는 많은 작업을 다른 하드웨어에서 재사용 할 수 있습니다.
커뮤니티:
ROS의 또 다른 장점. 새로운 알고리즘은 ROS- 인터페이스를 매우 빠르게 가져 오며 많은 사람들이 당신과 같은 문제를 겪어 도움을 줄 누군가를 찾을 수 있습니다.
http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf