robotics - テキストプログラミング言語とグラフィカルプログラミング言語

Question

私は高校のロボット工学チームの一員ですが、ロボットのプログラミングにどの言語を使用するかについて議論があります。C (またはおそらく C++) と LabVIEW のどちらかを選択しています。言語ごとに長所があります。

C(++):

広く使われています
将来に向けた適切な準備 (ほとんどのプログラミング職では、テキストベースのプログラマーが必要です。)
昨年の C コードベースを拡張できます
ロボットが何をしているかをよりよく理解することができます。

LabVIEW

プログラムフローの視覚化が容易 (コード行ではなく、ブロックとワイヤ)
教えやすい（おそらく…）
「プログラミングの未来はグラフィカルです。」（そう思う？）
一部の新しいメンバーが持つ可能性のあるロボラボのバックグラウンドに近い。
何が起こっているのかを詳しく知る必要はありません。モジュールに赤いボールを見つけるように指示するだけです。方法を知る必要はありません。

これは私たちにとって非常に難しい決断であり、しばらく議論を重ねてきました。各言語の長所と、あなたの経験から、より良い選択肢は何だと思いますか? 必ずしも純粋な効率を求めているわけではないことに注意してください。また、プログラミングの将来に向けてプログラマーを準備したいと考えています。

また：

LabVEIW などのグラフィカル言語はプログラミングの未来だと思いますか?
グラフィック言語はテキスト言語より習得が容易ですか? 私は、彼らは学ぶのがほぼ同じように挑戦的であるべきだと思います.
私たちは部分的に人々の学習を支援することに根ざしているため、事前に作成されたモジュールにどれだけ依存し、どれだけ自分で作成しようとする必要があるでしょうか? (「優れたプログラマーは優れたコードを書き、優れたプログラマーは優れたコードをコピーします。」しかし、まず、優れたプログラマーになる価値はありませんか?)

アドバイスありがとう！

編集: この質問をもっと強調したいと思います: チームのキャプテンは、LabVIEW が学習と教育の容易さの点で優れていると考えています。 本当？ Cも同じように簡単に教えられると思いますし、初心者レベルのタスクはまだCであると思います。あなたの意見を聞きたいです。 while{} の入力が「while ボックス」の作成より難しい理由はありますか? プログラムが 1 行ずつ流れ、if とループによってのみ変更されるのと同じように、プログラムがワイヤーを介して流れ、if とループによってのみ変更されるのと同じくらい直感的ではありませんか!?

再度、感謝します！

編集：これが「言語論争」のトピックに該当することに気付きました。これは、特定の目標を持った特定のプログラミングブランチに最適なものに関するものなので、問題ないことを願っています。そうじゃなかったら…ごめんなさい…

score 34 · Accepted Answer

私が到着する前、私たちのグループ (プログラミングのバックグラウンドがほとんどない博士号を持つ科学者) は、ほぼ 1 年間、LabVIEW アプリケーションのオンとオフの実装を試みていました。コードが乱雑で複雑すぎ (フロントエンドとバックエンド)、そして最も重要なことに、機能しませんでした。私は熱心なプログラマーですが、LabVIEW を使用したことはありません。私が知っていたテキストプログラミングパラダイムをLabVIEWの概念に翻訳するのを手伝ってくれるLabVIEWの第一人者からの少しの助けにより、1週間でアプリをコーディングすることができました. ここでのポイントは、基本的なコーディングの概念を学ぶ必要があるということです.言語は、LabVIEWのようなものであっても、それらを表現する別の方法です.

