텍스트 대 그래픽 프로그래밍 언어

StackOverflow https://stackoverflow.com/questions/13678

문제

저는 고등학교 로봇 공학 팀의 일원입니다. 로봇을 프로그래밍하는 데 어떤 언어를 사용해야 하는지에 대한 논쟁이 있습니다.우리는 C(또는 C++)와 LabVIEW 중에서 선택하고 있습니다.각 언어마다 장단점이 있습니다.

C(++):

  • 광대하게 사용 된
  • 미래를 위한 좋은 준비(대부분의 프로그래밍 직책에는 텍스트 기반 프로그래머가 필요합니다.)
  • 작년부터 C 코드베이스를 확장할 수 있습니다.
  • 로봇이 하는 일을 더 잘 이해할 수 있습니다.

LabVIEW

  • 프로그램 흐름을 시각화하기가 더 쉽습니다(코드 줄 대신 블록 및 와이어).
  • 가르치기가 더 쉽습니다 (아마도 ...)
  • "프로그래밍의 미래는 그래픽입니다." (그렇게 생각하세요?)
  • 일부 신규 회원이 가질 수 있는 Robolab 배경에 더 가깝습니다.
  • 무슨 일이 일어나고 있는지 자세히 알 필요는 없습니다.모듈에 빨간 공을 찾으라고 지시하기만 하면 됩니다. 방법을 알 필요는 없습니다.

이것은 우리에게 있어서 매우 어려운 결정이고, 우리는 한동안 논쟁을 벌였습니다.각 언어별 전문가와 여러분의 경험을 바탕으로, 더 나은 선택이 무엇이라고 생각하시나요? 우리가 반드시 순수한 효율성을 추구하는 것은 아니라는 점을 명심하세요.우리는 또한 프로그래머들이 프로그래밍의 미래를 준비할 수 있기를 바랍니다.

또한:

  • LabVEIW와 같은 그래픽 언어가 프로그래밍의 미래라고 생각하시나요?
  • 그래픽 언어가 텍스트 언어보다 배우기 더 쉽나요? 나는 그들이 배우는 것이 똑같이 도전적이어야 한다고 생각합니다.
  • 우리는 부분적으로 사람들의 학습을 돕는 데 뿌리를 두고 있기 때문에, 미리 작성된 모듈에 얼마나 의존해야 하며, 스스로 작성하려고 얼마나 노력해야 합니까? ("좋은 프로그래머는 좋은 코드를 작성하고, 훌륭한 프로그래머는 훌륭한 코드를 복사합니다." 하지만 먼저 좋은 프로그래머가 될 가치가 있지 않나요?)

조언 해주셔서 감사합니다!

편집하다:나는 이 질문을 더욱 강조하고 싶습니다.팀 주장은 학습과 교육이 쉽다는 점에서 LabVIEW가 더 좋다고 생각합니다. 그게 사실인가요? 내 생각에는 C도 마찬가지로 쉽게 가르칠 수 있고 초급 수준의 작업도 여전히 C와 함께 할 수 있을 것 같습니다.나는 정말로 당신의 의견을 듣고 싶습니다. while 입력이{} "while 상자"를 생성하는 것보다 더 어려워야 하는 이유가 있나요? 프로그램이 한 줄씩 흐르고 ifs와 루프에 의해서만 수정되는 것이 직관적이지 않습니까? 프로그램이 와이어를 통해 흐르고 ifs와 루프에 의해서만 수정되는 것이 직관적이지 않습니까!?

다시 한 번 감사드립니다!

편집하다:나는 이것이 "언어 토론"이라는 주제에 속한다는 것을 깨달았습니다. 특정 목표를 가진 특정 프로그래밍 지점에 가장 적합한 것이기 때문에 괜찮기를 바랍니다.그렇지 않다면...죄송합니다...

도움이 되었습니까?

해결책

제가 도착하기 전에 우리 그룹(프로그래밍 배경이 거의 없는 박사학위 과학자)은 거의 1년 동안 계속해서 LabVIEW 어플리케이션을 구현하려고 노력해 왔습니다.코드가 정돈되지 않았고 너무 복잡했으며(프런트엔드와 백엔드) 가장 중요한 것은 작동하지 않았다는 것입니다.저는 열정적인 프로그래머이지만 LabVIEW를 사용해 본 적이 없습니다.제가 알고 있는 텍스트 프로그래밍 패러다임을 LabVIEW 개념으로 변환하는 데 도움을 줄 수 있는 LabVIEW 전문가의 도움으로 일주일 만에 앱을 코딩하는 것이 가능했습니다.여기서 요점은 기본 코딩 개념은 여전히 ​​배워야 하며, LabVIEW와 같은 언어라도 이를 표현하는 방법이 다를 뿐입니다..

LabVIEW는 원래 설계된 목적에 맞게 사용하기에 좋습니다.즉.DAQ 카드에서 데이터를 가져와 중간에 약간의 조작을 통해 화면에 표시합니다.그러나 프로그래밍은 알고리즘 더 쉬울 수도 없고 더 어렵다고 제안하고 싶습니다.예를 들어, 대부분의 절차적 언어에서 실행 순서는 일반적으로 의사 수학적 표기법을 사용하여 한 줄씩 따릅니다(예: y = x*x + x + 1) 반면에 LabVIEW는 반드시 서로 뒤따르지 않는 일련의 VI를 사용하여 이를 구현합니다(예:캔버스에 왼쪽에서 오른쪽으로).

게다가 직업으로서의 프로그래밍은 코딩의 기술을 아는 것 이상입니다.효과적인 도움 요청/답변 검색, 읽기 가능한 코드 작성, 레거시 코드 작업 등은 모두 LabVIEW와 같은 그래픽 언어에서는 훨씬 어려운 핵심 기술입니다.

저는 그래픽 프로그래밍의 일부 측면이 주류가 될 수 있다고 믿습니다. Sub-VI의 사용은 프로그래밍의 '블랙박스' 원칙을 완벽하게 구현하고 다음과 같은 다른 언어 추상화에도 사용됩니다. 야후 파이프 그리고 Apple Automator - 그리고 아마도 미래의 그래픽 언어가 우리가 프로그래밍하는 방식에 혁명을 일으킬 것입니다. 그러나 LabVIEW 자체는 언어 설계에 있어 엄청난 패러다임 변화는 아닙니다. while, for, if 흐름 제어, 타입 캐스팅, 이벤트 중심 프로그래밍, 심지어 객체까지.미래가 실제로 LabVIEW로 작성된다면 C++ 프로그래머는 이를 넘어가는 데 큰 어려움을 겪지 않을 것입니다.

