Softwaretests für Testsoftware

Der chaotische Hauptfaden

Moderatoren: Finger, Sven, TDI, Heaterman, duese

Antworten
lüsterklemme2000
Beiträge: 231
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Softwaretests für Testsoftware

Beitrag von lüsterklemme2000 » Sa 1. Mai 2021, 08:12

Moin,

zusammen mit einem Mitbastler baue ich gerade eine Drohne bzw. die Steuerungshard und -software. Um das ganze nicht in einem Fiasco enden zu lassen, sodass der erste Flug eine Bruchlandung wird habe ich einen Teststand zusammengeschustert. Ein Microcontroller liest fleißig die MotorPWMs des Drohnencontrollers ein und emuliert im Gegenzug sämtliche Sensoren, also Kompass, Luftdruck, IMU, GPS etc.. Der Microcontroller redet über den Seriellen Port mit einem PC auf dem die eigentliche Testsoftware und Visualisierung läuft.
Die Testsoftware ist am Ende nur ein selbstgeschriebenes physikalisches Modell der Drohne, also nur Matrix- und Vektorrechnung. Für einen Zeitpunkt werden grob gesagt alle angreifenden Kräfte und daraus resultierenden Drehmomente berechnet, mittels Massenträgheit die translatorischen und rotatorischen Beschleunigungen berechnet und diese dann mit der Simulationszeit multipliziert auf die jeweiligen Geschwindigkeiten addiert.
Aber da ich mich dabei gerne verrechne jetzt die Frage: Wie verifiziere ich ob die Physiksimulation keinen Denkfehler drin hat und damit der Realität recht nahe kommt? Klar lässt sich sowas wie Freier Fall und ähnliches sehr einfach Nachrechnen und das Stimmt auch.
Die Visualisierung spricht auch dafür, dass alles soweit hinkommt, aber wie testet man sowas "vernünftig"?

Wir haben nämlich schon eine Flugsteuerung um ein Physikmodell gebaut, bei welchem eine Koordinatentransformation falsch war und daher die gesamten PID Werte jetzt nutzlos sind :roll:

Welche Simulationszeiten sind anzustreben/notwendig um die Realität mit vertretbarem Fehler anzunähern? Aktuell hat das Programm Durchlaufzeiten bei ~15 ms.

Ich hoffe das ist kein zu Computerlastiges Thema, immerhin ist der Bastelbezug ja noch gegeben ;)

Lüsterklemme

ch_ris
Beiträge: 1282
Registriert: Mo 30. Nov 2015, 10:08

Re: Softwaretests für Testsoftware

Beitrag von ch_ris » Sa 1. Mai 2021, 09:09

"Matrix- und Vektorrechnung"
also FEM? Puh... komplizierte sache.
wenn nicht... das braucht's aber für nicht-lineare Probleme.
bzw. das wäre dann eine Möglichkeit deine Rechnung zu prüfen.
muss aber wiederum selbst an der Realität geprüft werden.

hab das mal für ein 2D Biegeproblem gemacht, das war für mich extrem fordernd, aber peanuts gegen das hier.

edit. evtl. wäre eine Spiele Physik engine was?
das ist zwar vermutlich ungenau, vielleicht reichts?
https://github.com/ThePhysicsGuys/Physics3D

edit. an die nötige Auflösung würde ich mich heran iterieren.
Je feiner du die machst desto kleiner werden die Wert Änderung zur vorherigen werden.

ch_ris
Beiträge: 1282
Registriert: Mo 30. Nov 2015, 10:08

Re: Softwaretests für Testsoftware

Beitrag von ch_ris » Sa 1. Mai 2021, 10:03

oder geht's dir um Unittests?
https://de.wikipedia.org/wiki/Modultest
in Java hatten wir Junit verwendet.
Das war dann da rein programmiert, lief automatisch nachts durch und hat ne email mit dem Ergebnis verschickt. :roll:
Bis das sich lohnt, im Vergleich zu, einige Testfälle manuell durchzuführen?

Benutzeravatar
ferdimh
Beiträge: 8068
Registriert: Fr 16. Aug 2013, 15:19

Re: Softwaretests für Testsoftware

Beitrag von ferdimh » Sa 1. Mai 2021, 10:19