LabVIEW は、もともと設計された用途に最適です。つまり、DAQ カードからデータを取得し、画面上に表示するには、おそらくその間にいくつかの小さな操作を行います。ただし、アルゴリズムのプログラミングは簡単ではなく、より難しいことをお勧めします。たとえば、ほとんどの手続き型言語では、実行順序は通常、疑似数学表記を使用して行y = x*x + x + 1ごとに追跡されますが(つまり、キャンバスに。

さらに、キャリアとしてのプログラミングは、コーディングの技術を知るだけではありません。効果的にヘルプを求めたり、回答を検索したり、読みやすいコードを記述したり、レガシーコードを操作したりできることはすべて、LabVIEW などのグラフィカル言語では明らかに難しい重要なスキルです。

サブ VI の使用は、プログラミングの「ブラックボックス」原理を完全に具現化しており、Yahoo Pipesや Apple Automator などの他の言語の抽象化でも使用されています。言語は私たちのプログラミング方法に革命をもたらしますが、LabVIEW 自体は言語設計における大規模なパラダイムシフトではなく、while, for, ifフロー制御、型キャスト、イベント駆動型プログラミング、さらにはオブジェクトさえも備えています。未来が本当に LabVIEW で書かれるのであれば、C++ プログラマーは難なく乗り越えられるでしょう。

あとがきとして、C/C++ はロボティクスに適していると言えます。学生は間違いなく組み込みシステムや FPGA を扱う必要があるからです。低レベルのプログラミング知識 (ビット、レジスタなど) は、この種のことには非常に貴重です。

@mendicant実際、LabVIEW は業界、特に制御システムで多く使用されています。確かに、NASA が搭載衛星システムに使用する可能性は低いですが、宇宙システムのソフトウェア開発はまったく別の球技です...

score 12 · Accepted Answer

私が現在所属している研究グループでも似たような状況に遭遇したことがあります。それは生物物理学のグループで、あらゆる場所で LabVIEW を使用して機器を制御しています。これは非常にうまく機能します。機器のすべての側面を制御し、そのステータスを表示し、データを保存するための UI を簡単に組み立てることができます。

私にとって LabVIEW は悪夢だったので、今は 5 ページにわたる暴言を書くのをやめなければなりません。代わりに、いくつかの長所と短所を要約してみましょう。

免責事項私はLabVIEWの専門家ではありません。偏った、時代遅れの、または単に間違っていることを言うかもしれません:)

LabVIEWのプロ

はい、習得は簡単です。私たちのグループの多くの博士号は、数週間かそれ以下でハッキングするのに十分なスキルを身につけているようです。
ライブラリ。これは大きなポイントです。自分の状況でこれを慎重に調査する必要があります（適切なLabVIEWライブラリがあるかどうか、または他の言語に代替手段があるかどうか、何が必要かわかりません）。私の場合、たとえば、Python で優れた高速チャート作成ライブラリを見つけることが大きな問題でした。そのため、Python でプログラムの一部を書き直すことができませんでした。
あなたの学校では、すでにインストールして実行しているかもしれません。

LabVIEWの短所

学ぶのは簡単すぎるかもしれません。いずれにせよ、ベストプラクティスを学ぼうとする人は誰もいないようで、プログラムはすぐに完全で取り返しのつかない混乱になります。確かに、注意しないとテキストベースの言語でも同じことが起こりますが、LabVIEW で正しく処理するのははるかに困難です。
LabVIEW では、サブ VI を見つける際に大きな問題が発生する傾向があります(バージョン 8.2 まででも)。LabVIEWには、ライブラリとサブVIの場所を知る独自の方法があるため、ソフトウェアを完全に壊してしまうのは非常に簡単です。これを処理する方法を知っている人が周りにいない場合、大規模なプロジェクトは苦痛になります。
LabVIEW をバージョン管理で動作させるのは大変です。確かにそれはできますが、いずれにせよ組み込み VC の使用は控えたいと思います。LabVIEW 差分ツールのLVDiffを調べてください。ただし、マージについては考えないでください。

(最後の 2 つのポイントは、1 つのプロジェクトでチームで作業することを困難にします。それはおそらくあなたの場合に重要です)

これは個人的なことですが、多くのアルゴリズムは視覚的にプログラムされているだけでは機能しないことがわかりました。めちゃくちゃです。
- 1 つの例は、厳密にシーケンシャルなものです。それはすぐに面倒になります。
- コードの概要を把握するのは困難です。
- 小さなタスクにサブ VI を使用する場合 (小さなタスクを実行し、1 つの画面に収まる関数を作成するのが良い方法であるように)、名前を付けるだけではなく、それぞれにアイコンを描画する必要があります。そのうちの。これは、ほんの数分で非常に面倒で面倒になるため、サブ VI に何かを入れたくないという誘惑にかられます。面倒くさいだけです。ところで、本当に良いアイコンを作るには、何時間もかかります。作成したすべてのサブ VI に、一意ですぐに理解できる認識可能なアイコンを作成してみてください :)
1週間以内に手根管ができます。保証します。
@ブレンダン：聞いて、聞いて！

おわりに

あなたの「自分のモジュールを書くべきですか」という質問については、よくわかりません。時間の制約によって異なります。必要がなければ、車輪の再発明に時間を費やさないでください。低レベルのコードを書くのに何日も費やした後、時間がなくなったことに気付くのはあまりにも簡単です。それがLabVIEWを選択することを意味する場合は、それを選択してください。

LabVIEW と C++ などを組み合わせる簡単な方法があれば、それについて聞きたいです。

ただし、あなたとあなたのチームは、ベストプラクティスの学習に時間を費やすようにしてください。お互いのコードを見ています。お互いから学ぶ。使いやすく、わかりやすいコードを書く。そして楽しんで！

