... | ... | @@ -13,10 +13,10 @@ The different parameters in the launch of a model rocket shall be verified using |
|
|
|
|
|
# Project goals
|
|
|
|
|
|
- [ ] Develop and build a rocket motor test stand
|
|
|
- [ ] Verify the thrust curves of standard 18 mm motors
|
|
|
- [ ] Build and simulate a 35 mm model rocket to verify flight curves
|
|
|
- [ ] Use altimeter to verify simulation data in real flights
|
|
|
- [x] Develop and build a rocket motor test stand
|
|
|
- [x] Verify the thrust curves of standard 18 mm motors
|
|
|
- [x] Build and simulate a 35 mm model rocket to verify flight curves
|
|
|
- [x] Use altimeter to verify simulation data in real flights
|
|
|
|
|
|
Ideally a team of 3 students shall work on this project.
|
|
|
|
... | ... | @@ -71,104 +71,6 @@ The sensor platform that was developed in [previous projects](2023%20Altimeter%2 |
|
|
|
|
|
# Report (authors: @stcomosc, @istpankwa, @stronjin)
|
|
|
|
|
|
## Einführung
|
|
|
|
|
|
Insgesamt sind im Rahmen dieses Projekts Messsungen an folgenden Motoren der Firma Klima durchgeführt worden:
|
|
|
|
|
|
- B4-4: 11 Messungen
|
|
|
- C6-5: 12 Messungen
|
|
|
- D9-7: 2 Messungen
|
|
|
|
|
|
## Anleitung (author: @stcomosc)
|
|
|
|
|
|
### Webapp
|
|
|
|
|
|
{width="777" height="303"}
|
|
|
|
|
|
**Nullen**
|
|
|
|
|
|
Nach ungefähr zehn Sekunden ist der Moving Average Filter in der Webapp mit Werten gefüllt und man kann auf "TARE" klicken. Der aktuelle Filterwert wird unten in das Feld "offset" übernommen und kann mit "set values" an die Steuerung übertragen werden. Dieser Wert bleibt bis zum nächsten Hochfahren des Microcontroller bestehen.
|
|
|
|
|
|
**Kalibrieren**
|
|
|
|
|
|
Der Standardwert des Kalibrierfaktors ist speizifisch für unsere Kombination aus Messverstärker und Wägezelle. Wenn jedoch eine andere Kombination benutzt wird, muss ein neuer Faktor bestimmt werden:
|
|
|
|
|
|
{width="146" height="303"}
|
|
|
|
|
|
1. Auflegen des ersten bekannten Gewichts
|
|
|
2. Eintragen des bekannten Gewichts in gramm im ersten Feld ("weight 1 \[g\]")
|
|
|
3. 10 Sekunden warten
|
|
|
4. Auf den "set" Button neben dem Feld klicken
|
|
|
5. Für ein zweites Gewicht die Schritte 1. bis 4. entsprechend wiederholen
|
|
|
6. Der nun angezeigte Wert unter den beiden Feldern kann in das Feld "factor \[raw to N\]" eingetragen werden
|
|
|
7. Mit "set values" wird der Wert an die Steuerung übertragen
|
|
|
|
|
|
Für eine spätere Verwendung des Wertes bietet es sich an diesen zu notieren
|
|
|
|
|
|
**Parameter einer Messung einstellen**
|
|
|
|
|
|
Im ersten Feld wird der Dateiname eingtragen
|
|
|
|
|
|
Das erste Drop-Down-Menü beinhaltet eine Auswahl an Motoren und eine letzte Option "other", wenn der Motor auf dem Prüfstand nicht aufgelistet ist.
|
|
|
|
|
|
Im darunter liegenden Auswahlfeld wird die Richtung, in der der Motor feuert ausgewählt. Da unser Prüfstand hauptsächlich zur Seite feuert, ist das auch der Standardwert.
|
|
|
|
|
|
Falls einem nach mehr prosa zu Mute ist, kann man untersten Feld einen Kommentar schreiben. Hauptsächlich ist es für den Fall gedacht, wenn keines der aufgelisteten Motortypen auf den im Prüfstand Eingespannten zutrifft.
|
|
|
|
|
|
"reset values" setzt alle Felder auf die Werte der Steuerung zurück
|
|
|
|
|
|
"save" überträgt die eingetragenen Werte auf die Steuerung
|
|
|
|
|
|
**Starten/Stoppen von Messungen**
|
|
|
|
|
|
Zum Starten einer Messung müssen folgende Dinge erfüllt sein, dass der "start" Button aktiviert ist:
|
|
|
|
|
|
1. Eine SD Karte ist eingelegt
|
|
|
2. Der Haken neben "armed" ist gesetzt
|
|
|
|
|
|
Während einer Messung wir oben rechts in der Leiste anstatt "idle", "measuring" angezeigt. Außerdem sind die alle Buttons auf der "Home"-Seite deaktiviert.
|
|
|
|
|
|
Zum Stoppen der Messung muss der "stop" Button gedrückt werden. Dieser tritt an die selbe Stelle wie der "start" Button. Im Anschluss sind die aufgenommenen Daten auf der "Data"-Seite einsehbar.
|
|
|
|
|
|
**Daten auf der SD-Karte**
|
|
|
|
|
|
Es wird eine Liste aller verfügbaren Dateien im "/measure" Unterordner der SD Karte angezeigt. Die Liste wird auf Basis der vorhanden .json Dateien erstellt und berücksichtigt nicht, ob eine csv Datei vorhanden ist.\
|
|
|
In jeder Zeile steht ein Button "view" zur Verfügung, der eine Vorschau der aufgenommenen Messdaten ermöglicht. Da es vorkommen kann, dass man den Raketenmotor in negativer Kraftrichtung eingespannt hat, steht auch ein Button "invert" zum invertieren der Werte zur Verfügung. Der maximale Wert der Messung wird auch errechnet und dargestellt. Als letzes steht auch noch ein Button zum herunterladen der Daten zur Verfügung.\
|
|
|
Die CSV Datei hat folgendes Format:
|
|
|
|
|
|
```csv
|
|
|
time [ms], force [N], raw values from HX711
|
|
|
```
|
|
|
|
|
|
**Info-Panel**
|
|
|
|
|
|
{width="111" height="232"}
|
|
|
|
|
|
Über den blauen Button mit "i" in der obersten Leiste kann das Info-Panel geöffnet werden.\
|
|
|
Hier kann man die Verbindung zur Steuerung erneut herstellen ("reconnect" Button) oder mit "reset" den Microcontroller neu starten.
|
|
|
|
|
|
### Messungen
|
|
|
|
|
|
Vor jeder Messreihe:
|
|
|
|
|
|
1. Prüfstand möglichst eben auf feuerfestem Untergrund platzieren
|
|
|
2. In Schubrichtung und Gegenrichtung darf sich kein brennbares Material befinden
|
|
|
3. Gegen Verrutschen und Umkippen sichern
|
|
|
4. Wägezelle kalibrieren und nullen
|
|
|
|
|
|
Ablauf einer Messung:
|
|
|
|
|
|
1. Motor in Spannvorrichtung befestigen
|
|
|
2. In Schubrichtung prüfen, ob er sicher eingespannt ist
|
|
|
3. Einzigartigen Dateinamen in Webapp vergeben und Motor-Typ eintragen
|
|
|
4. "Save" clicken
|
|
|
5. Zündschnur vorbereiten
|
|
|
6. Umgebung prüfen
|
|
|
7. Messung starten
|
|
|
8. Anzünden
|
|
|
9. Nach ausbrennen: Messung stoppen
|
|
|
10. Motor vorsichtig (kann heiß sein!) aus Spannvorrichtung entfernen
|
|
|
|
|
|
## Meilensteine
|
|
|
|
|
|
- %"Proof of Concept":
|
... | ... | @@ -339,11 +241,7 @@ UI: |
|
|
|
|
|
**Entscheidung fällt auf 3**. Da für das UI sowohl einfache Bedienmethoden über Buttons (low level Backup oder Schnellzugriff) als auch komplexere Anforderungen erfüllt werden müssen, fiel die Wahl auf eine Kombination aus Buttons, LEDs, einem kleinen Display und einer Webapp.
|
|
|
|
|
|
Die Funktion der **Buttons** wäre, dass man zB in einem Experiment den nächsten Schritt auswählt oder ein Experiment abbricht. Diese Buttons weden direkt am Prüfstand angebracht und sind vom Versuchsleiter/Bediener gut zu erreichen. In Kombination mit den **LEDs** und einem **kleinen Display** lässt sich auf einen Blick direkt der Zustand des Prüftstands erkennen. Die **Webapp** bietet die selben Interaktionsmöglichkeiten mit einem erweitertem Funktionsumfang: z.B. zum Erstellen eines Experiments, Verwalten der Kalibrierdaten oder Abrufen vergangener Versuche. Die Idee ist, dass man in der Webapp aus veschiedenen vorprogrammierten Experiment-Bausteinen ein Experiment aufbaut, welches dann gefahren werden kann auf dem Prüfstand. Die Webapp interagiert mit dem microcontroller über eine API, deren Umsetzung weiter unten erläutert wird:
|
|
|
|
|
|
Aus den definierten Anforderungen und dem angestrebten Design der Software ergab sich folgender Aufbau:
|
|
|
|
|
|

|
|
|
Die Funktion der **Buttons** wäre, dass man zB in einem Experiment den nächsten Schritt auswählt oder ein Experiment abbricht. Diese Buttons weden direkt am Prüfstand angebracht und sind vom Versuchsleiter/Bediener gut zu erreichen. In Kombination mit den **LEDs** und einem **kleinen Display** lässt sich auf einen Blick direkt der Zustand des Prüftstands erkennen. Die **Webapp** bietet die selben Interaktionsmöglichkeiten mit einem erweitertem Funktionsumfang: z.B. zum Erstellen eines Experiments, Verwalten der Kalibrierdaten oder Abrufen vergangener Versuche. Die Idee ist, dass man in der Webapp aus veschiedenen vorprogrammierten Experiment-Bausteinen ein Experiment aufbaut, welches dann gefahren werden kann auf dem Prüfstand. Die Webapp interagiert mit dem microcontroller über eine API, deren Umsetzung weiter unten erläutert wird.
|
|
|
|
|
|
### Proof of Concept
|
|
|
|
... | ... | @@ -370,6 +268,97 @@ Das Design der Software in Kombination mit dem des Prüfstands hat es uns ermög |
|
|
|
|
|
Zwischen der vorher beschrieben Messreihe und dem Launch Day wurden nur wenige Änderungen vorgenommen. Die Buttons auf der Webapp waren zu klein und wurden größer gemacht und eine Routine hinzugefügt, welche ein Starten der Messung verhindert, wenn keine SD-Karte eingelegt ist.
|
|
|
|
|
|
|
|
|
### Anleitung (author: @stcomosc)
|
|
|
|
|
|
#### Webapp
|
|
|
|
|
|
{width="777" height="303"}
|
|
|
|
|
|
**Nullen**
|
|
|
|
|
|
Nach ungefähr zehn Sekunden ist der Moving Average Filter in der Webapp mit Werten gefüllt und man kann auf "TARE" klicken. Der aktuelle Filterwert wird unten in das Feld "offset" übernommen und kann mit "set values" an die Steuerung übertragen werden. Dieser Wert bleibt bis zum nächsten Hochfahren des Microcontroller bestehen.
|
|
|
|
|
|
**Kalibrieren**
|
|
|
|
|
|
Der Standardwert des Kalibrierfaktors ist speizifisch für unsere Kombination aus Messverstärker und Wägezelle. Wenn jedoch eine andere Kombination benutzt wird, muss ein neuer Faktor bestimmt werden:
|
|
|
|
|
|
{width="146" height="303"}
|
|
|
|
|
|
1. Auflegen des ersten bekannten Gewichts
|
|
|
2. Eintragen des bekannten Gewichts in gramm im ersten Feld ("weight 1 \[g\]")
|
|
|
3. 10 Sekunden warten
|
|
|
4. Auf den "set" Button neben dem Feld klicken
|
|
|
5. Für ein zweites Gewicht die Schritte 1. bis 4. entsprechend wiederholen
|
|
|
6. Der nun angezeigte Wert unter den beiden Feldern kann in das Feld "factor \[raw to N\]" eingetragen werden
|
|
|
7. Mit "set values" wird der Wert an die Steuerung übertragen
|
|
|
|
|
|
Für eine spätere Verwendung des Wertes bietet es sich an diesen zu notieren
|
|
|
|
|
|
**Parameter einer Messung einstellen**
|
|
|
|
|
|
Im ersten Feld wird der Dateiname eingtragen
|
|
|
|
|
|
Das erste Drop-Down-Menü beinhaltet eine Auswahl an Motoren und eine letzte Option "other", wenn der Motor auf dem Prüfstand nicht aufgelistet ist.
|
|
|
|
|
|
Im darunter liegenden Auswahlfeld wird die Richtung, in der der Motor feuert ausgewählt. Da unser Prüfstand hauptsächlich zur Seite feuert, ist das auch der Standardwert.
|
|
|
|
|
|
Falls einem nach mehr prosa zu Mute ist, kann man untersten Feld einen Kommentar schreiben. Hauptsächlich ist es für den Fall gedacht, wenn keines der aufgelisteten Motortypen auf den im Prüfstand Eingespannten zutrifft.
|
|
|
|
|
|
"reset values" setzt alle Felder auf die Werte der Steuerung zurück
|
|
|
|
|
|
"save" überträgt die eingetragenen Werte auf die Steuerung
|
|
|
|
|
|
**Starten/Stoppen von Messungen**
|
|
|
|
|
|
Zum Starten einer Messung müssen folgende Dinge erfüllt sein, dass der "start" Button aktiviert ist:
|
|
|
|
|
|
1. Eine SD Karte ist eingelegt
|
|
|
2. Der Haken neben "armed" ist gesetzt
|
|
|
|
|
|
Während einer Messung wir oben rechts in der Leiste anstatt "idle", "measuring" angezeigt. Außerdem sind die alle Buttons auf der "Home"-Seite deaktiviert.
|
|
|
|
|
|
Zum Stoppen der Messung muss der "stop" Button gedrückt werden. Dieser tritt an die selbe Stelle wie der "start" Button. Im Anschluss sind die aufgenommenen Daten auf der "Data"-Seite einsehbar.
|
|
|
|
|
|
**Daten auf der SD-Karte**
|
|
|
|
|
|
Es wird eine Liste aller verfügbaren Dateien im "/measure" Unterordner der SD Karte angezeigt. Die Liste wird auf Basis der vorhanden .json Dateien erstellt und berücksichtigt nicht, ob eine csv Datei vorhanden ist.\
|
|
|
In jeder Zeile steht ein Button "view" zur Verfügung, der eine Vorschau der aufgenommenen Messdaten ermöglicht. Da es vorkommen kann, dass man den Raketenmotor in negativer Kraftrichtung eingespannt hat, steht auch ein Button "invert" zum invertieren der Werte zur Verfügung. Der maximale Wert der Messung wird auch errechnet und dargestellt. Als letzes steht auch noch ein Button zum herunterladen der Daten zur Verfügung.\
|
|
|
Die CSV Datei hat folgendes Format:
|
|
|
|
|
|
```csv
|
|
|
time [ms], force [N], raw values from HX711
|
|
|
```
|
|
|
|
|
|
**Info-Panel**
|
|
|
|
|
|
{width="111" height="232"}
|
|
|
|
|
|
Über den blauen Button mit "i" in der obersten Leiste kann das Info-Panel geöffnet werden.\
|
|
|
Hier kann man die Verbindung zur Steuerung erneut herstellen ("reconnect" Button) oder mit "reset" den Microcontroller neu starten.
|
|
|
|
|
|
#### Messungen
|
|
|
|
|
|
Vor jeder Messreihe:
|
|
|
|
|
|
1. Prüfstand möglichst eben auf feuerfestem Untergrund platzieren
|
|
|
2. In Schubrichtung und Gegenrichtung darf sich kein brennbares Material befinden
|
|
|
3. Gegen Verrutschen und Umkippen sichern
|
|
|
4. Wägezelle kalibrieren und nullen
|
|
|
|
|
|
Ablauf einer Messung:
|
|
|
|
|
|
1. Motor in Spannvorrichtung befestigen
|
|
|
2. In Schubrichtung prüfen, ob er sicher eingespannt ist
|
|
|
3. Einzigartigen Dateinamen in Webapp vergeben und Motor-Typ eintragen
|
|
|
4. "Save" clicken
|
|
|
5. Zündschnur vorbereiten
|
|
|
6. Umgebung prüfen
|
|
|
7. Messung starten
|
|
|
8. Anzünden
|
|
|
9. Nach ausbrennen: Messung stoppen
|
|
|
10. Motor vorsichtig (kann heiß sein!) aus Spannvorrichtung entfernen
|
|
|
|
|
|
### API
|
|
|
|
|
|
Aufgabe der API ist es, eine definierte Schnittstelle zwischen der Steuerung und einem Client (z.B. Webapp) zur Verfügung zu stellen. Die API ist so aufgebaut, dass sie über HTTP-Requests angesprochen wird und JSON-Daten aufnimmt und oder zurückgibt. Hier ein kurzer Überblick über die Endpunkte der API:
|
... | ... | @@ -569,6 +558,19 @@ Die folgenden Grafiken und Tabellen wurden aus den Daten unter **RocketMotorTest |
|
|
|
|
|
{width="473" height="284"}
|
|
|
|
|
|
Bei den B4-Motoren wurde eine Messung ausgeschlossen, da sie sich sehr stark vom Rest unterschied. Den Grund für diese Abweichung konnten wir uns nicht erklären. Der Brennvorgag war vergleichbar zu den anderen und unterschied sich nur in einem Punkt, dass wir eine höhere Temperatur beim Entnehmen festgestellt haben.
|
|
|
|
|
|
``insert plot``
|
|
|
|
|
|
Scheinbar gibt es Bedingungen beim Abbrennen des Treibsatzes, die für mehr Temeperatur und eine längere, ungleichhmäßige (stotternde) Verbrennung sorgen.
|
|
|
|
|
|
Im Vergleich der gemessenen Verläufe zu den jeweiligen Referenzen, fällt der B4-Motor als erstes auf. Hier kann man einen großen Unterschied feststellen. Jedoch wird man feststellen, dass sich gelieferte Impuls (siehe weiter unten) nicht groß unterscheidet. Der steilere Anstieg am Anfang ist sogar von Vorteil, da am Anfang viel effizienter beschleunigt werden kann. Bei geringerer Geschwindigkeit ist der Luftwiderstand noch gering und so kann der verbrannte Treibstoff effizienter in Bewegung umgesetzt werden. Zu Erkennen ist das in den Simulationen (weiter unten) an der höheren Geschwindigkeit beim Verlassen der Rampe.
|
|
|
Scheinbar hat der Hersteller Parameter der Motoren geändert, ohne sie auf dem Datenblatt zu aktualisieren. An dieser Stelle wäre es interssant, dies vom Hersteller bewerten zu lassen. Eine solche Anfrage wird im Anschluss an dieses Projekt erfolgen und an dieser Stelle dokumentiert.
|
|
|
|
|
|
Die von uns aufgezeichneten Verläufe der C6-Motoren sind vergleichbar zum Datenblatt. Jedoch liegt ein großer Teil der Werte unterhalb der Referenz.
|
|
|
|
|
|
Da uns nur eine begrenzte Anzahl an D9-Motoren zur Verfügung stand, hatten wir nur insgesamt zwei von diesem Typ auf dem Prüfstand. Außerdem haben wir die Vermutung, dass das Holz in Kombination mit unserer Spannvorrichtung nicht genug Klemmkraft aufbringen kann. Wenn der Motor also in der Vorrichtung rutschen kann, dämpft das die gemessene Kraft. Wegen dieser beiden Gründe, haben wir uns dafür entschieden die Messdaten des D9 nicht in die Bewertung mit einzubeziehen. Der Vollständigkeit halber sind die Daten des D9 mit aufgelistet, da sie die Grenze unseres Prüfstands aufzeigen. Mit einer Gummierung ließe sich das Problem wahrscheinlich beheben.
|
|
|
|
|
|
### Liste aller verwendeten Daten
|
|
|
|
|
|
#### B4-4
|
... | ... | @@ -1047,3 +1049,30 @@ ejection \[ms\] |
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
### Scatter Plot zur Untersuchung der Streuung
|
|
|
|
|
|
In den folgenden drei Plots sieht man die Brenndauer aufgetragen in Relation zum jeweiligen gelieferten Impuls. Der Impuls hat sich als gutes Maß herausgestellt, um das Potential eines Motors zu beurteilen.
|
|
|
|
|
|
``instert plots``
|
|
|
|
|
|
Nur ein B4-Motor übertrifft die Herstellerangaben. Bei jedem anderen lagen sie entweder nur knapp darunter (B4) oder sogar eine Ns unterhalb der Referenz. Die D9-Motoren wurden, wie bereits weiter oben erklärt, ausgeschlossen aus der Auswertung.
|
|
|
|
|
|
### Simulation (post LaunchDay)
|
|
|
|
|
|
Nachdem wir am LaunchDay 2024 das erste Mal Modellrakten gebaut und starten lassen haben, wurde eines der Raketen in OpenRocket nachgbaut. Das Modell einer 35mm Rakete vom Typ "Quick and Easy MAXI" des Herstellers Klima wurde so gut wie möglich nachgebaut (QaE-MAXI_4xForm5.ork). Verglichen wurden die Motoren aus der Openrocket-Datenbank und den aus unseren Messdaten erstellten ".eng"-Dateien. Diese Konvertierung übernimmt übrigens auch das Skript "analyzer.py".
|
|
|
|
|
|
In der folgenden Tabelle ist eine Gegenüberstellung der Referenz-Motoren mit unserem jeweils besten und schlechtesten Motor. Als Kriterium zur Bewertung wurde die maximale Höhe der Rakete herangezogen. Es liegt nahe, dass ein Motor, der mehr Schub liefert, die Rakete höher steigen lässt. Und der Schub über die Zeit ist der Impuls.
|
|
|
|
|
|
``insert table``
|
|
|
|
|
|
Alle aus den Daten gewonnen Erkenntnisse, bestätigen sich in der Simulation. Sie soll in Kombination mit den zwei auf dem LaunchDay gemessenen Höhen nur noch einmal das vorherige Ergebnis untermauern. Man sieht, dass die realen B4-Motoren in der ersten Phase des Fluges schneller beschleunigen und so früh eine höhere Geschwindigkeit erreichen. Die von uns vermessenen C6-Motoren schließen schlechter als die Referenz ab (20m weniger Höhe). Jedoch liegt der Referenzmotor näher an der realen gemessenen Höhe von 209m. Eine Höhenmesung einer Rakete mit verbautem B4-Motor lieferte hingegegn 92m Apogäum. Dies entspräche unserer Simulation mit dem besten gemssenen Motor.
|
|
|
|
|
|
Man kann gut erkennen, dass sich die Realität mit einer Simulation nur begrenzt darstellen lässt. Sensitivitäten und eine ungefähre Abschätzung über den Flugverlauf (siehe Modell der Ariane 6) können jedoch gut untersucht werden.
|
|
|
|
|
|
Die Erkenntnisse aus dem Prüfstand lassen sich unsere Meinung nach jedoch schwer einordnen. Der fehlende Einblick in die innere Funktion, Produktion des Motors sowie seiner Auswirkungen auf den gelieferten Schub, lassen uns nur spekulieren.
|
|
|
|
|
|
## Ausblick
|
|
|
|
|
|
Die Messungen und Simulationen haben gezeigt, dass die gemessenen Werte von den Referenzwerten abweichen. Jedoch ließen sich die genauen Ursachen schwer ausmachen, weshalb zum Beispiel eine Untersuchung des Gewichts vor und nach der Feuerung denkbar wäre. Die vorhanden Wäägezelen können ohne Probleme als weterer Sensor integriert werden. Für diese Untersuchung sind verschlossene (plugged) Motoren notwendig, da die Ausstoßladung sonst die Messung verfälscht. Oder man macht Messungen mit einem Motor, der so eingespannt ist, dass die Wäägezelle das Gewicht des Motors aufnimmt. Auch eine Kombination aus gleichzeitiger Schub- und Gewichtsmessung wäre denkbar. Eventuell bestünde in der Zukunft auch Interesse daran zu untersuchen, wie der Schub sich in alle Raumrichtungen verteilt. Bereits vorbereitet wurde die Messung eines Clusters aus drei Motoren. An dieser Stelle wäre es interessant zu untersuchen, ob die Motoren gleichzeitig zünden und ob sie gleichmäßig abbrennen. Das selbe ließe sich auch untersuchen, wenn am Prüfstand eine elektronische Zündeinrichtung verbaut würde.
|
|
|
Auf jeden Fall sollte eine Anfrage an den Hersteller gestellt werden, um die Abweichungen zu klären. Außerdem muss für eine Messung stärekerer Motoren (z.B. D9) die Spannvorrichtung verbessert werden.
|
|
|
|