Cómo integrar / probar las interfaces de hardware del software

Question

Estoy trabajando en pequeños proyectos divertidos que construyen un robot. Nosotros, como programadores, trabajamos en paralelo con las personas que construyen el robot. Por lo tanto, muy a menudo estamos tratando de ejecutar un software modificado y los constructores han cambiado el hardware. Si las pruebas de software no se ejecutan, siempre es difícil determinar si el software o el hardware falla o, peor aún, si falla la integración. Hay algunas partes difíciles con una prueba automática para estos problemas.

Hemos descubierto algunas formas de desglosar las cosas, por lo que tenemos control rc para permitir que el robot realice algunos movimientos sin que el software se asegure de que todavía funciona. Luego, comenzamos algunas pruebas de software que hacen que el robot ejecute algunas cifras definidas para mostrar que el software se comporta de la misma manera que antes. Pero esto siempre se reduce a una tarea que consume mucho tiempo porque no se puede automatizar y alguien tiene que comenzar la prueba, verla e intentar averiguar si el robot hizo lo que debería hacer.

Otro problema es que las pruebas constantes con nuestro hardware real están desgastando partes de nuestro hardware, articulaciones, motores, ruedas dentadas, etc.

Pero no se ha comprobado que las pruebas causen tantos problemas y consuman tanto tiempo que me gustaría saber qué tipo de técnicas se utilizan en otros proyectos que tienen que ver con la interacción del software y si hay herramientas que pueden implementarse. utilizado.

Answer 1

La interfaz entre el robot y el software debe definirse primero; no necesariamente exhaustivamente, esto podría hacerse de forma incremental. Comience con algo pequeño, por ejemplo, con movimientos básicos (hacia adelante, hacia atrás), luego, una vez que se haya probado completamente, tanto de forma aislada como integrada, agregue algo de comportamiento (por ejemplo, gire a la izquierda, gire a la derecha), vuelva a probar. De esa manera, todo el equipo puede usar lo que aprendió a lo largo del proyecto para extender la interfaz, posiblemente minimizando las modificaciones de la interfaz.

El artículo Progreso antes del hardware describe dicho proceso con mayor detalle, centrándose en El aspecto del desarrollo dirigido por pruebas (TDD).

Consulte también las respuestas a la Cómo hacer TDD con hardware .

Answer 2

Creo que es una situación muy interesante.

Creo que no hay problema con tu proceso de prueba. Si te burlas de tu robot y lo pruebas, todo está bien.
Si el robot de hardware actúa de manera diferente a su robot burlado, hay otro gran problema: La comunicación .

La interfaz entre el software y el hardware es el protocolo " " especificación. En mi opinión, no debe cambiarse sin discusión. ¡Los chicos del hardware pueden no cambiarlo y ustedes los del software tampoco! Solo pueden cambiarlo juntos. En su situación, todos lo cambian por su cuenta.

En su situación, sus equipos parecen trabajar uno contra el otro. Así que trate de concentrar sus esfuerzos en su interfaz y especialmente en su comunicación, no en su prueba de integración que no funcionará de todos modos.

Una sugerencia mía sería utilizar el simulacro de software de un robot como la única especificación . Así que puede confiar en su simulacro y hay un punto central que define la conexión entre hardware y software.
Cuando los chicos de software quieran cambiarlo, ok. Tienen que discutirlo contigo y cambiarás la simulación del software. Si el hardware fue cambiado y el simulacro no, tiene una disculpa, porque se desarrolla en contra de su especificación.

¡Buena suerte!