후기로서 학생들이 어느 시점에서는 임베디드 시스템과 FPGA를 다루어야 하기 때문에 C/C++가 로봇 공학에 더 적합하다고 말하고 싶습니다.이런 종류의 작업에는 낮은 수준의 프로그래밍 지식(비트, 레지스터 등)이 매우 중요합니다.

@거지 실제로 LabVIEW는 업계, 특히 제어 시스템에 많이 사용됩니다.NASA가 이를 온보드 위성 시스템에 사용할 가능성은 거의 없지만 우주 시스템용 소프트웨어 개발은 완전히 다른 공 게임...

다른 팁

제가 현재 일하고 있는 연구그룹에서도 비슷한 상황을 겪은 적이 있습니다.생물물리학 그룹이고 우리는 계측기를 제어하기 위해 모든 곳에서 LabVIEW를 사용하고 있습니다.정말 훌륭하게 작동합니다.계측기의 모든 측면을 제어하고 상태를 확인하며 데이터를 저장하기 위해 UI를 쉽게 조립할 수 있습니다.

이제 저는 5페이지 분량의 장황한 글을 쓰는 것을 그만둬야 합니다. 왜냐하면 저에게 LabVIEW는 악몽이었기 때문입니다.대신 몇 가지 장점과 단점을 요약해 보겠습니다.

부인 성명 저는 LabVIEW 전문가가 아닙니다. 편견이 있거나, 시대에 뒤떨어지거나, 완전히 잘못된 내용을 말할 수도 있습니다. :)

LabVIEW 전문가

  • 그래 배우기 쉽다.우리 그룹의 많은 박사 학위는 몇 주 또는 그보다 짧은 시간 내에 해킹할 수 있는 충분한 기술을 습득한 것 같습니다.
  • 도서관.이것이 중요한 포인트입니다.자신의 상황에 맞게 이를 주의 깊게 조사해야 합니다(무엇이 필요한지, 이를 위한 좋은 LabVIEW 라이브러리가 있는지, 아니면 다른 언어로 된 대안이 있는지는 모르겠습니다).내 경우, 예를 들어 Python에서 훌륭하고 빠른 차트 작성 라이브러리를 찾는 것이 주요 문제였으며 이로 인해 일부 프로그램을 Python으로 다시 작성할 수 없었습니다.
  • 학교에 이미 설치되어 실행 중일 수도 있습니다.

LabVIEW 단점

  • 아마도 ~도 배우기 쉽다.어쨌든 아무도 모범 사례를 배우려고 애쓰지 않는 것 같기 때문에 프로그램은 금세 완전하고 돌이킬 수 없는 엉망이 됩니다.물론, 조심하지 않으면 텍스트 기반 언어에서도 이런 일이 발생할 수 있지만, IMO에서는 LabVIEW에서 작업을 올바르게 수행하는 것이 훨씬 더 어렵습니다.
  • 있는 경향이 있습니다 LabVIEW에서 Sub-VI를 찾을 때 발생하는 주요 문제 (심지어 버전 8.2까지인 것 같습니다).LabVIEW에는 라이브러리와 Sub-VI의 위치를 ​​아는 고유한 방법이 있으므로 소프트웨어를 완전히 중단시키는 것이 매우 쉽습니다.주변에 이 문제를 처리하는 방법을 아는 사람이 없으면 대규모 프로젝트가 어려워집니다.
  • LabVIEW를 버전 제어와 함께 사용하는 것은 쉽지 않습니다..물론 가능합니다. 하지만 어떤 경우에도 내장된 VC를 사용하지 않겠습니다.확인해 보세요 LVDiff LabVIEW diff 도구를 사용하고 있지만 병합에 대해서는 생각조차 하지 마십시오.

(마지막 두 가지 사항은 한 프로젝트에서 팀으로 작업하는 것을 어렵게 만듭니다.귀하의 경우에는 아마도 중요할 것입니다)

  • 이것은 개인적인 것이지만 시각적으로 프로그래밍하면 많은 알고리즘이 작동하지 않는다는 것을 알았습니다. 엉망이야.
    • 한 가지 예는 엄격하게 순차적인 것입니다.꽤 빨리 번거로워집니다.
    • 코드 개요를 파악하는 것은 어렵습니다.
    • 작은 작업을 위해 Sub-VI를 사용하는 경우(작은 작업을 수행하고 한 화면에 맞는 함수를 만드는 것이 좋은 습관인 것처럼) 이름만 지정할 수는 없지만 각각에 대해 아이콘을 그려야 합니다. 그들의.그것은 단 몇 분 만에 매우 짜증나고 번거로워지므로 유혹에 빠지게 됩니다. ~ 아니다 Sub-VI에 물건을 넣습니다.너무 번거롭습니다.그런데:정말 좋은 아이콘을 만드는 데는 전문적인 시간이 걸릴 수 있습니다.작성하는 모든 Sub-VI에 대해 고유하고 즉시 이해 가능하며 인식할 수 있는 아이콘을 만들어 보십시오. :)
  • 일주일 안에 손목터널이 생길 거예요.보장됩니다.
  • @브렌든:들어라, 들어라!

끝 맺는 말

"나만의 모듈을 작성해야 할까요?"라는 질문에 대해서는:잘 모르겠습니다.시간 제약에 따라 다릅니다.꼭 필요하지 않다면 바퀴를 재발명하는 데 시간을 낭비하지 마십시오.낮은 수준의 코드를 작성하는 데 며칠을 소비하다가 시간이 부족하다는 사실을 깨닫는 것은 너무 쉽습니다.LabVIEW를 선택하셨다면 선택하십시오.

LabVIEW와 C++를 결합하는 쉬운 방법이 있다면 이에 대해 듣고 싶습니다.그것은 당신에게 두 세계의 장점을 모두 제공할 수 있지만 그럴지는 의심스럽습니다.