Die gute Nachricht ist: Drohnenflugprobleme sind linear, und die ganze Drohne kann als ein Klotz betrachtet werden.

Das Problem dürfte hier nicht sein, die Tests durchzuführen, sondern Testfälle zu generieren.
Das ist hier keine Datenverwurstungsmaschine, die sich einfach testen lässt, sondern ein Nachbau eines analogen Systems, das sich auch analog verhält.

Mein Vorschlag für einen Test, wäre eine billige bekannt funktionierende Drohnensteuerung dranzurödeln und zu gucken, ob das Ganze "fliegt".
Dann wird kein grober Fehler drin sein. Fehler in Details sind viel unwahrscheinlicher als grober Unfug. Was bleibt, ist die leider oft gesehene Methode, im Rahmen einer Kopftisch-Kurzschluß-Aktion den Unfug an der falschen Stelle zu erkennen und ungefähr zu kompensieren. Dann bleibt ein kleiner Restfehler zurück, der viel schwieriger zu finden ist. DA kann einem aber nur das Gewissen helfen.

Die Alternative wäre, noch jemanden das Gleiche programmieren zu lassen und zu gucken, ob das gleiche rauskommt. So wird das wohl bei "ernsthafter" Technik gemacht.

lüsterklemme2000
Beiträge: 231
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Softwaretests für Testsoftware

Beitrag von lüsterklemme2000 » Sa 1. Mai 2021, 10:20

@ chris: Moment, bevor wir aneinander vorbeireden hier mal ein beispiel für eine Winkelkomponente im Koordinatensystem der Drohne:

angleAccAlpha = torque3 / (armLength * armLength * motorweight * 4 + 1 / 12 * controlweight * (controlweightwidth * controlweightwidth * 2));
alpha_vel += angleAccAlpha * calculationtime;
alpha += alpha_vel * calculationtime;

Die Matrix und Vektorrechnung kommt aus der Mechanik und vom Umrechnen des Drohnenkoordinatensystems zu einem absoluten Bezugssystem in welchem die translatorischen Geschwindigkeiten errechnet werden. FEM wäre hier ja so gesehen auch nicht wirklich notwendig, da man das ja hier iterativ mit einer linearen Ansatz annähern kann, wäre zumindest unser Ansatz.

Flip
Beiträge: 472
Registriert: Mi 14. Aug 2013, 12:04

Re: Softwaretests für Testsoftware

Beitrag von Flip » Sa 1. Mai 2021, 10:38

Für das (eigene) verständnis und lesbarkeit hilft es schon sehr, die Rechenschritte aufzuteilen. Um performance dreht es sich hier ja nicht, und so bekommen dann die konstanten erstmal einen Namen, und Teilrechnungen lassen sich erschließen, bevor alles zusammenverwurstet wird. Eine erprobte software zum test des testalgo zu nehmen, wäre auch mein bevorzugter Ansatz.

Benutzeravatar
ferrum
Beiträge: 135
Registriert: Mi 23. Jul 2014, 11:58
Wohnort: Bayern

Re: Softwaretests für Testsoftware

Beitrag von ferrum » Sa 1. Mai 2021, 10:39

Du frickelst dir gemeinsam mit der Hardware von der Drohne eine Differentialgleichung(-system) wenn ich es richtig verstehe. Das halt immer schrittweise ausgewertet wird(ähnlich wie die euler methode)?

Praktisch wäre es eine analytische Lösung für einige Szenarien zu haben und das mit dem was der Teststand tut zu vergleichen. Das verifiziert dir zwar nicht dein Modell selber aber zumindestens die Implementierung. Das Modell selber final zu verifizieren geht nur durch Messung also im real life ausprobieren, aber eine analytische Erwartung zu haben bringt trotzdem auch für das Modell einiges an Sicherheit wenn die mit der Intuition übereinstimmt.

Du muss glaub ich auch aufpassen dass dir das nicht numerisch instabil wird der code riecht irgendwie ziemlich danach. Such mal nach Explizites Euler Verfahren das müsste so ziemlich an den selben Fallstricken leiden wie das was du vor hast.
lüsterklemme2000 hat geschrieben:
Sa 1. Mai 2021, 10:20
alpha_vel += angleAccAlpha * calculationtime;
alpha += alpha_vel * calculationtime;
Das Modell selber würde mich ehrlich gesagt interessieren. Auf jeden fall eine nice idee!!!