そして、エッジの効いた、おそらくやや衒学的に聞こえることをお許しください。LabVIEWは私にとって本当に悪夢でした:)

score 9 · Accepted Answer

LabVIEWを選択するかどうかは、市場性のあるスキルとして一般的に使用される言語でプログラミングを学びたいのか、それとも単に物事を成し遂げたいのかによって決まると思います。LabVIEWを使用すると、非常に迅速かつ生産的に作業を完了できます。他の人が観察しているように、それはあなたが何をしているのかを魔法のように理解する必要からあなたを解放しません、そしてあなたが理解しなければ不潔な混乱を引き起こす可能性があります-逸話的に、LabVIEWの悪いコーディングスタイルの最悪の例は一般に、テキスト言語の経験があり、LabVIEWの動作に適応することを拒否する人々によって実行されます。なぜなら、彼らは「プログラミングの方法をすでに知っているからです」。

もちろん、LabVIEWプログラミングが市場性のあるスキルではないことを意味するものではありません。C++ほどマスマーケットではないというだけです。

LabVIEWを使用すると、並行して実行されるさまざまな処理を非常に簡単に管理できます。これは、ロボット制御の状況で発生する可能性があります。シーケンシャルである必要があるコードの競合状態も問題にはなりません（つまり、問題がない場合は、間違っています）：必要に応じて正しい順序で処理が行われるようにするための簡単なテクニックがあります-サブVIを使用してサブVIをチェーンしますエラーワイヤまたはその他のデータ、ノーティファイアまたはキューを使用して、ステートマシン構造を構築します。必要に応じてLabVIEWのシーケンス構造を使用します。繰り返しになりますが、これは、LabVIEWで利用可能なツールとそれらがどのように機能するかを理解するために時間をかける場合にすぎません。subVIアイコンを作成しなければならないという不満はあまりよく方向付けられていないと思います。おそらく背景色で、テキストのいくつかの単語を含むものを非常にすばやく作成できます。

「グラフィカル言語は未来の道ですか」は、誤った二分法に基づく赤いニシンです。グラフィカル言語に適しているものもあります（たとえば、並列コード）。他のものはテキスト言語にはるかに適しています。LabVIEWとグラフィカルプログラミングがなくなることも、世界を引き継ぐことも期待していません。

ちなみに、NASAが宇宙プログラムでLabVIEWを使用していなかったら、私は非常に驚きます。最近、Info-LabVIEWメーリングリストで、ボーイング787の電気モーターによって作動する飛行面の閉ループ制御をLabVIEWを使用して開発およびテストした方法について説明し、LabVIEWが飛行機の開発に広く使用されているという印象を与えました。大型ハドロン衝突型加速器のリアルタイム制御にも使用されます！

National Instruments自身のサイトやフォーラムを除いて、LabVIEWに関する詳細情報やヘルプを入手するために現在最も活発な場所は、LAVAのようです。

score 6 · Accepted Answer

これはあなたの質問に直接答えるものではありませんが、解釈された言語で混合するという 3 番目のオプションを検討することをお勧めします。たとえば、Luaはすでにロボット工学の分野で使用されています。ほとんどのマイクロコントローラーには FPU がないため、高速で軽量で、浮動小数点数ではなく固定小数点数で実行するように構成できます。Forは、同様の使用法を持つ別の代替手段です。

C で薄いインターフェイスレイヤーを作成し、解釈されたスクリプトで学生を解放するのは非常に簡単なはずです。チップを再コンパイルしてフラッシュすることなく、コードを動的にロードできるように設定することもできます。これにより、反復サイクルが短縮され、生徒は結果をより迅速に確認することでよりよく学習できるようになります。

私は、LabVIEW などのビジュアルツールの使用に偏見を持っています。私はいつも、自分がやりたいようにうまくいかない、またはうまくいかないことをやっているようです。したがって、私はテキストコードで得られる絶対的な制御を好みます。

score 6 · Accepted Answer

LabVIEW のその他の強み (ライブラリ以外) は同時実行性です。これはデータフロー言語であり、ランタイムが同時実行を処理できることを意味します。そのため、高度に並行して何かを行っていて、従来の同期を行う必要がない場合は、LabVIEW が役立ちます。

未来は、現在のグラフィカル言語に属していません。これは、グラフィカルなアプローチと同じくらい簡単で、プログラマー自身のツールで解析できるデータフロー (または別の並行処理に適したタイプのプログラミング) の表現を思い付くことができる人に属します。

score 4 · Accepted Answer

グラフィック言語は、テキスト言語に比べて表現度が常に制限されていると思います。視覚的な記号（例：REBUSや手話）でのコミュニケーションと、言葉を使ったコミュニケーションを比較してください。