그러나 귀하와 귀하의 팀은 모범 사례를 배우는 데 시간을 투자해야 합니다.서로의 코드를 살펴봅니다.서로에게서 배웁니다.사용 가능하고 이해하기 쉬운 코드 작성.그리고 재미있게 지내세요!

그리고 제가 초조하고 어쩌면 다소 현학적으로 들리는 것을 용서해 주십시오.LabVIEW는 단지 진짜 나에겐 악몽 :)

LabVIEW를 선택할지 말지는 일반적으로 사용되는 언어로 프로그래밍하는 방법을 시장성 있는 기술로 배우고 싶은지, 아니면 그냥 작업을 수행하고 싶은지에 달려 있다고 생각합니다.LabVIEW를 사용하면 작업을 매우 빠르고 생산적으로 완료할 수 있습니다.다른 사람들이 관찰했듯이, 자신이 하고 있는 일을 이해하지 않아도 되는 마술처럼 자유롭지는 않으며, 그렇지 않으면 불경스러운 혼란을 야기할 가능성이 높습니다. 일화적으로는 LabVIEW의 잘못된 코딩 스타일의 최악의 예는 다음과 같습니다. 일반적으로 텍스트 언어 사용 경험이 있고 '이미 프로그래밍 방법을 알고 있기 때문에 LabVIEW 작동 방식에 적응하기를 거부하는 사람들이 저지르는 일입니다. 젠장!'

물론 이는 LabVIEW 프로그래밍이 시장성 있는 기술이 아니라는 의미는 아닙니다.단지 C++만큼 대중 시장에 출시되지는 않았을 뿐입니다.

LabVIEW를 사용하면 병렬로 진행되는 다양한 작업을 매우 쉽게 관리할 수 있으며, 이는 로봇 제어 상황에서도 가능합니다.순차적이어야 하는 코드의 경쟁 조건도 문제가 되어서는 안 됩니다(예:만약 그렇다면, 당신은 잘못하고 있는 것입니다):필요한 경우 올바른 순서로 작업이 수행되도록 하는 간단한 기술이 있습니다. 오류 와이어나 기타 데이터를 사용하여 SubVI를 연결하고, 알림자 또는 큐를 사용하고, 상태 머신 구조를 구축하고, 필요한 경우 LabVIEW의 시퀀스 구조를 사용하는 등의 방법이 있습니다.다시 한번 말씀드리지만 이는 LabVIEW에서 사용할 수 있는 도구와 그 작동 방식을 이해하는 데 시간을 투자한 사례입니다.저는 subVI 아이콘을 만들어야 한다는 불만이 그다지 적절하다고 생각하지 않습니다.배경색을 사용하여 몇 단어의 텍스트가 포함된 텍스트를 매우 빠르게 만들 수 있으며 이는 대부분의 목적에 적합합니다.

'그래픽 언어가 미래의 길인가'는 잘못된 이분법에 기초한 붉은 청어입니다.어떤 것들은 그래픽 언어(예: 병렬 코드)에 적합합니다.다른 것들은 텍스트 언어에 훨씬 더 적합합니다.저는 LabVIEW와 그래픽 프로그래밍이 사라지거나 세상을 장악할 것이라고 기대하지 않습니다.

덧붙여서, NASA라면 매우 놀랄 것입니다 하지 않았다 우주 프로그램에서 LabVIEW를 사용하십시오.최근 Info-LabVIEW 메일링 리스트에 어떤 사람이 LabVIEW를 사용하여 Boeing 787의 전기 모터로 작동되는 비행 표면의 폐쇄 루프 제어를 개발하고 테스트한 방법을 설명했으며, LabVIEW가 비행기 개발에 광범위하게 사용되었다는 인상을 주었습니다.실시간 제어에도 사용됩니다. 대형 하드론 충돌기!

현재 National Instruments의 자체 사이트와 포럼 외에 LabVIEW에 대한 추가 정보와 도움을 얻을 수 있는 가장 활발한 곳은 다음과 같습니다. 용암.

이것은 귀하의 질문에 직접적으로 대답하지는 않지만 해석된 언어로 혼합하는 세 번째 옵션을 고려할 수 있습니다. 루아, 예를 들어, 이미 사용된 로봇공학 분야에서.빠르고 가벼우며 대부분의 마이크로 컨트롤러에는 FPU가 없기 때문에 부동 소수점 대신 고정 소수점 숫자로 실행되도록 구성할 수 있습니다. 앞으로 유사한 사용법을 가진 또 다른 대안입니다.

C로 얇은 인터페이스 레이어를 작성하고 학생들이 해석된 스크립트를 사용하도록 하는 것은 꽤 쉬울 것입니다.칩을 다시 컴파일하거나 플래시하지 않고도 코드를 동적으로 로드할 수 있도록 설정할 수도 있습니다.이렇게 하면 반복 주기가 줄어들고 학생들이 결과를 더 빨리 확인하여 더 잘 배울 수 있습니다.

나는 편견이 있어요 ~에 맞서 LabVIEW와 같은 시각적 도구를 사용합니다.나는 항상 내가 원하는 대로 작동하지 않거나 작동하지 않는 것을 치는 것 같습니다.그래서 저는 텍스트 코드를 통해 얻을 수 있는 절대적인 제어를 선호합니다.

(라이브러리 외에) LabVIEW의 다른 장점은 다음과 같습니다. 동시성.그것은 데이터 흐름 언어, 이는 런타임이 동시성을 처리할 수 있음을 의미합니다.따라서 고도로 동시 작업을 수행하고 전통적인 동기화를 수행하고 싶지 않은 경우, LabVIEW가 도움이 될 수 있습니다.

미래는 현재의 그래픽 언어에 속하지 않습니다.이는 그래픽 접근 방식만큼 간단하면서도 프로그래머 자체 도구로 구문 분석할 수 있는 데이터 흐름(또는 다른 동시성 친화적 프로그래밍 유형)의 표현을 생각해 낼 수 있는 사람의 몫입니다.

National Instruments가 주최한 주제에 대한 연구 결과가 발표되었습니다.

그래픽 vs. 그래픽에 대한 연구DSP 교육을 위한 텍스트 프로그래밍

구체적으로 LabVIEW와 MATLAB(C와 반대)을 살펴봅니다.

