Come integrare / testare le interfacce hardware del software

Question

Sto lavorando a piccoli progetti divertenti che costruiscono un robot. Noi come programmatori stiamo lavorando parallelamente alle persone che costruiscono il robot. Quindi, molto spesso, stiamo provando a eseguire software modificato e i costruttori hanno cambiato l'hardware. Se i test del software non vengono eseguiti, è sempre difficile capire se il software o l'hardware falliscono o, peggio ancora, se l'integrazione fallisce. Ci sono alcune parti rigide con un test automatico per questo problema.

Abbiamo escogitato alcuni modi per abbattere le cose, quindi abbiamo il controllo rc per consentire al robot di eseguire alcuni movimenti senza che il software assicuri che funzioni ancora. Quindi iniziamo alcuni test del software che fanno andare il robot ad alcune cifre definite per mostrare che il software si comporta allo stesso modo di prima. Ma questo si riduce sempre a un compito che richiede molto tempo perché non è possibile automatizzarlo e qualcuno deve iniziare il test, guardare il test e provare a capire se il robot ha fatto quello che doveva fare.

Un altro problema è che i test costanti con il nostro hardware reale stanno consumando parti del nostro hardware, giunto, motori, ruote dentate e così via.

Ma non testare ha dimostrato di causare così tanti problemi e consumare così tanto tempo che vorrei sapere che tipo di tecniche sono utilizzate in altri progetti che si occupano di interazione software hardware e se ci sono strumenti là fuori che possono essere usato.

Answer 1

L'interfaccia tra robot e software deve essere definita per prima; non necessariamente esaustivo, questo potrebbe essere fatto in modo incrementale. Inizia in piccolo, ad esempio con le mosse di base (avanti, indietro), quindi, una volta che è stato completamente testato, sia in isolamento che integrato, aggiungi un po 'di comportamento (ad es. Gira a sinistra, gira a destra), riprova. In questo modo, l'intero team può utilizzare ciò che ha appreso lungo tutto il progetto per estendere l'interfaccia, riducendo al minimo i rielaborazioni dell'interfaccia.

L'articolo Progressi prima dell'hardware descrive questo processo in maggiore dettaglio, concentrandosi su l'aspetto Test-Driven-Development (TDD).

Vedi anche le risposte alla Come fare TDD con hardware .

Answer 2

Penso che sia una situazione molto interessante.

Credo che non ci siano problemi con il processo di test. Se prendi in giro il tuo robot e provi contro questo finto, va tutto bene Se il robot hardware si comporta diversamente dal robot deriso, c'è un altro grosso problema: La comunicazione .

L'interfaccia tra il software e l'hardware è il "protocollo" specifica. Secondo me non deve essere cambiato senza discussione. I ragazzi dell'hardware non possono cambiarlo e anche voi ragazzi del software! Puoi solo cambiarlo insieme. Nella tua situazione, tutti lo cambiano da soli.

Nella tua situazione, le tue squadre sembrano lavorare l'una contro l'altra. Quindi cerca di concentrare i tuoi sforzi sulla tua interfaccia e specialmente sulla tua comunicazione, non nel tuo test di integrazione che non funzionerà comunque.

Un mio suggerimento sarebbe di usare il software finto di un robot come l'unica e unica specifica. Quindi puoi fare affidamento sul tuo finto e c'è un punto centrale che definisce la connessione tra hardware e software.
Quando i ragazzi del software vogliono cambiarlo, ok. Devono discuterne con te e cambierai il software finto. Se l'hardware è stato modificato e non è finto, hai delle scuse, perché sviluppi contro le tue specifiche.

Buona fortuna!