単純なタスクの場合、通常はグラフィカル言語を使用する方が簡単ですが、より複雑なロジックの場合、グラフィカル言語が邪魔になることがわかります。

ただし、この議論で暗示されるもう1つの議論は、宣言型プログラミングと命令型プログラミングです。宣言型は通常、何かがどのように行われるかをきめ細かく制御する必要がない場合に適しています。C ++は宣言型の方法で使用できますが、それを実現するには事前にさらに作業が必要になりますが、LABViewは宣言型言語として設計されています。

絵は千の言葉の価値がありますが、絵があなたが必要としない千の言葉を表していて、それを変えることができないなら、その場合、絵は価値がありません。一方、言葉を使って何千もの写真を作成し、細部をすべて指定し、視聴者の焦点を明示的に導くことさえできます。

score 4 · Accepted Answer

ナショナルインスツルメンツが主催するこのトピックに関する研究が公開されています。

DSP 教育のためのグラフィカルプログラミングとテキストプログラミングの研究

具体的には、LabVIEW と MATLAB (C ではなく) を比較します。

score 4 · Accepted Answer

LabVIEW を使用するとすぐに使い始めることができ、(他の人がすでに言っているように) さまざまなテスト、測定、および制御関連のことを行うためのコードの膨大なライブラリがあります。

ただし、LabVIEW の唯一の最大の欠点は、プログラマーが自分で作成したすべてのツールを失うことです。

コードは VI として保存されます。これらは不透明なバイナリファイルです。これは、コードが実際にはあなたのものではなく、LabVIEW のものであることを意味します。独自のパーサーを作成することも、コードジェネレーターを作成することも、マクロやスクリプトを介して自動化された変更を行うこともできません。

これは、5000 VI のアプリを使用している場合、微調整を全体的に適用する必要があります。あなたの唯一の選択肢は、すべての VI を手動で調べることです。

はい、バイナリなので、テキスト言語のように diff/merge/patch を実行することはできません。これにより、複数のバージョンのコードを扱うことは、保守性にとって恐ろしい悪夢になります。

簡単なことをしている場合、プロトタイプを作成する必要がある場合、またはコードを維持する予定がない場合は、必ず LabVIEW を使用してください。

保守しやすい本物のプログラミングを行いたい場合は、テキスト言語を使用してください。始めるのは遅くなるかもしれませんが、長期的には速くなります。

(ああ、DAQ ライブラリが必要な場合、NI はそれらの C++ および .Net バージョンも提供しています。)

score 2 · Accepted Answer

なんてこった、答えはとても簡単です。LabViewを使用します。

私は 10 年間組み込みシステムをプログラミングしてきましたが、少なくとも 2 か月のインフラストラクチャ (非常に慎重なインフラストラクチャ!) がなければ、 LabViewを使用した初日ほどの生産性は得られないと言えます。

軍事用に販売および使用するロボットを設計している場合は、C から始めてください。これは良い判断です。

それ以外の場合は、最短時間で最も多くの種類を試すことができるシステムを使用してください。それがLabViewです。

score 2 · Accepted Answer

LabVIEWが大好きです。他の人が似たようなものを使用したことがある場合は特に、強くお勧めします. 通常のプログラマーが慣れるまでにはしばらく時間がかかりますが、プログラミングの方法を既に知っていれば、結果ははるかに良くなります。

C/C++ は、独自のメモリを管理します。あなたはメモリリンクを泳いでいて、それらについて心配しています. LabVIEW を使用し、LabVIEW に付属のドキュメントを読み、競合状態に注意してください。

言語を学ぶのは簡単です。プログラミングの方法を学ぶことはそうではありません。これはグラフィカル言語であっても変わりません。グラフィカル言語の利点は、そこに座って大量のテキストを解読するよりも、コードが何をするかを視覚化する方が簡単であることです。

重要なのは言語ではなく、プログラミングの概念です。少し努力すれば、どの言語でも上手にプログラミングできるようになるはずなので、どの言語でプログラミングを学ぶかは重要ではありません。言語は行ったり来たりします。

score 2 · Accepted Answer

免責事項: LabVIEW は見たことがありませんが、WebMethods Flow や Modeller、大学での動的シミュレーション言語、MIT の Scratch など、他のいくつかのグラフィカル言語を使用したことがあります :)。

私の経験では、グラフィカル言語はプログラミングの「配管」部分をうまく処理できますが、積極的に使用したものはアルゴリズムの邪魔になります。アルゴリズムが非常に単純であれば、それで問題ないかもしれません。

一方、C++ もあなたの状況に適しているとは思いません。有用な作業よりも、ポインターとメモリ管理の問題を追跡することに多くの時間を費やすことになります。