나는 그래픽 언어가 텍스트 언어에 비해 표현력이 항상 제한적이라고 생각합니다.시각적 기호(예: REBUS 또는 수화)를 사용하여 의사소통하는 것과 단어를 사용하여 의사소통하는 것을 비교해 보세요.

간단한 작업의 경우 일반적으로 그래픽 언어를 사용하는 것이 더 쉽지만 보다 복잡한 논리의 경우 그래픽 언어가 방해가 됩니다.

하지만 이 주장에 암시된 또 다른 논쟁은 선언적 프로그래밍과 선언적 프로그래밍입니다.피할 수 없는.선언적 방식은 일반적으로 작업 수행 방법을 세밀하게 제어할 필요가 없는 경우에 더 좋습니다.너 ~할 수 있다 C++를 선언적 방식으로 사용하려면 사전에 더 많은 작업이 필요한 반면, LABView는 선언적 언어로 설계되었습니다.

한 장의 그림은 천 단어의 가치가 있습니다. 그러나 그림이 천 단어를 나타내지만 필요하지 않고 변경할 수 없다면 그 그림은 가치가 없습니다.반면에 단어를 사용하여 수천 장의 그림을 만들고 모든 세부 사항을 지정하고 보는 사람의 초점을 명시적으로 유도할 수도 있습니다.

LabVIEW를 사용하면 빠르게 시작할 수 있으며 (다른 사람들이 이미 말했듯이) 다양한 테스트, 측정 및 제어 관련 작업을 수행하기 위한 대규모 코드 라이브러리가 있습니다.

그러나 LabVIEW의 가장 큰 단점은 프로그래머가 스스로 작성하는 모든 도구를 잃게 된다는 것입니다.

귀하의 코드는 VI로 저장됩니다.이는 불투명한 바이너리 파일입니다.이는 귀하의 코드가 실제로는 귀하의 것이 아니라 LabVIEW의 것임을 의미합니다.자신만의 파서를 작성할 수 없고, 코드 생성기를 작성할 수 없으며, 매크로나 스크립트를 통해 자동화된 변경을 수행할 수 없습니다.

이것 짜증나 보편적으로 적용되는 사소한 조정이 필요한 5000 VI 앱이 있는 경우.당신의 오직 옵션은 모든 VI를 수동으로 살펴보는 것입니다. 한 VI의 변경 사항을 어딘가에서 놓친 경우 하늘이 도와줄 것입니다.

그리고 그렇습니다. 바이너리이기 때문에 텍스트 언어처럼 diff/merge/patch를 수행할 수 없습니다.이는 실제로 두 개 이상의 코드 버전으로 작업하는 것을 유지 관리에 있어서 끔찍한 악몽으로 만듭니다.

간단한 작업을 수행하거나, 프로토타입을 제작해야 하거나, 코드를 유지 관리할 계획이 없다면 LabVIEW를 사용하십시오.

실제적이고 유지 관리 가능한 프로그래밍을 수행하려면 텍스트 언어를 사용하십시오.시작하는 속도가 느려질 수도 있지만 장기적으로는 더 빨라질 것입니다.

(아, 그리고 DAQ 라이브러리가 필요한 경우 NI에서 C++ 및 .Net 버전도 제공합니다.)

내 첫 번째 게시물은 여기에 있습니다 :) 부드럽게 ...

저는 자동차 산업에 종사하다가 지금은 방위 산업에 종사하고 있습니다.경험을 통해 C/C++와 LabVIEW는 서로 다른 목적을 염두에 두고 있는 정말 다른 짐승이라는 것을 알 수 있습니다.C/C++는 컴팩트하고 컴파일러/도구를 쉽게 구할 수 있었기 때문에 마이크로 컨트롤러에 대한 임베디드 작업에 항상 사용되었습니다.반면에 LabVIEW는 테스트 시스템을 구동하는 데 사용되었습니다(시퀀서로서의 테스트 스탠드와 함께).우리가 사용한 대부분의 테스트 장비는 NI 제품이었기 때문에 LabVIEW는 우리가 원하는 지원과 함께 작업에 필요한 도구와 드라이버를 갖춘 환경을 제공했습니다.

학습 용이성 측면에서 볼 때 C/C++에 대한 많은 리소스가 있으며 무료로 사용할 수 있는 거의 모든 것에 대한 디자인 고려 사항 및 예제 알고리즘을 설명하는 많은 웹 사이트가 있습니다.LabVIEW의 경우 사용자 커뮤니티가 C/C++만큼 다양하지 않을 수 있으며, 예제 코드를 검사하고 비교하는 데 약간의 노력이 더 필요합니다(올바른 버전의 LabVIEW가 있어야 함 등).LabVIEW는 선택하고 배우기가 매우 쉽다는 것을 알았지만, 여기에서 일부 사람들이 언급했듯이 병렬 처리 및 이를 인식하기 전에 약간의 경험이 필요한 다양한 다른 것들과 관련하여 성가신 문제가 있습니다.

그럼 결국 결론은?나는 두 가지 언어가 서로 다른 두 가지 프로그래밍 스타일을 대표하기 때문에 학습할 가치가 있다고 말하고 싶습니다. 두 가지 언어를 모두 알고 능숙하게 아는 것은 확실히 가치가 있습니다.

맙소사, 대답은 너무 간단해요.사용 LabView.

나는 10년 동안 임베디드 시스템을 프로그래밍해 왔으며 최소한 몇 달 간의 인프라(매우 세심한 인프라!) 없이는 처음부터 생산성을 발휘할 수 없을 것이라고 말할 수 있습니다. LabView.

군용으로 판매 및 사용할 로봇을 설계하는 경우 C부터 시작하십시오. 좋은 선택입니다.

그렇지 않으면 가장 짧은 시간에 가장 다양한 것을 시험해 볼 수 있는 시스템을 이용하세요.그건 LabView.

내 생각엔 그래픽 언어가 미래의 언어일지도 모른다고 생각하는데....모든 임시 MS Access 개발자를 위한 것입니다.순수한 텍스트 코더를 위한 자리는 항상 있을 것입니다.

