我正在做一个有趣的小项目来建造一个机器人。作为程序员，我们与构建机器人的人并行工作。因此，我们经常尝试运行更改后的软件，而构建者已经更改了硬件。如果软件测试没有运行，那么很难确定软件或硬件是否失败，或者如果集成失败则更糟。有一些困难的部分可以自动测试这个问题。
我们已经找到了一些分解的方法，所以我们有 rc 控制让机器人在没有软件的情况下完成一些动作，以确保他仍然可以工作。然后我们开始一些软件测试，让机器人按照一些定义的数字运行，以显示软件的行为方式与以前相同。但这总是归结为一项非常耗时的任务，因为您无法将其自动化，并且必须有人开始测试，观察测试并尝试确定机器人是否做了它应该做的事情。
另一个问题是，对我们真实硬件的不断测试会磨损我们的硬件、关节、电机、齿轮等部件。
但事实证明，不进行测试会造成如此多的麻烦并耗费大量时间，我想知道在其他处理硬件软件交互的项目中使用了哪些技术，以及是否有可用的工具。
必须先定义机器人与软件之间的接口；不一定要详尽无遗，这可以逐步完成。从小处着手，例如基本动作（前进、后退），然后，一旦经过全面测试，无论是孤立的还是综合的，添加一些行为（例如左转、右转），然后重新测试。这样，整个团队就可以使用在整个项目中学到的知识来扩展界面，从而最大限度地减少界面返工。
硬件之前的进展文章更详细地描述了这样一个过程，重点是测试驱动开发 (TDD) 方面。
另请参阅How to do TDD with hardware问题的答案。
我认为这是一个非常有趣的情况。
我相信你的测试过程没有问题。如果你模拟你的机器人并针对这个模拟进行测试，一切都很好。
如果硬件机器人的行为与您模拟的机器人不同，那么还有另一个大问题：通信。
软件和硬件之间的接口是“协议”规范。在我看来，它不能未经讨论就改变。硬件人可能不会改变它，而你们软件人也不会！你只能一起改变它。在你的情况下，每个人都自己改变它。
在您的情况下，您的团队似乎相互对抗。所以试着把你的精力集中在你的界面上，尤其是你的沟通上，而不是在你无论如何都行不通的集成测试上。
我的一个建议是使用机器人的软件模拟作为唯一的规范。所以你可以依赖你的模拟，并且有一个中心点定义了硬件和软件之间的连接。
当软件人员想要更改它时，好的。他们必须与您讨论，您将更改软件模拟。如果硬件改变了而模拟没有改变，你有一个道歉，因为你的开发违背了你的规范。
祝你好运！