スクリプト言語 (Python、Ruby、Perl など) を使用してロボットを制御できる場合は、それがより良い選択になると思います。

次に、ハイブリッドオプションがあります。

ロボットにスクリプト作成オプションがなく、チームに C++ オタクがいる場合は、そのオタクにバインディングを作成させて、C++ ライブラリをスクリプト言語にマップすることを検討してください。これにより、他の専門分野を持つ人々がロボットをより簡単にプログラミングできるようになります。ビンディングはコミュニティへの良い贈り物になるでしょう。

LabVIEW で許可されている場合は、そのグラフィカル言語を使用して、テキスト言語で記述されたモジュールを組み立てます。

score 1 · Accepted Answer

いつものように、それは依存します。

私は約 20 年前から LabVIEW を使用しており、単純な DAQ から非常に複雑な視覚化、デバイス制御からテストシーケンサまで、非常に多くの種類の仕事を行ってきました。ダメだったら間違いなく乗り換えていました。そうは言っても、パンチカードを使って Fortran のコーディングを開始し、Z80 ベースのマシンから始めて、8 ビットの「マシン」で多くのプログラミング言語を使用しました。言語は、アセンブラーから BASIC、Turbo-Pascal から C にまで及びました。

LabVIEW は、データ収集と解析のための豊富なライブラリにより、大幅に改善されました。しかし、別のパラダイムを学ばなければなりません。そして、あなたは間違いなくトラックボールが必要です;-))

score 1 · Accepted Answer

私は、グラフィカル言語が将来の言語になるかもしれないと考えています....そこにいるすべてのアドホックなMS Access開発者にとって. 純粋なテキストコーダーの居場所は常にあります。

個人的には、ロボットを作ることの本当の楽しみは何ですか? そこに「赤いボールを見つける」モジュールをドロップして、それが動くのを見たら？あなたは自分の業績に対してどのような誇りを持っていますか? 個人的には、あまりありませんでした。さらに、コーディングについて、またはロボット工学で重要なソフトウェア/ハードウェアインターフェイスの (非常に重要な) 側面について、何を教えてくれるのでしょうか?

私はこの分野の専門家ではありませんが、1 つ自問してみてください。NASA は LabVIEW を使用して火星探査機をコーディングしたと思いますか? ロボット工学の分野で真に著名な人物が LabView を使用していると思いますか?

本当に、あなたが私に尋ねると、LabVIEWのようなクッキーカッターを使用してこれを構築する唯一の準備は、裏庭のロボットビルダーになることだけです. 業界での経験に近いものが必要な場合は、独自の「LabVIEW」タイプのシステムを構築してください。独自のボール探しモジュール、または独自の「フォローザライン」モジュールを構築します。はるかに難しくなりますが、よりクールでもあります。:D

score 1 · Accepted Answer

あなたは高校生です。このプログラムに取り組むのにどのくらいの時間がかかりますか? あなたのグループは何人ですか？彼らはすでに C++ や LabView を知っていますか?

あなたの質問から、あなたは C++ を知っていて、ほとんどのグループは知らないことがわかりました。また、グループリーダーは、チームの一部のメンバーがテキストベースのプログラミング言語に怯えている可能性があることに気付くのに十分な洞察力を持っているのではないかと思います。これは許容範囲です。あなたは高校生であり、これらの人々は正常です。普通の高校生ならLabViewの方がC++よりも直感的に理解できる気がします。高校生のほとんどは、一般の人々と同じように、コマンドラインを怖がっていると思います。あなたにとってはそれほど違いはありませんが、彼らにとっては昼と夜です。

同じ概念が C++ として LabView に適用される可能性があることは正しいです。それぞれに長所と短所があります。重要なのは、ジョブに適したツールを選択することです。LabView は、この種のアプリケーション向けに設計されました。C++ はより一般的で、他の多くの種類の問題に適用できます。

LabView をお勧めします。適切なハードウェアがあれば、ほぼそのまま使用できます。あなたのチームは、ロボットにあなたが望むことをさせるために、より多くの時間を費やすことができます。これが、このアクティビティの焦点であるべきです。

グラフィカル言語はプログラミングの未来ではありません。それらは、長年にわたり、特定のタイプの問題を解決するために作成された、利用可能な選択肢の 1 つです。プログラミングの未来は、マシンコードから離れた抽象化のレイヤーごとです。将来的には、「セマンティクス」のプログラミングに何度も何度も時間を費やした理由を考えることになるでしょう。