개인적으로 로봇을 다 만들었다면 로봇을 만드는 진짜 재미가 무엇인지 묻고 싶습니다.거기에 '빨간 공 찾기' 모듈을 놓고 그것이 진행되는 것을 지켜본다면?당신은 당신의 성취에 대해 어떤 자부심을 가질 것입니까?개인적으로는 별로 없었을 겁니다.또한 코딩이나 로봇 공학에서 중요한 소프트웨어/하드웨어 인터페이스의 (매우 중요한) 측면에 대해 무엇을 가르쳐 줄까요?

나는 이 분야의 전문가라고 주장하지 않지만, 스스로에게 한 가지 질문을 던져 보십시오.NASA가 화성 탐사선을 코딩하기 위해 LabVIEW를 사용했다고 생각하십니까?로봇공학 분야에서 정말 저명한 사람이 LabView를 사용하고 있다고 생각하시나요?

실제로, LabVIEW와 같은 쿠키 커터를 사용하여 이것을 구축하는 유일한 방법은 뒷마당 로봇 제작자가 되는 것입니다.업계 경험과 유사한 것을 제공할 수 있는 것을 원한다면 자신만의 'LabVIEW' 유형 시스템을 구축하십시오.자신만의 공 찾기 모듈이나 '라인 따라가기' 모듈을 구축하세요.훨씬 더 어려울 것이지만 훨씬 더 멋질 것입니다.:디

저는 LabVIEW를 좋아합니다.특히 다른 사람이 비슷한 것을 사용한 적이 있다면 강력히 추천합니다.일반 프로그래머가 익숙해지는 데 시간이 좀 걸리지만 이미 프로그래밍 방법을 알고 있다면 결과가 훨씬 더 좋습니다.

C/C++는 자신의 메모리를 관리하는 것과 같습니다.당신은 기억의 연결 속에서 헤엄치며 그것에 대해 걱정하게 될 것입니다.LabVIEW를 사용하여 LabVIEW와 함께 제공되는 문서를 읽고 경쟁 조건을 주의하십시오.

언어를 배우는 것은 쉽습니다.프로그래밍 방법을 배우는 것은 아닙니다.이는 그래픽 언어라 할지라도 변하지 않습니다.그래픽 언어의 장점은 앉아서 많은 텍스트를 해독하는 것보다 코드가 수행할 작업을 시각적으로 보는 것이 더 쉽다는 것입니다.

중요한 것은 언어가 아니라 프로그래밍 개념입니다.프로그래밍을 위해 어떤 언어를 배우는지는 중요하지 않습니다. 조금만 노력하면 어떤 언어로든 잘 프로그래밍할 수 있기 때문입니다.언어는 왔다가 사라집니다.

부인 성명:저는 LabVIEW를 본 적이 없지만 WebMethods Flow와 Modeller, 대학의 동적 시뮬레이션 언어, 그리고 MIT의 Scratch를 포함한 몇 가지 다른 그래픽 언어를 사용해 왔습니다.

내 경험에 따르면 그래픽 언어는 프로그래밍의 '배관' 부분을 훌륭하게 수행할 수 있지만, 내가 적극적으로 사용한 언어는 알고리즘을 방해합니다.알고리즘이 매우 간단하다면 괜찮을 수도 있습니다.

반면에 C++도 귀하의 상황에 적합하지 않다고 생각합니다.유용한 작업보다 포인터 및 메모리 관리 문제를 추적하는 데 더 많은 시간을 할애하게 됩니다.

스크립트 언어(Python, Ruby, Perl 등)를 사용하여 로봇을 제어할 수 있다면 그것이 훨씬 더 나은 선택이 될 것이라고 생각합니다.

그런 다음 하이브리드 옵션이 있습니다.

로봇을 위한 스크립팅 옵션이 없고 팀에 C++ 괴짜가 있는 경우 해당 괴짜가 바인딩을 작성하여 C++ 라이브러리를 스크립팅 언어에 매핑하도록 하는 것을 고려하십시오.이를 통해 다른 전문 분야를 가진 사람들도 로봇을 더 쉽게 프로그래밍할 수 있습니다.바인딩은 지역 사회에 좋은 선물이 될 것입니다.

LabVIEW가 허용하는 경우 그래픽 언어를 사용하여 텍스트 언어로 작성된 모듈을 연결하십시오.

당신은 고등학교에 재학 중입니다.이 프로그램에 얼마나 많은 시간을 할애해야 합니까?당신의 그룹에는 몇 명이 있습니까?C++나 LabView를 이미 알고 있나요?

귀하의 질문에 따르면 귀하는 C++을 알고 있지만 대부분의 그룹은 그렇지 않습니다.나는 또한 그룹 리더가 팀의 일부 구성원이 텍스트 기반 프로그래밍 언어에 겁을 먹을 수 있다는 것을 알아차릴 만큼 통찰력이 있다고 의심합니다.이것은 허용됩니다. 당신은 고등학생이고 이 사람들은 규범.일반 고등학생이라면 C++보다 LabView를 더 직관적으로 이해할 수 있을 것 같습니다.나는 일반 인구와 마찬가지로 대부분의 고등학생이 명령줄을 두려워한다고 생각합니다.당신에게는 차이가 훨씬 적지만 그들에게는 밤과 낮이 있습니다.

LabView에도 C++와 동일한 개념이 적용될 수 있다는 말씀이 맞습니다.각각에는 강점과 약점이 있습니다.중요한 것은 작업에 적합한 도구를 선택하는 것입니다.LabView는 이전 이런 종류의 응용 프로그램을 위해 설계되었습니다..C++는 훨씬 더 일반적이며 다른 많은 종류의 문제에 적용될 수 있습니다.

LabView를 추천해드리고 싶습니다.올바른 하드웨어가 제공되면 거의 즉시 사용할 수 있습니다.팀이 더 많은 시간을 보낼 수 있습니다 로봇이 원하는 일을 하게 하기, 이것이 바로 이 활동의 ​​초점이 되어야 하는 것입니다.

그래픽 언어는 프로그래밍의 미래가 아닙니다.이는 수년 동안 특정 유형의 문제를 해결하기 위해 만들어진 선택 사항 중 하나였습니다.프로그래밍의 미래는 기계 코드에서 벗어나 추상화 계층을 계층화하는 것입니다.앞으로 우리는 왜 "의미론"을 프로그래밍하는데 이 모든 시간을 계속해서 낭비하는지 궁금해할 것입니다.

