回答:
コンピュータに戻ってきました！
このコメントで述べたように、ROSは通常必須ではありません。ROSは多くのプラットフォームの1つであり、主にWillow Garageが、ある時点で最も多くのROSモジュールを作成した人に無料のロボットを配布することで有名です。とはいえ、それは可能な限り最高のプラットフォームではなく、確かにそれほど特別なものではありません。特に、このコンテストは、数値を上げるためだけに多くの低品質モジュールをもたらしました。
時間の経過とともに、ROSモジュールの品質は向上し、多くのROSモジュールもあります。したがって、ROSを使用すると、すでに行われていることの多くを再利用できるという利点があります。ROSを使用する理由については、こちらをご覧ください。
これを念頭に置いて、副作用についても注意する必要があります。
ROSを使用すると、ネットワークを介して互いに通信する多くのノードがあります。これは適切で簡単な場合もありますが、通常はメッセージの受信に大幅な遅延が発生します。その結果、すべてのメッセージが確実に届くようにするには、制御遅延を大きくする必要があります。つまり、イベントに迅速に対応できず、イベントを逃さないようにロボットを低速で動かす必要があります。
信じられないかもしれませんが、人々は実際にROSを介してロボット制御を行っています（MoveIt！は関連するコンポーネントセットの名前です）。スロー。安全ではない。でも簡単！
分散していない場合でも、ROSはリアルタイムプラットフォームではありません。つまり、Linuxカーネルの裁量により、適切と思われるときにいつでもタスクをスケジュールできます。これは一部のアプリケーションでは問題ありませんが、他のアプリケーションでは問題があります。したがって、独自の要件を確認する必要があります。タスクが既知の時間枠内に完了することを保証する必要がありますか？もしそうなら、あなたはリアルタイムシステムが必要です。
考慮すべきもう1つの点は、ROSは一般的な通信プロトコルですが、基本的にはホストされた環境でのみサポートされていることです。ホストされた手段とは対照的に、カーネルの上にコードが実行され、自立（マイクロコントローラ上で、例えば）コードを直接ハードウェアを制御する手段。
ロボットアプリケーションがハードウェアの近くで実行されているため、マイクロコントローラーで実行されるプログラムが必要な場合、ROSは役に立ちません。
最後に重要なことですが、ROS用に開発すると、プラットフォームがロックインされます。これは、将来、何らかの理由で、OROCOS、YARPなど、耐え難い別のロボットプラットフォームに基づいて作業を行うことを決定したことを意味します。
また、Linuxにある程度ロックされます。Linuxは間違いなく最高ですが、ある日、QNX、VxWorksなどの別のシステムをサポートする必要が生じ、そこでも問題が発生する可能性があります。
マイクロコントローラー向けに作成している場合は、ROSを忘れてください。高レベルのモジュールを作成する場合は、移植可能なコードを作成することを強くお勧めします。たとえば、新しいセンサーを開発し、このセンサーからデータを取得するモジュールを作成して、CANバスを介してコンピューターに接続するとします。
この状況でできることは、センサーと連携してデータを取得できる関数を備えた独立したライブラリを作成することです。定期的にデータを取得してキューに入れるスレッドをライブラリに生成することも考えられます。
このヘルパーライブラリを取得したら、CLI、GUI、ROSモジュール、OROCOSモジュール、YARPモジュール、Matlabへの接続、またはセンサーとのやり取りに使用したいものを自由に作成できます。
最後に、ここで私が述べたことは、ROSだけでなく、すべてのロボットプラットフォームに一般的に当てはまります。
「ROS」は相対的な用語です。APMは、カスタムROSがクラッシュしないようにするのが望ましい可能性があるQuadrocopter制御用に特別に設計された完全なカスタムコードを実行します。一方、Navio +はLinuxカーネルで実行され、オートパイロット以外のコードを実行します。クラッシュを防ぐことができます。ほとんどのROSは、OSをゼロから作成するのではなく、実際には既存のOSの上にある一連の関数です。何でもそうですが、状況によって異なります。
免責事項：この回答は、どういうわけかShahbazの投稿に対する反応であるため、ROSを支持する偏見があります。
ROSは必須ではないと思いますが、これは素晴らしい出発点であり、投資する価値はあります。それはウィローガレージ内で始まりましたが、この会社は消滅し、ROSはまだ生きており、使用され、開発されています。ROSのほとんどは完全にオープンソースであり、商業的にも使用できるため、企業がROSに興味を持たなくなった場合にROSが消滅することはありません。もちろん、コードの品質は、一部のphd学生が彼の論文で公開した最先端のアルゴリズムのコアモジュールと実装の間で異なります。
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）の主要な目標の1つなので、システム全体で将来的に必要になったとしても、ROSはカバーしています。
組み込みのものを本当に実行したい場合は、もちろんarduinoへの接続があります。そのため、シリアル接続を介して送信されるarduinoにROSメッセージを直接書き込むことができます。
WindowsでのROSの実行は現在かなり苦痛ですが、WindowsがLinuxに近づいているため（たとえbashのようなものになり始めたとしても）、それが可能になるまでの時間の問題です。（とにかく、窓付きのロボットを動かしたい人はいますか？）
ハードウェアインターフェイスとアルゴリズム：
これは本当にROSの強みだと思います。多くの市販のロボットには、すでにROSインターフェースが付属しているか、誰かがインターフェースを実装するためにすでに時間を費やしています。ほとんどの商用アームはMoveItで使用できるため、特定のアームでアプリケーションを実行するための作業の多くは、別のハードウェアで再利用できます。
コミュニティ：
ROSのもう1つの長所。新しいアルゴリズムはROSインターフェースを非常に迅速に取得し、多くの人々があなたと同じ問題を抱えていたので、あなたを助ける人を見つけるでしょう。
http://download.ros.org/downloads/metrics/metrics-report-2016-07.pdf