事前に作成されたモジュールにどの程度依存する必要があり、独自に作成する必要があるか? 車輪の再発明に時間を費やすべきではありません。Labview で利用可能なデバイスドライバがある場合は、それらを使用します。機能が似ているコードをコピーして、ニーズに合わせて調整することで、多くのことを学ぶことができます。他の人が同様の問題をどのように解決したかを見ることができ、自分の問題に適切に適用する前に、彼らの解決策を解釈する必要があります。コードをやみくもにコピーした場合、それが機能する可能性はほとんどありません。コードをコピーしたとしても、上手でなければなりません。

頑張ってください！

score 1 · Accepted Answer

LabVIEWを使用することをお勧めします。ロボットをより速く簡単にやりたいことに取り掛かることができるからです。LabVIEW は、このことを念頭に置いて設計されています。もちろん C(++) は優れた言語ですが、LabVIEW は他の何よりも優れた機能を備えています。LabVIEWは十分な範囲とサポートを提供するため、LabVIEWで本当に優れたソフトウェアを作成できます。

score 1 · Accepted Answer

私はLabViewについては何も知りません(またはC/C++についてはあまり知りません)が..

LabVEIW などのグラフィカル言語はプログラミングの未来だと思いますか?

いいえ...

グラフィック言語はテキスト言語より習得が容易ですか? 私は、彼らは学ぶのがほぼ同じくらい挑戦的であるべきだと思います.

習得しやすい？いいえ、しかし、それらは説明と理解がより簡単です。

プログラミング言語を説明するには、変数とは何かを説明する必要があります (これは驚くほど難しいことです)。これは、LEGO Mindstroms プログラミングインターフェイスや Quartz Composer などのフローグラフ/ノードコーディングツールでは問題になりません。

たとえば、これはかなり複雑な LEGO Mindstroms プログラムです。何が起こっているのかを理解するのは非常に簡単です...しかし、ロボットにINCREASEJITTERブロックを 5 回実行させ、次に 10 秒間前進させてから、INCREASEJITTER を試してください。またループ？物事は非常に急速に混乱し始めます..

Quartz Composer はこの素晴らしい例であり、グラフィカル言語が「未来」になるとは思えない理由です。

これにより、非常に優れたもの (Web カメラからのピクセルの平均輝度によって制御されるカメラを使用した 3D パーティクルエフェクト) を非常に簡単に実現できます。その平均ピクセル値をファイルに。

私たちは部分的に人々の学習を支援することに根ざしているため、事前に作成されたモジュールにどれだけ依存し、どれだけ自分で作成しようとする必要があるでしょうか? (「優れたプログラマーは優れたコードを書き、優れたプログラマーは優れたコードをコピーします。」しかし、まず、優れたプログラマーであることに価値があるのではないでしょうか?)

学習に関しては、グラフィック言語を説明して理解する方がはるかに簡単です..

そうは言っても、私は専門的なテキストベースの言語を進歩としてお勧めします. たとえば、ProcessingやNodeBoxなどのグラフィックスの場合。それらは「通常の」言語 (Processing は Java、NodeBox は Python) であり、非常に専門的で使いやすい (しかし非常に強力な) フレームワークが組み込まれています。

重要なことは、それらは非常にインタラクティブな言語であり、画面上に円を表示するためだけに何百行も書く必要がないということです.入力oval(100, 200, 10, 10)して実行ボタンを押すだけで、円が表示されます! これにより、デモンストレーションと説明が非常に簡単になります。

もっとロボティクス関連で、LOGO のようなものでもよい導入になるでしょう。「FORWARD 1」と入力すると、カメはボックスを 1 つ前進します.「LEFT 90」と入力すると、カメは 90 度回転します.. 各命令が何を行うかを視覚化してから、実際に試してみて、実際にそのように機能することを確認できます。

彼らにピカピカのものを見せてください、彼らは途中でCから学ぶ有用なことを拾います.彼らが興味を持っているか、「本当の」言語が必要なところまで進んでいるなら、彼らはすべての知識を持っているでしょう.構文エラーが発生し、ブリックウォールをコンパイルしています..

score 1 · Accepted Answer

アプリケーションに LabVIEW を使用する際に、大きなマイナス点が 1 つあります。それは、設計の複雑さを整理することです。物理学者として、Labview はプロトタイピング、機器制御、数学的解析に最適だと思います。LabVIEW よりも速く、より良い結果が得られる言語はありません。1997 年から LabView を使用していました。2005 年からは、設計と保守が容易な .NET フレームワークに完全に切り替えました。

LabVIEW では、単純な「if」構造を描画する必要があり、グラフィックデザインで多くのスペースを使用します。商用アプリケーションの多くは保守が難しいことがわかりました。アプリケーションが複雑になればなるほど、読むのが難しくなりました。