미리 작성된 모듈에 얼마나 의존해야 하며, 스스로 작성하려고 얼마나 노력해야 합니까?바퀴를 재발명하는 데 시간을 낭비해서는 안 됩니다.Labview에 사용 가능한 장치 드라이버가 있으면 이를 사용하십시오.기능이 유사한 코드를 복사하고 필요에 맞게 조정하면 많은 것을 배울 수 있습니다. 다른 사람들이 유사한 문제를 어떻게 해결했는지 확인하고 문제에 적절하게 적용하기 전에 그들의 솔루션을 해석해야 합니다.맹목적으로 코드를 복사하면 코드가 작동할 가능성이 희박합니다.코드를 복사하더라도 잘해야 합니다.

행운을 빌어 요!

원하는 작업을 더 빠르고 쉽게 로봇으로 만들 수 있도록 LabVIEW를 사용하는 것이 좋습니다.LabVIEW는 이러한 생각을 바탕으로 설계되었습니다.OfCourse C(++)는 훌륭한 언어이지만 LabVIEW는 다른 어떤 것보다 더 나은 기능을 수행합니다.LabVIEW는 이에 대한 충분한 범위와 지원을 제공하므로 사람들은 정말 좋은 소프트웨어를 작성할 수 있습니다.

내 어플리케이션에 LabVIEW를 사용하면서 제가 발견한 한 가지 큰 단점은 다음과 같습니다.설계 복잡성을 구성합니다.물리학자로서 저는 Labview가 프로토타이핑, 기기 제어 및 수학적 분석에 적합하다고 생각합니다.LabVIEW보다 더 빠르고 더 나은 결과를 얻을 수 있는 언어는 없습니다.저는 1997년부터 LabView를 사용했습니다.2005년부터 디자인과 유지 관리가 더 쉽기 때문에 .NET 프레임워크로 완전히 전환했습니다.

LabVIEW에서는 간단한 'if' 구조를 그려야 하며 그래픽 디자인에서 많은 공간을 사용합니다.저는 우리 회사의 상용 애플리케이션 중 다수가 유지 관리가 어렵다는 사실을 방금 알게 되었습니다.응용 프로그램이 복잡해질수록 읽기가 더 어려워졌습니다.

나는 이제 텍스트 언어를 사용하고 모든 것을 유지하는 데 훨씬 더 능숙합니다.C++와 LabVIEW를 비교한다면 LabVIEW를 사용하겠지만 C#과 비교하면 이기지 못합니다.

항상 그렇듯이 상황에 따라 다릅니다.

저는 약 20년 전부터 LabVIEW를 사용하고 있으며 간단한 DAQ부터 매우 복잡한 시각화, 디바이스 제어부터 테스트 시퀀서까지 매우 다양한 작업을 수행했습니다.충분하지 않다면 분명히 바꿨을 것입니다.즉, 저는 펀치카드로 Fortran 코딩을 시작했고 Z80 기반 언어부터 시작하여 8비트 '머신'에서 수많은 프로그래밍 언어를 사용했습니다.언어는 Assembler에서 BASIC, Turbo-Pascal에서 C까지 다양했습니다.

LabVIEW는 데이터 수집 및 분석을 위한 광범위한 라이브러리로 인해 크게 개선되었습니다.그러나 다른 패러다임을 배워야 합니다.그리고 반드시 트랙볼이 필요합니다 ;-))

저는 LabView(또는 C/C++에 대해)에 대해서는 아무것도 모르지만..

LabVEIW와 같은 그래픽 언어가 프로그래밍의 미래라고 생각하시나요?

아니요...

그래픽 언어가 텍스트 언어보다 배우기 더 쉽나요?나는 그들이 배우는 것이 똑같이 도전적이어야 한다고 생각합니다.

배우기가 더 쉽나요?아니, 하지만 그들은 ~이다 설명하고 이해하기가 더 쉽습니다.

프로그래밍 언어를 설명하려면 변수가 무엇인지 설명해야 합니다(놀랍게도 어렵습니다).이는 LEGO Mindstroms 프로그래밍 인터페이스 또는 Quartz Composer와 같은 흐름 그래프/노드 코딩 도구에는 문제가 되지 않습니다.

예를 들어, 이것은 상당히 복잡한 LEGO Mindstroms 프로그램입니다. - 내용을 이해하는 것은 매우 쉽습니다 ...하지만 로봇이 INCREASEJITTER 5번 블록하고 10초 동안 앞으로 이동한 다음 INCREASEJITTER 루프를 다시 시도하시겠습니까?상황이 매우 빨리 지저분해지기 시작합니다..

Quartz Composer는 이에 대한 좋은 예이며, 그래픽 언어가 "미래"가 될 수 없다고 생각하는 이유는 무엇입니까?

이를 통해 정말 멋진 작업(3D 입자 효과, 웹캠 픽셀의 평균 밝기로 제어되는 카메라 사용)을 매우 쉽게 수행할 수 있습니다.하지만 XML 파일의 요소를 반복하거나 평균 픽셀 값을 파일에 저장하는 등의 쉬운 작업을 수행하는 것은 엄청나게 어렵습니다.

우리가 부분적으로 사람들의 학습을 돕는 데 뿌리를 두고 있는 것을 볼 때, 미리 작성된 모듈에 얼마나 의존해야 하며, 스스로 작성하려고 얼마나 노력해야 합니까?("좋은 프로그래머는 좋은 코드를 작성하고, 훌륭한 프로그래머는 훌륭한 코드를 복사합니다." 하지만 먼저 좋은 프로그래머가 될 가치가 있지 않나요?)

학습을 위해서는 그래픽 언어를 설명하고 이해하는 것이 훨씬 쉽습니다.

그렇긴 하지만, 저는 전문적인 텍스트 기반 언어 언어를 발전 과정으로 추천하고 싶습니다.예를 들어, 다음과 같은 그래픽의 경우 처리 또는 노드박스.그들은 매우 전문적이고 사용하기 쉬운(그러나 터무니없이 강력한) 프레임워크가 내장되어 있는 "일반적인" 언어(처리는 Java, NodeBox는 Python)입니다.