lg ferrum

lüsterklemme2000
Beiträge: 231
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Softwaretests für Testsoftware

Beitrag von lüsterklemme2000 » Sa 1. Mai 2021, 10:44

Das ist hier keine Datenverwurstungsmaschine, die sich einfach testen lässt, sondern ein Nachbau eines analogen Systems, das sich auch analog verhält
Und das ganze ist sogar wenn man die Simulationszeit zu hoch ansetzt, bzw. der künstliche Horizont zu lange zum aktualisieren braucht, schwingfähig....

@ferdimh: Kennst du eine dementsprechende simple Software/Steuerung die man auch noch etwas umschreiben kann, sodass man sich spart auch noch das Bus-Interface von irgendwelchen Sensoren nachzubauen? Ansonsten hätte ich vermutlich mal ArduPilot ausprobiert, aber vielleicht gibt es da ja noch etwas einfacheres.

@Flip: Da gebe ich Dir Recht bzgl. Kleinschrittigkeit. Ich rechne solche Sachen wie hier aber sowieso immer erstmal auf Papier vor und verwurste das dann in Software, sonst wird mir das auch zu unübersichtlich.

lüsterklemme2000
Beiträge: 231
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Softwaretests für Testsoftware

Beitrag von lüsterklemme2000 » Sa 1. Mai 2021, 11:02

Absolut korrekt, ferrum. Die Stabilitätsgrenze des ganzen habe ich wie gesagt auch schon herausgefunden, als ich der Meinung war man braucht noch schöne Animationen für die Software, sodass die Durchläufe zu lange gedauert haben und das ganze instabil wurde. Das Modell selber..... naja ich hab Dir mal ein PDF angehängt wo ich das hergeleitet habe, ordentlich geht aber anders und es ist auch großteils nur die eigentliche Berechnung der ganzen Kraftvektoren. Aber von da aus geht man dann einfach wie weiter oben gezeigt vor und summiert das ganze Zeug auf.
Dateianhänge
Drohne.pdf
(1.22 MiB) 21-mal heruntergeladen

Benutzeravatar
Fritzler
Beiträge: 10145
Registriert: So 11. Aug 2013, 19:42
Wohnort: D:/Berlin/Adlershof/Technologiepark
Kontaktdaten:

Re: Softwaretests für Testsoftware

Beitrag von Fritzler » Sa 1. Mai 2021, 11:10

lüsterklemme2000 hat geschrieben:
Sa 1. Mai 2021, 10:20
angleAccAlpha = torque3 / (armLength * armLength * motorweight * 4 + 1 / 12 * controlweight * (controlweightwidth * controlweightwidth * 2));
Hier können schon Fehler entstehen: 1/12*x.
Was ist gewollt und was macht der Compiler draus?
Solche Rechnungen aufteilen oder so richtig den Klammerbeutel drüber aussschütten.
Flip hat geschrieben:
Sa 1. Mai 2021, 10:38
Für das (eigene) verständnis und lesbarkeit hilft es schon sehr, die Rechenschritte aufzuteilen. Um performance dreht es sich hier ja nicht
Der Compiler muss das doch eh in einzelne Rechenschritte aufteilen, daher ist es nichtmal ein Performanceverlust.

lüsterklemme2000
Beiträge: 231
Registriert: So 28. Aug 2016, 20:31
Wohnort: Südliches Niedersachsen

Re: Softwaretests für Testsoftware

Beitrag von lüsterklemme2000 » Sa 1. Mai 2021, 11:24

Also gewollt ist:
(1 / 12) * controlweight * (controlweightheight * controlweightheight + controlweightwidth * controlweightwidth)
Das hat der Compiler auch vorher schon so gemacht. Ich hätte jetzt auch erwartet, dass wenn nur noch * und / vorhanden sind der Compiler dann von links nach rechts da durch geht. Ist dem nicht immer so?
Klammern setzen ist aber natürlich generell sinnvoller als auf den Compiler zu hoffen, wird geändert, danke.

Antworten