私は現在、テキスト言語を使用しており、すべてを維持するのにはるかに優れています. C++ と LabVIEW を比較するなら LabVIEW を使用しますが、C# と比較すると勝てません。

score 0 · Accepted Answer

あなたがプログラミングの将来のために私たちのチームを準備しようとしているなら、C（++）がより良いルートであるように思われます。視覚的なビルディングブロックで構築された一般的なプログラミング言語の約束は実現したようには見えませんでした。特定の問題領域に対しては実行できますが、多くの一般的な問題を解決しようとすると、テキストベースのプログラミング言語に勝るものはないようです。

かつて私は実行可能なUMLのアイデアに夢中になりましたが、オブジェクトの関係とプロセスフローの一部を通過すると、UMLはアプリを構築するためのかなり惨めな方法になるようです。すべてをGUIに接続しようとしていると想像してみてください。間違っていることが証明されてもかまいませんが、これまでのところ、ポイントアンドクリックプログラミングがすぐに行われる可能性は低いようです。

score 0 · Accepted Answer

Labview（およびこの点でMatlab）に対する私の不満は、コードをx86以外に埋め込むことを計画している場合（そしてLabviewにはLabview VIをARMに配置するためのツールがある場合）、問題にできるだけ多くの馬力を投入する必要があるということです非効率的であるため、できる限りです。

Labviewは優れたプロトタイピングツールです。多くのライブラリ、ブロックをつなぎ合わせるのは簡単、高度なアルゴリズムを実行するのは少し難しいかもしれませんが、おそらくあなたがやりたいことのためのブロックがあります。機能をすばやく実行できます。しかし、あなたがそのVIを取り、それをデバイスに置くことができると思うなら、あなたは間違っています。たとえば、Labviewで加算器ブロックを作成すると、2つの入力と1つの出力があります。そのためのメモリ使用量はどれくらいですか？データに値する3つの変数？二？CまたはC++では、コードを記述しz=x+yたりx+=y、コードが何を実行しているか、メモリの状況を正確に把握しているため、ご存知のとおりです。特に（他の人が指摘しているように）Labviewは高度に並列であるため、メモリ使用量は急速に急増する可能性があります。したがって、問題で思ったよりも多くのRAMを投入する準備をしてください。そして、より多くの処理能力。

つまり、Labviewはラピッドプロトタイピングに最適ですが、他の状況では制御が行き過ぎてしまいます。大量のデータまたは限られたメモリ/処理能力で作業している場合は、テキストベースのプログラミング言語を使用して、何が行われるかを制御できます。

score 0 · Accepted Answer

Microsoft Robotics Studio をご覧になりましたか? http://msdn.microsoft.com/en-us/robotics/default.aspx

ビジュアルプログラミング (VPL): http://msdn.microsoft.com/en-us/library/bb483047.aspx や、C# などの最新の言語を使用できます。少なくともチュートリアルを確認することをお勧めします。

score 0 · Accepted Answer

私は約 2 年前に LabVIEW を使い始めましたが、現在は常に使用しているため偏見があるかもしれませんが、データの取得と制御が必要なアプリケーションには理想的です。

LabVIEW は主に、連続測定を行い、ガスバルブと ATE エンクロージャを制御するテストに使用します。これには、デジタルとアナログの両方の入力と出力が含まれ、信号分析ルーチンとプロセス制御がすべて GUI から実行されます。各パーツをサブ VI に分割することで、マウスをクリックしてドラッグするだけでテストを再構成できます。

C/C++ とまったく同じではありませんが、Visual BASIC を使用した同様の測定、制御、および分析の実装は、比較すると複雑で保守が難しいように見えます。

プログラミングのプロセスは実際のコーディング言語よりも重要であり、グラフィカルプログラミング言語のスタイルガイドラインに従うべきだと思います。LabVIEWブロックダイアグラムはデータの流れ（データフロープログラミング）を示しているので、問題が発生したことはありませんが、潜在的な競合状態を簡単に確認できるはずです。C コードベースがある場合、それを dll にビルドすると、LabVIEW がそれを直接呼び出すことができます。

score 0 · Accepted Answer

チームのキャプテンは、LabVIEWの方が学習と教育のしやすさで優れていると考えています。本当？

それがどの言語やパラダイムにも当てはまるとは思えません。LabView は、電子工学のバックグラウンドを持つ人にとっては確かに簡単かもしれません。その中でプログラムを作成することは、「単純に」ワイヤーを描くことです。繰り返しになりますが、そのような人々はすでにプログラミングに触れている可能性もあります。

グラフィック以外の重要な違いの 1 つは、LV が要求ベース (フロー) プログラミングであることです。結果から始めて、それに到達するために何が必要かを伝えます。従来のプログラミングは必須である傾向があります (逆に言えば)。

