6

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

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

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

しかし、ハードウェアとソフトウェアの相互作用を扱っている他のプロジェクトでどのような手法が使用されているか、また使用できるツールがあるかどうかを知りたいと思うほど、テストはそれほど多くの問題を引き起こし、多くの時間を消費することが証明されていません。

4

2 に答える 2

2

とても面白い状況だと思います。

あなたのテスト プロセスに問題はないと思います。ロボットをモックして、このモックに対してテストすれば、すべて問題ありません。
ハードウェア ロボットがモック ロボットとは異なる動作をする場合、別の大きな問題があります:通信です。

ソフトウェアとハ​​ードウェアの間のインターフェースは「プロトコル」仕様です。私の意見では、それは議論なしに変更されるべきではありません。ハードウェアの連中はそれを変更しないかもしれませんし、ソフトウェアの連中もそうではありません! 一緒に変更するだけです。あなたの状況では、誰もが自分でそれを変更します。

あなたの状況では、あなたのチームは互いに敵対しているように見えます。したがって、いずれにせよ機能しない統合テストではなく、インターフェイス、特にコミュニケーションに力を注ぐようにしてください。

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

幸運を！

于 2009-06-17T05:48:07.377 に答える