Cómo integrar/probar interfaces de hardware de software de la unidad

Question

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

Hemos descubierto algunas formas de romper las cosas, de modo que tenemos control de RC para permitir que el robot realice algunos movimientos sin que el software asegure que todavía funciona. Luego comenzamos algunas pruebas de software que hacen que el robot avance 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, observar la prueba y tratar de descubrir si el robot hizo lo que debería hacer.

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

Pero no probar ha causado tantos problemas y consumir 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 de hardware y si hay herramientas que pueden ser usado.

Answer 1

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

El artículo Progress before Hardware describe dicho proceso en mayor detalle, centrándose en el aspecto Prueba-Dirigida-Desarrollo (TDD).

Consulte también las respuestas a la pregunta How to do TDD with hardware.

Answer 2

Creo que es una situación muy interesante.

Creo que no hay ningún problema con su proceso de prueba. Si te burlas de tu robot y pruebas contra este simulacro, todo está bien.
Si el robot de hardware actúa de forma diferente a su robot simulado, existe otro gran problema: La comunicación.

La interfaz entre el software y el hardware es la especificación del "protocolo". En mi opinión, no debe cambiarse sin discusión. ¡Es posible que los chicos del hardware no lo cambien y tu software no lo haga! Solo puedes cambiarlo juntos. En su situación, todo el mundo lo cambia por su cuenta.

En su situación, sus equipos parecen funcionar uno contra el otro. Así que trate de enfocar 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. Entonces puede confiar en su simulacro y hay un punto central que define la conexión entre hardware y software.
Cuando los chicos del software quieren cambiarlo, está bien. Deben discutirlo contigo y cambiarás el simulacro de software. Si el hardware fue cambiado y el simulacro no, tienes una disculpa, porque desarrollas contra tu especificación.

Buena suerte!