ソフトウェア・ハードウェア・インターフェースの統合/単体テストを行う方法

Question

私はロボットを作る小さな楽しいプロジェクトに取り組んでいます。私たちプログラマーは、ロボットを構築する人々と並行して作業します。したがって、私たちが変更されたソフトウェアを実行しようとしていて、ビルダーがハードウェアを変更してしまったというケースは非常によくあります。ソフトウェア テストが実行されていない場合、ソフトウェアまたはハードウェアが故障しているかどうか、あるいは統合が失敗している場合はさらに悪いことに、それを把握することが常に困難になります。この問題の自動テストには難しい部分がいくつかあります。

私たちは物事を分解するいくつかの方法を考え出したので、ロボットがまだ動作していることを保証するソフトウェアなしでロボットにいくつかの動きをさせるための RC 制御を備えています。次に、ソフトウェアが以前と同じように動作することを示すために、ロボットを所定の数値で動作させるいくつかのソフトウェア テストを開始します。しかし、これは常に非常に時間がかかる作業になります。自動化できず、誰かがテストを開始し、テストを監視し、ロボットがすべきことを実行したかどうかを判断する必要があるためです。

もう 1 つの問題は、実際のハードウェアを使用した継続的なテストにより、ハードウェア、ジョイント、モーター、歯車などの部品が磨耗していることです。

しかし、テストを行わないことは非常に多くの問題を引き起こし、非常に多くの時間を費やすことが判明しているため、ハードウェアとソフトウェアの相互作用を扱う他のプロジェクトではどのような技術が使用されているのか、また使用できるツールがあるのか​​どうかを知りたいと思っています。

Answer 1

最初にロボットとソフトウェア間のインターフェースを定義する必要があります。必ずしも網羅的にではなく、これは段階的に行うことができます。例えば、基本的な動き（前方、後方）で小規模に開始し、完全にテストされたら、単独で統合された状態で、いくつかの動作を追加します（左に曲がって、右に曲がってください）、再テストします。このようにして、チーム全体がプロジェクト全体で学んだことを使用してインターフェイスを拡張し、インターフェイスのリワークを最小限に抑えることができます。

ハードウェアの前の進捗状況の記事では、このようなプロセスについて詳しく説明しています。テスト駆動開発（TDD）アスペクト。

ハードウェアでTDDを行う方法の質問への回答もご覧ください。

Answer 2

とても興味深い状況だと思います。

テストプロセスには問題ないと思います。ロボットをモックして、そのモックに対してテストを行っても、問題はありません。
ハードウェア ロボットが模擬ロボットとは異なる動作をする場合、別の大きな問題が発生します。 コミュニケーション.

ソフトウェアとハ​​ードウェア間のインターフェイスは「プロトコル」仕様です。私の考えでは、それは議論なしに変更されるべきではありません。ハードウェア担当者はそれを変更しないかもしれませんが、ソフトウェア担当者も同様です。一緒に変更することのみ可能です。あなたの状況では、誰もが自分で状況を変えます。

あなたの状況では、チームは互いに対立しているように見えます。したがって、どうやっても機能しない統合テストではなく、インターフェース、特にコミュニケーションに重点を置くようにしてください。

私の提案は、ロボットのソフトウェアモックを次のように使用することです。 唯一無二 仕様。したがって、モックに依存することができ、ハードとソフトウェアの間の接続を定義する中心点が存在します。
ソフトウェア担当者がそれを変更したいときは、OK。彼らはそれについてあなたと話し合う必要があり、あなたはソフトウェアモックを変更することになります。ハードウェアが変更され、モックが変更されていない場合は、仕様に反して開発しているため、謝罪する必要があります。

幸運を！