一部の言語では、両方を提供できます。私は最近、Lua 用のマルチスレッドライブラリ (Lanes) を作成しました。これは、必須の環境で要求ベースのプログラミングに使用できます。ほとんどが Lua で実行されている成功したロボットがあることを私は知っています ( Lua Oh Six のCrazy Ivan )。

score 0 · Accepted Answer

どちらの選択にも間違いなくメリットがあります。ただし、あなたのドメインは教育的な経験であるため、C/C++ ソリューションが学生にとって最もメリットがあると思います。グラフィカルプログラミングは常にオプションですが、低レベルプログラミングではテキストプログラミングよりも効率的に使用できる洗練された方法で機能を提供することはできません。これは悪いことではありません。抽象化の全体的なポイントは、問題領域の新しい理解と見方を可能にすることです。しかし、多くの人がグラフィカルプログラミングに失望するかもしれないと私が考える理由は、特定のプログラムについて、C でのプログラミングからグラフィカルへの移行の増加分は、アセンブリから C への移行とほとんど同じではないからです。

グラフィカルプログラミングの知識は、将来のプログラマーにとって確実に役立ちます。将来的には、グラフィカルプログラミングの知識のみを必要とする機会があり、学生の何人かは、グラフィカルプログラミングの初期の経験から恩恵を受ける可能性があります。一方、テキストによるアプローチによって提供される基本的なプログラミング概念の強固な基盤は、すべての学生に利益をもたらし、間違いなくより良い答えに違いありません.

score 0 · Accepted Answer

人々は常にlabviewをC++と比較し、「ああ、labviewは高レベルであり、機能が組み込まれているため、dfftを実行してデータを取得し、データを表示するのはlabviewで非常に簡単なので、C++で試してください」と比較します。

神話 1: C++ は非常に低レベルであり、labview には既に多くの機能が実装されているため、C++ で何かを行うのは困難です。問題は、C++ でロボットシステムを開発している場合、 opencv 、 pcl .. ect などのライブラリを使用する必要があり、ROS (ロボットオペレーティングシステム) などのロボットシステムを構築するために設計されたソフトウェアフレームワークを使用すると、さらにスマートになることです。したがって、フルセットのツールを使用する必要があります。実際、opencv や pcl などのライブラリを備えた ROS + python/c++ を使用すると、より高レベルのツールを使用できます。私は labview ロボティクスを使用しましたが、率直に言って、ICP のような一般的に使用されるアルゴリズムは存在せず、他のライブラリを簡単に使用できるようにもなりません。

誤解 2: グラフィカルプログラミング言語を理解するのは簡単ですか

状況によります。複雑なアルゴリズムをコーディングしている場合、グラフィック要素が貴重な画面スペースを占有し、方法を理解するのが難しくなります。labviewコードを理解するには、上から下に読むだけでコードのO(n^2)の複雑さである領域を読む必要があります。

並列システムがある場合はどうでしょうか。ROS は、コールバックを使用して実装されたサブクライバー/パブリッシャーメッセージに基づくグラフベースのアーキテクチャを実装しており、複数のプログラムを実行して通信するのは非常に簡単です。個々の並列コンポーネントを分離すると、デバッグが容易になります。たとえば、制御フローはある場所から別の場所にジャンプするため、並列の labview コードをステップ実行することは悪夢です。ROS では、labview のようにアーキテクチャを明示的に描画することはありませんが、コマンド ros run rqt_graph (接続されているすべてのノードが表示されます) を実行すると、アーキテクチャを確認できます。

「プログラミングの未来はグラフィカルです。」（そう思う？）

現在の labview の実装では、テキストベースの方法とグラフィカルな方法を使用したコーディングは許可されていません。( mathscript がありますが、これは信じられないほど遅いです)

並列処理を簡単に隠すことができないため、デバッグが困難です。

非常に多くの領域を見なければならないため、labviewコードを読むのは困難です。

Labview は、データ aq および信号処理には最適ですが、SLAM (同時ローカリゼーションとマッピング)、点群登録、点群処理などの高レベルコンポーネントのほとんどが欠落しているため、実験的ロボット工学には適していません。これらのコンポーネントを追加し、ROS のように簡単に統合できたとしても、labview はプロプライエタリで高価であるため、オープンソースコミュニティに追いつくことはできません。

要約すると、ラボビューがメカトロニクスの未来である場合、私はキャリアパスを投資銀行に変更します... 仕事を楽しむことができない場合は、お金を稼いで早期退職することもできます...

robotics - テキストプログラミング言語とグラフィカルプログラミング言語

25 に答える 25

LabVIEWのプロ

LabVIEWの短所

おわりに

Related

Reference