중요한 것은 이 언어가 매우 대화형 언어이므로 화면에 원을 표시하기 위해 수백 줄을 작성할 필요가 없다는 것입니다.그냥 입력하시면 됩니다 oval(100, 200, 10, 10) 실행 버튼을 누르면 나타납니다!이는 또한 시연하고 설명하기가 매우 쉽습니다.

로봇공학과 관련하여 LOGO와 같은 것도 좋은 소개가 될 것입니다. "FORWARD 1"을 입력하면 거북이가 한 상자 앞으로 이동합니다."LEFT 90"을 입력하면 90도 회전합니다.이것은 매우 간단하게 현실과 관련이 있습니다.각 명령이 수행하는 작업을 시각화한 다음 시험해 보고 실제로 그런 식으로 작동하는지 확인할 수 있습니다.

그들에게 반짝거리는 것을 보여주면 그들은 도중에 C에서 배울 유용한 것들을 배울 것입니다. 만약 그들이 관심이 있거나 "진짜" 언어가 필요한 지점까지 발전한다면 그들은 언어가 아닌 모든 지식을 갖게 될 것입니다. 구문 오류가 발생하고 벽돌 벽을 컴파일하는 중입니다.

프로그래밍의 미래를 위해 우리 팀을 준비시키려는 경우 C(++)가 더 나은 경로일 수 있습니다.시각적 빌딩 블록으로 구축된 일반 프로그래밍 언어의 약속은 결코 실현되지 않은 것 같았으며 실현될 것인지 궁금해지기 시작했습니다.특정 문제 영역에 대해서는 수행할 수 있지만 일단 많은 일반적인 문제를 해결하려고 하면 텍스트 기반 프로그래밍 언어를 이기기가 어려운 것 같습니다.

한때 나는 실행 가능한 UML에 대한 아이디어를 일종의 구매했지만 일단 개체 관계와 일부 프로세스 흐름을 지나치면 UML은 앱을 구축하는 데 매우 비참한 방법이 될 것 같습니다.모든 것을 GUI에 연결하려고 한다고 상상해 보십시오.나는 틀렸다는 것이 증명되더라도 상관하지 않지만 지금까지는 우리가 곧 포인트 앤 클릭 프로그래밍을 할 것 같지 않습니다.

저는 약 2년 전에 LabVIEW를 시작했고 지금은 항상 사용하고 있기 때문에 편견이 있을 수 있지만 데이터 수집 및 제어가 관련된 어플리케이션에 이상적이라고 생각합니다.

우리는 주로 지속적인 측정을 수행하고 가스 밸브와 ATE 인클로저를 제어하는 ​​테스트에 LabVIEW를 사용합니다.여기에는 GUI에서 실행되는 신호 분석 루틴과 프로세스 제어를 갖춘 디지털 및 아날로그 입력 및 출력이 모두 포함됩니다.각 부분을 SubVI로 나누어 마우스 클릭과 드래그만으로 테스트를 재구성할 수 있습니다.

C/C++와 정확히 동일하지는 않지만 Visual BASIC을 사용한 유사한 측정, 제어 및 분석 구현은 비교를 통해 복잡하고 유지 관리하기 어려워 보입니다.

저는 실제 코딩 언어보다 프로그래밍 과정이 더 중요하다고 생각하며, 그래픽 프로그래밍 언어에 대한 스타일 지침을 따라야 한다고 생각합니다.LabVIEW 블록 다이어그램은 데이터의 흐름을 보여줍니다(데이터 흐름 프로그래밍) 따라서 아무런 문제가 없었지만 잠재적인 경쟁 조건을 쉽게 확인할 수 있습니다.C 코드베이스가 있는 경우 이를 dll로 빌드하면 LabVIEW가 이를 직접 호출할 수 있습니다.

두 가지 선택 모두에는 확실히 장점이 있습니다.그러나 귀하의 도메인은 교육 경험이기 때문에 C/C++ 솔루션이 학생들에게 가장 큰 도움이 될 것이라고 생각합니다.그래픽 프로그래밍은 항상 선택 사항이지만 저수준 프로그래밍을 위한 텍스트 프로그래밍보다 사용하기 더 효율적이게 만드는 우아한 방식의 기능을 제공하지 않습니다.이것은 나쁜 것이 아닙니다. 추상화의 전체 요점은 문제 영역에 대한 새로운 이해와 관점을 허용하는 것입니다.하지만 많은 사람들이 그래픽 프로그래밍에 실망할 수 있다고 생각하는 이유는 특정 프로그램의 경우 C 프로그래밍에서 그래픽 프로그래밍으로 전환할 때의 점진적인 이득이 어셈블리에서 C로 전환하는 것과 거의 같지 않기 때문입니다.

그래픽 프로그래밍에 대한 지식은 미래의 프로그래머에게 확실히 도움이 될 것입니다.미래에는 그래픽 프로그래밍에 대한 지식만 필요한 기회가 있을 것이며 아마도 일부 학생들은 그래픽 프로그래밍에 대한 초기 경험을 통해 이익을 얻을 수 있을 것입니다.반면에, 텍스트 접근 방식을 통해 제공되는 기본 프로그래밍 개념의 탄탄한 기반은 도움이 될 것입니다. 모두 당신의 학생들 중 확실히 더 나은 대답이 될 것입니다.

팀 주장은 LabView가 학습 및 교육의 용이성에 더 좋다고 생각합니다.그게 사실인가요?

나는 그것이 어떤 단일 언어나 패러다임에도 해당될지 의심스럽습니다.LabView는 전자 공학 배경 지식을 가진 사람들에게 확실히 더 쉬울 수 있습니다.그 안에서 프로그램을 만드는 것은 "단순히" 전선을 그리는 것입니다.그렇다면 그러한 사람들도 이미 프로그래밍에 노출되어 있을 수도 있습니다.

그래픽과는 별개로 한 가지 중요한 차이점은 LV가 수요 기반(흐름) 프로그래밍이라는 것입니다.결과부터 시작하여 결과에 도달하기 위해 필요한 것이 무엇인지 알려줍니다.전통적인 프로그래밍은 필수적인 경향이 있습니다(반대).

일부 언어에서는 두 가지를 모두 제공할 수 있습니다.저는 최근 Lua용 멀티스레딩 라이브러리(Lanes)를 만들었고, 이는 필수적인 환경에서 요구 기반 프로그래밍에 사용될 수 있습니다.나는 주로 Lua에서 실행되는 성공적인 로봇이 있다는 것을 알고 있습니다(미친 이반 루아오식스에서).

