我正在开发一个构建机器人的小型有趣项目。 我们作为程序员正在与构建机器人的人并行工作。所以我们经常会遇到这种情况，我们试图运行改变后的软件，而且制造商已经改变了硬件。如果软件测试没有运行，那么确定软件或硬件是否出现故障是非常困难的，如果集成失败则更加糟糕。 有一些硬件可以自动测试这个问题。如何集成/单元测试软件硬件接口
我们已经想出了一些破解方法，所以我们有rc的控制权让机器人在没有软件的情况下通过一些运动确保他仍然可以工作。 然后，我们开始一些软件测试，使机器人进入一些定义的数字，以显示软件的行为与以前相同。但是这总是要花费很长时间才能完成，因为你不能自动化它，并且有人必须开始测试，观察测试并试图弄清楚机器人是否应该做它应该做的事情。
另一个问题是，用我们真实的硬件进行持续测试会损坏硬件，接头，电机，齿轮等部件。
但是没有测试已经证明会导致如此多的麻烦，并且消耗了太多的时间，我想知道在处理硬件软件交互的其他项目中使用了哪种技术，以及是否有可用的工具使用。
机器人与软件之间的接口必须先定义;不一定详尽，这可以逐步完成。从基本动作（向前，向后）开始很小，然后，一旦完全测试完毕，无论是单独还是整合，都要添加一些行为（例如向左转，向右转），重新测试。这样，整个团队就可以使用它在项目中学到的知识来扩展界面，从而尽可能减少界面的返工。
Progress before Hardware文章更详细地描述了这样的过程，重点介绍了测试驱动开发（TDD）方面。
另请参阅How to do TDD with hardware问题的答案。
我认为这是一个非常有趣的情况。
我相信你的测试过程没有问题。如果你嘲笑你的机器人并对这个模拟进行测试，那就很好。
如果硬件机器人与您的嘲弄机器人行为不同，还有另一大问题：通信。
软件和硬件之间的接口是“协议”规范。我认为不得在没有讨论的情况下改变。硬件家伙可能不会改变它，你也不是软件家伙！你只能一起改变它。在你的情况下，每个人都自己改变它。
在你的情况下，你的团队似乎互相攻击。因此，尽量把精力集中在你的界面上，特别是你的沟通中，而不是在你的集成测试中不管用。
我的建议是使用机器人的软件模拟为的唯一规范。所以你可以依靠你的模拟，并有一个中心点来定义硬件和软件之间的联系。
当软件家伙想改变它，好吧。他们必须与你讨论，你会改变软件模拟。如果硬件改变了，模拟不了，你就会道歉，因为你是根据你的规范开发的。
祝你好运！