Microsoft Robotics Studio를 살펴보셨나요?http://msdn.microsoft.com/en-us/robotics/default.aspx

시각적 프로그래밍(VPL)이 가능합니다.http://msdn.microsoft.com/en-us/library/bb483047.aspxC#과 같은 현대 언어도 마찬가지입니다.최소한 튜토리얼을 살펴보는 것이 좋습니다.

Labview(및 이와 관련하여 Matlab)에 대한 나의 불만은 x86 이외의 다른 것에 코드를 삽입할 계획이라면(그리고 Labview에는 ARM에 Labview VI를 배치하는 도구가 있음) 문제에 최대한 많은 힘을 쏟아야 한다는 것입니다. 비효율적이기 때문에 가능한 한.

Labview는 훌륭한 프로토타이핑 도구입니다.많은 라이브러리, 블록을 연결하기 쉬움, 고급 알고리즘을 수행하기가 약간 어려울 수도 있지만 원하는 블록이 있을 수 있습니다.기능을 빠르게 완료할 수 있습니다.그러나 해당 VI를 디바이스에 적용할 수 있다고 생각한다면 큰 오산입니다.예를 들어, Labview에서 가산기 블록을 만들면 두 개의 입력과 하나의 출력이 있습니다.이에 대한 메모리 사용량은 얼마입니까?세 가지 변수가 데이터 가치가 있나요?둘?C나 C++에서는 다음 중 하나를 쓸 수 있기 때문입니다. z=x+y 또는 x+=y 코드가 수행하는 작업과 메모리 상황이 무엇인지 정확히 알 수 있습니다.특히 (다른 사람들이 지적했듯이) Labview는 병렬성이 높기 때문에 메모리 사용량이 빠르게 급증할 수 있습니다.따라서 문제에서 생각했던 것보다 더 많은 RAM을 투입할 준비를 하십시오.그리고 더 많은 처리 능력.

간단히 말해서, Labview는 신속한 프로토타이핑에 적합하지만 다른 상황에서는 제어력을 너무 많이 잃게 됩니다.많은 양의 데이터 또는 제한된 메모리/처리 능력으로 작업하는 경우 텍스트 기반 프로그래밍 언어를 사용하여 진행되는 작업을 제어할 수 있습니다.

사람들은 항상 labview를 C++와 비교하며 "아 labview는 높은 수준이고 기능이 너무 많이 내장되어 있습니다. dfft를 수행하여 데이터를 수집하고 데이터를 표시하는 것은 labview에서 너무 쉽습니다. C++에서 시도해 보세요."라고 말합니다.

신화 1:C++에서는 수준이 너무 낮고 labview에는 이미 많은 기능이 구현되어 있기 때문에 작업을 수행하기가 어렵습니다.문제는 C++로 로봇 시스템을 개발하는 경우 opencv, pcl ..과 같은 라이브러리를 사용해야 한다는 것입니다.즉, ROS(로봇 운영 체제)와 같은 로봇 시스템을 구축하기 위해 설계된 소프트웨어 프레임워크를 사용하면 훨씬 더 똑똑해질 것입니다.따라서 전체 도구 세트를 사용해야 합니다.실제로 opencv 및 pcl과 같은 라이브러리와 함께 ROS + python/c++를 사용하면 더 높은 수준의 도구를 사용할 수 있습니다.나는 labview 로봇 공학을 사용해 왔지만 ICP와 같이 솔직히 일반적으로 사용되는 알고리즘은 없으며 현재 다른 라이브러리를 쉽게 사용할 수 있는 것과는 다릅니다.

신화2:그래픽 프로그래밍 언어를 이해하는 것이 더 쉬운가요?

상황에 따라 다릅니다.복잡한 알고리즘을 코딩할 때 그래픽 요소는 귀중한 화면 공간을 차지하며 방법을 이해하기 어려울 것입니다.labview 코드를 이해하려면 코드에서 O(n^2) 복잡성이 있는 영역을 위에서 아래로 읽어야 합니다.

병렬 시스템이 있다면 어떨까요?ROS는 콜백을 사용하여 구현된 구독자/게시자 메시지를 기반으로 하는 그래프 기반 아키텍처를 구현하며 여러 프로그램을 실행하고 통신하는 것이 매우 쉽습니다.개별 병렬 구성 요소를 분리하면 디버깅이 더 쉬워집니다.예를 들어 병렬 labview 코드를 단계별로 실행하는 것은 제어 흐름이 한 위치에서 다른 위치로 이동하기 때문에 악몽입니다.ROS에서는 labview처럼 명시적으로 아키텍처를 그리지는 않지만 ros run rqt_graph 명령을 실행하면 계속 볼 수 있습니다(연결된 모든 노드가 표시됨).

"프로그래밍의 미래는 그래픽입니다." (그렇게 생각하세요?)

나는 그렇지 않기를 바랍니다. 현재 labview 구현에서는 텍스트 기반 방법과 그래픽 방법을 사용한 코딩을 허용하지 않습니다.(수학 스크립트가 있지만 엄청나게 느립니다)

병렬성을 쉽게 숨길 수 없기 때문에 디버깅하기가 어렵습니다.

너무 많은 영역을 살펴보아야 하기 때문에 labview 코드를 읽기가 어렵습니다.

Labview는 데이터 aq 및 신호 처리에 적합하지만 실험적인 로봇 공학에는 적합하지 않습니다. 왜냐하면 SLAM(동시 위치 파악 및 매핑), 포인트 클라우드 등록, 포인트 클라우드 처리 등과 같은 대부분의 고급 구성 요소가 없기 때문입니다.이러한 구성요소를 추가하고 ROS처럼 쉽게 통합할 수 있더라도 labview는 독점적이고 비용이 많이 들기 때문에 결코 오픈 소스 커뮤니티를 따라갈 수 없습니다.

요약하자면, labview가 메카트로닉스의 미래라면 저는 투자 은행으로 진로를 바꾸고 있습니다...일을 즐길 수 없다면 돈을 좀 벌고 일찍 은퇴하는 편이 나을 것 같습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top