CableCam mit BL-Gimbal

Jogijo · Dez 27, 2013

Ich melde mich hier nur kurz um zu sagen das ich nicht verschwunden bin, ich bin noch da und willig, habe aber im Moment noch weniger zeit als befürchtet.
@yang
Nicht locker lassen, auch wenn sich lange keiner meldet, ich bin sicher es lesen noch einige mit. Ich habe mir auch ernsthaft überlegt ob ich mich nicht doch im coden versuchen soll, aber da müsste ich wirklich fast bei Null beginnen, und wäre dir keine große Hilfe, da bist du sicher weiter als ich.
Ich glaube mein Problem ist auch das ich erst lernen müsste wie man coden lernt, ich müsste also das lernen lernen. Bei der Elektronik, beim Fräsen oder Drehen habe ich ja etwas worauf ich aufbauen kann, das fehlt mir beim coden, vielleicht habe ich ja auch darum so viel Respekt davor.

wolfes1126 · Dez 27, 2013

Sehr interessantes Thema... habe nun die ersten 31 Seiten durch und muss sagen:
TOP Design und sehr schnelle Verwirklichung/Fortschritt.
Habe mir leider die letzten 2 Seiten nicht ddurchgelesen da ich gleich auf "Tour/Arbeit" gehen muss.

Nur ein wenig Info zur Nutzung von "LKW" Spanngurten:
Da ich tagtäglich mit der Materie Spanngurt zu tun habe und wir bei verschiedenen Veranstaltungen auch immer wieder "Spanngurt/Zurrgurt-König" Wettbewerbe veranstalten, bei dem wir den "König" anhand der höchsten Spannwerte (KG gemessen) ermitteln ist folgendes zu sagen:
1. Nach dem erreichten Werten sinken die Messungen der Spannkraft innerhalb von Sekunden, da sich die Gurte (egal welche Qualität... denn wir benutzen für besagte Wettbewerbe schon aus Sicherheitstechnischen Gründen keinen "Billigschrott") sich dehnen.
2. Gespannte Gurte geben auch bei Feuchtigkeit nach geraumer Zeit in der Spannkraft nach.

Daher denke ich mal dass die "Spanngurt-Idee" eher kontraproduktive wäre, wenn das Seil bei verschiedenen Aufbauten für längere Zeit (paar Stunden oder sogar Tage) gespannt bleiben sollte, da durch die Eigenschaften der Spanngurt (oben beschrieben) ein ständiges Nachspannen nötig wäre.

Nur so als kleines Input.

Roman.C. · Dez 29, 2013

Salü
Wow, ihr habt da innert so kurzer Zeit klasse Ergebnisse geliefert (yang)
Bin fleissig alle 33 Seiten durchgegangen und jetzt will ich mir auch eins bauen.
Habe immer wieder Anfragen ich solle indoor mit meinem Copter fliegen und das noch über Menschenmassen. Sowas geht garnicht.

Motor und Regler habe ich ausgewählt. Jetzt frage ich mich für was bei den heutigen Gimbals diese teuren Gyros nötig sind?
Die Kreiselwirkung könnte preiswerter (keine 2000 Dollar) erzeugt werden, jedoch frisst das immer Strom.
Bei manchen hochpreisigen Konstruktionen sind Servogimbals drauf und dann wird so ein Gyro schon Sinn machen.

Habe ich was übersehen, oder hat Jogijo sein Cablecam noch nicht gezeigt/gebaut?

Nette Grüsse
Roman

yang · Dez 29, 2013

Ich weiß auch nicht warum man Gyros heute noch verwendet. Ich vermute einfach das vor ein paar Monaten noch keine Brushless Gimbals verfügbar waren, die auch mit größeren Kameras umgehen können. Selbst heute sind die Gimbals für DSLRs mit 3 Achsen recht teuer. Ich sehe keinen Grund mehr mit Gyros zu arbeiten. Zumindest nicht wenn man von GoPro bis DSLR Größe spricht.

Jogi hat alle Bauteile bei sich, aber aktuell keine Zeit.

Roman.C. · Dez 29, 2013

Ich fange mal ohne an und falls es dann irgendwann doch notwendig würde, kann man immer noch nachrüsten.
Aber das wären pro Stück 2000 Dollar und dies schmerzt.

yang · Dez 29, 2013

Jogijo hat gesagt.:

Microcontroller sind doof.

Nimm mal dieses Codebeispiel von der Initialisierung der PWM Module aus der MultiWii

TCCR1A |= (1<<WGM11); // phase correct mode & no prescaler
TCCR1A &= ~(1<<WGM10);
TCCR1B &= ~(1<<WGM12) & ~(1<<CS11) & ~(1<<CS12);
TCCR1B |= (1<<WGM13) | (1<<CS10);
ICR1 |= 0x3FFF; // TOP to 16383;
TCCR1A |= _BV(COM1A1); // connect pin 9 to timer 1 channel A

Ist das schwer? Nein, ein paar Register Bits (z.B. TCCR1A) werden gesetzt und die steuern dann irgendetwas im Mikrocontroller, eben die Frequenz vom PWM Signal. Erste Schwierigkeit - woher weiß man welche Bits von welchen Registern gesetzt sein müssen? Klar, steht alles in der Doku. Als nächstes müssen mehrere Dinge zusammenpassen, etwa hier soll der Timer den Wert 16383 haben und der PreScaler ist 1, also 16'000'000Hz/16383 = 1ms PWM timing. Wenn Du den PreScaler vergisst, kommt eben die falsche Frequenz zustande und nichts geht mehr. Woher man das weiß? Klar, steht alles in der Doku.
Und zur Krönung sind die Microcontroller bzw. deren Software sehr dumm. So könntest Du z.B. feststellen: Ich habe exakt das gemacht was man für PWM braucht, trotzdem passiert nichts. Weil ich den Pin vergessen habe zu einem Output zu konfigurieren (TCCR1A), jetzt wird also ein PWM Signal intern erzeugt aber nicht auf das Pin vom Microcontroller geschalten. Na super.

Wie Du siehst ist alles sehr einfach zu programmieren, aber bis es funktioniert und Du all die kleinen, unscheinbaren Fallen gefunden hast, bist Du um etliche weiße Haare reicher.

Deswegen ist die Lernkurve bei so etwas sehr schlecht. Am Anfang kannst Du froh sein wenn er überhaupt reagiert, dann lernst Du PWM Signale zu erzeugen, dann die serielle Schnittstelle, dann Interrupts und deren Eigenheiten usw. Nach einigen Monaten intensiver Beschäftigung beherrschst Du dann alle wichtigen Module so halbwegs - für diesen einen Microcontroller.

yang · Dez 31, 2013

yang hat gesagt.:

Okay, ich bin schon recht weit, möchte aber gerne ein Problem mit euch validieren.

Ich kann jetzt den RC Empfänger auslesen, die Werte in ein Array schreiben und die Servos steuern. Soweit so gut, damit wären Punkt 1 bis 3 abgehakt.

Als nächstes die Hall Sensoren. So wie ich das verstanden habe kann ich beim Atmel32u4 ausschließlich die Pins 0,1,2,3 per Interrupt überwachen. Nur werden Pins 0&1 für den UART verwendet und Pins 2&3 für die I2C Kommunikation. Ich muss also eine der beiden Funktionalitäten opfern. Die I2C wäre blöd, denn darüber wollte ich die IMU auslesen. Davon abgesehen hat das Board da Pullup Widerstände, das geht also sowieso nicht.
Bleibt der UART, obwohl darüber wollte ich die Kommunikation mit dem WLAN Controller realisieren.

Wenn obige Aussagen stimmen dann habe ich nur die Möglichkeit den WLAN Controller per I2C zu verbinden. Das ist wiederum ungeschickt weil die NanoWii der Master für die IMU sein sollte, aber der Slave für den WLAN Controller.
Aaarrgh.

Korrekt soweit?

yang · Jan 1, 2014

Ich glaube ich habe die Antwort gefunden. Der komplette PortB kann als *ein* Interrupt verwendet werden - siehe RX.cpp in der MultiWii.

yang · Jan 1, 2014

Ha, der Teil funktioniert auch.

Jetzt ist die Basis gelegt, ich kenne den RC Input, ich kann RC Output erzeugen und ich zähle die Motorumdrehungen.
Damit kann ich in die eigentliche Logik einsteigen, also maximale Beschleunigung und Wegbegrenzung realisieren.

Roman.C. · Jan 1, 2014

Salü yang
Schön zu hören. Leider habe ich von programmieren keine Ahnung.
Gerne lese ich aber von deinen Fortschritten und kann was dabei lernen.
Meine Cabelcam soll auch mal ein Wegmess-System erhalten.

Gruss Roman und ein fröhliches neues Jahr

yang · Jan 1, 2014

PID Regler funktioniert ebenfalls, für Leerlauf ist er auch ordentlich eingestellt. Inwieweit das am Seil andere Werte verlangt, wird sich zeigen.

Die Logik habe ich jetzt einmal so realisiert:
1. Die Differenz zwischen RC Input Signal und Neutral wird zu einer Soll-Strecke integriert. Wenn ich also die Fernsteuerung für 10 Sekunden auf 1.7ms Sekunden habe, also +0.2ms über Neutral, dann möchte ich offensichtlich 30m weit fahren (oder so)
2. Der PID Regler versucht immer den aktuell gewünschten Punkt anzufahren, möglichst ohne Schwingungen. Im obigen Fall würde er also schnell Beschleunigen, und dann der Fahrgeschwindigkeit folgen.
3. Jetzt kann ich die Streckengrenzen einbauen, also wenn ich 30m weit fahren möchte aber 10m davor schon das Ende der Strecke ist, dann stoppe ich das hochzählen der Strecke.

Meine aktuelle Denkweise ist, die maximale Beschleunigung definiere ich über den I-Anteil des PID Reglers. Da brauche ich also keine zusätzliche Logik. Für die Streckenbegrenzung darf ich aber nicht das integrieren einfach hart stoppen, sondern muss da langsam verzögern. Sonst würden, wenn die CableCam gerade mit hoher Geschwindigkeit dem Soll-Punkt hinterherfährt, bei dem plötzlichen Stopp, die CableCam über den Endpunkt hinausfahren und sich dann auf den Endpunkt einschwingen. Also muss ich die maximale Bremsbeschleunigung bei der Annäherung an den Endpunkt mit berücksichtigen und den Sollpunkt immer langsamer an den Endpunkt fahren lassen.
Oder ich rechne zur aktuellen Geschwindigkeit den Bremsweg aus und sobald der über dem Endpunkt liegt, gebe ich den Enpunkt als neuen Soll-Punkt an. Das würde aber eine sehr gute Abstimmung erfordern, sonst könnte der PID Regler den neuen Sollpunkt sehen und kurz noch beschleunigen um dann mit der maximalen Verzögerung zu dem Punkt abbremsen.
Daher denke ich eher an zwei Beschleunigungswerte, einmal für den PID Kreis und einmal für das Endpunkt anfahren.

yang · Jan 2, 2014

Blöde idee. Habe gestern mehrfach versucht einen ordentlichen Algorithmus zu entwickeln - nicht hinbekommen. Immer wieder Schwingungen im Gesamtsystem.
Die bessere Idee ist den Sollwert nicht direkt von der Fernsteuerung abzugreifen sondern hier mit Filtern einzugreifen: Aktuelle Geschwindigkeit ist 5m/s, Sollgeschwindigkeit lt Fernsteuerung ist 8m/s aber die maximale Beschleunigung ist 1m/s, also ist der neue Sollwert für den Regler 6m/s. (Korrekt wäre es nicht pro Sekunde sondern pro 0.02s Taktung).

Bin gerade dabei das zu realisieren....

yang · Jan 2, 2014

Ich habe jetzt eine wunderschöne Regelung. Ich gebe aus dem Stand Vollgas, der Motor beschleunigt langsam und gleichmäßig bis zum Maximum, bleibt dort und später, während ich weiter auf Vollgas bin, beginnt der Motor gleichmäßig wieder langsamer zu werden, bis er exakt am definierten Endpunkt zum Ruhen kommt.
Die Ist-Wert Regelung überschießt den Endpunkt mit maximal 8 Motorschritten, das ist knapp über eine Umdrehung des Antriebsrads. Der d-Wert des PID Reglers ist aber auch noch sehr niedrig.

Wichtig war in der Programmierung keinen Wert aus den Ist-Variablen zu nehmen, denn sonst erzeuge ich ja einen neuen Reglertyp. z.B. ist die Ist-Geschwindigkeit für's Bremsen uninteressant. Man verwendet die Soll-Geschwindigkeit, die Aufgabe des PID Reglers ist diesen Soll-Wert schön zu erreichen. Als ich die Ist-Geschwindigkeit und Ist-Position verwendet hatte, kam es immer zu Schwingungen. Ist ja auch klar, damit setze ich die Soll Wert basierend auf den Ist-Werten die im Reglerkreis zum Erreichen des Soll-Werts verarbeitet werden und deswegen bekam ich eine Rückkopplung welche die Soll-Werte springen ließen.

Nachteil davon ist das die Beschleunigung kurz etwas höher ist als festgelegt, da der Soll-Wert sich um die Beschleunigung erhöht, der Ist Wert versucht diesen einzuholen und deswegen ein wenig mehr beschleunigen muss. Völlig egal, sind wenige % Punkte, mehr nicht.

Im Endeffekt habe ich damit eine echte Governer-Steuerung. Mit der Fernsteuerung gebe ich die gewünschte Geschwindigkeit an, damit erhöht sich der Soll-Punkt um diesen Geschwindigkeitsbetrag pro Takt (SollpunktT+1 = SollpunktT + Geschw*1). Der Regler versucht alles um diesen Soll-Punkt zu erreichen. Hänge ich auf einem schrägen Seil und die CableCam rollt von alleine langsam herunter, versucht der Regler diesen Punkt zu halten.

Nächster Schritt ist, nach dem Aktivieren eine erste langsame, freie Fahrt zu erlauben um die CableCam per Fernsteuerung an den Endpunkt fahren lassen und diese Position als die End-Position zu speichern.
Also beim Einschalten ist der Startpunkt 0, Endpunkt +9999999. Ich erlaube ein Fahren nur in die + Richtung und sobald die Fernsteuerung für 10 Sekunden in Neutral ist, wird das der neue Endpunkt.

Danach erfolgt die Implementierung der seriellen Schnittstelle um per WLAN Controller Werte überschreiben zu können, die PID Werte, aktuelle Position auslesen, Pan&Tilt automatisch einzustellen, Zielpunkte definieren usw.

yang · Jan 3, 2014

Nächste Hürde genommen - die serielle Schnittstelle und deren Befehle.

Ich kann über die Serielle Schnittstelle jetzt folgende Daten austauschen:
#define PROTOCOL_SET_PID 'K' // 3 float arguments for Kp, Ki, Kd
#define PROTOCOL_GET_PID 'k'
#define PROTOCOL_SET_MAX_ACCEL 'A' // 1 float argument
#define PROTOCOL_GET_MAX_ACCEL 'a'
#define PROTOCOL_SET_START_POS 'B' // 1 float argument
#define PROTOCOL_GET_START_POS 'b'
#define PROTOCOL_SET_END_POS 'E' // 1 float argument
#define PROTOCOL_GET_END_POS 'e'
#define PROTOCOL_SET_MAX_SPEED 'S' // 1 float argument
#define PROTOCOL_GET_MAX_SPEED 's'
#define PROTOCOL_SET_TARGET_POS 'T' // 1 float argument
#define PROTOCOL_GET_TARGET_POS 't'
#define PROTOCOL_SET_PITCH 'P' // 1 float argument
#define PROTOCOL_GET_PITCH 'p'
#define PROTOCOL_SET_YAW 'Y' // 1 float argument
#define PROTOCOL_GET_YAW 'y'

Wird also der Befehl "$k*00\r\n" (k...GET_PID) an die NanoWii gesendet, dann antwortet diese mit zwei Zeilen, zuerst die Werte und dann eine OK Zeile.

2.00,1.50,0.24
OK

Das $ am Zeilenanfang gibt an das es ein Befehl ist, *00 ist die Checksum und \r\n das carriage return & line feed char.

Generell gebe ich der Fernsteuerung Vorrang bei allen Inputs. Wenn ich also eine TARGET_POS mit dem Befehl "$T+900*00\r\n" absetze, dann beschleunigt der Motor mit der maximal erlaubten Beschleunigung, bis die Maximalgeschwindigkeit erreicht wurde und dann bremst er ab um den Zielpunkt genau zu treffen. Das geschieht aber nur solange die Fernsteuerung die Knüppel im neutralen Bereich hat oder überhaupt kein Empfänger angeschlossen ist.

Bei Yaw und Pitch das Gleiche. Im Code verwende ich etwa diese Logik:

if (rcData[2] != 0) {
..float diff_pitch = (float) (rcData[2] - SERVO_CENTER);
..if (diff_pitch < -NEUTRAL_RANGE) servo[1] = rcData[2]+NEUTRAL_RANGE; // Tilt or Pitch
..if (diff_pitch > +NEUTRAL_RANGE) servo[1] = rcData[2]-NEUTRAL_RANGE; // Tilt or Pitch
}

Nur wenn ich am Empfängerkanal 2 ein PWM Signal bekommen habe (rcData[2] != 0) und der Wert deutlich außerhalb von 1500us (=SERVO_CENTER) liegt, dann überschreibe ich den Wert vom RC Ausgangssignal (servo[1]). In allen anderen Fällen bleibt er gleich und kann somit über die serielle Schnittstelle direkt eingestellt werden.

Damit ist Hardware- und Softwareseitig eigentlich alles fertig in Sachen NanoWii. Jetzt kommt der WLan Controller mit dessen WebServer dran. Das habe ich aber schon oft gemacht, sollte also recht schnell erledigt sein.

Dann noch testen, testen, Fehler beseitigen, testen, beim Fehler beseitigen verursachte Fehler beseitigen, testen,..... und dann bin ich fertig.

yang · Jan 5, 2014

Eine Webseite ist fertig, bei der zweiten passt das Layout und die AJAX Kommunikation, WLAN Controller spricht mit der NanoWii usw.
User-Input auf der WebSeite zur Steuerung wird bereits an den WebServer gesendet, aktuelle Daten angezeigt und mit dieser Seite kann ich die cablecam fahren lassen.

Direkt nach dem Start ist die Weg-Untergrenze bei 0 und die Obergrenze 9999999. Deswegen ist es mir noch nicht erlaubt die Cablecam zu benutzen und die untere Hälfte des Screens (Movement) ist ausgeblendet. Wann immer ich jetzt auf "Start moving slowly" drücke, fährt die Cablecam mit einer sehr niedrigen maximalen Geschwindigkeit um 100 Motor Umdrehungen weiter. Das wiederhole ich so oft bis ich am Seilende bin, dann drücke ich den Stop Button und lege die aktuelle Position als die Weg Obergrenze fest. Gleichzeitig wird die maximale Geschwindigkeit auf den Sollwert gesetzt.

Ab jetzt kann ich mit dem GoTo Schieberegeler zwischen den Werten für die Unter (0.00) und Obergrenze (750.00) hin und her fahren, der Browser hat einen onChange Event und ruft ständig die URL move.cgi?targetpos=xyz auf, xyz ist der Wert des Schiebereglers, aktuell eben 276.00. Im Webserver wird diese URL ausgewertet und per UART das Kommando $T276.0*FF an die NanoWii geschickt und diese lässt die Cablecam sofort an diese Position fahren. Das ist natürlich bei weitem nicht so feinfühlig wie mit einer Fernsteuerung, aber dazu dient es ja auch nicht primär. Das eigentliche Ziel sind Wegprofile abzufahren, aktuell gibt es nur das automatisierte Fahren an den Anfang oder das Ende des Seils indem ich unterhalb des Reglers auf die Start- oder Endposition (0.00 oder 750.00) klicke.

Im Bereich "Current Position" werden aktuelle Werte dargestellt:
Pos: die Umdrehungen des Motors, die Ist-Position also
Target: Der Soll-Wert. Die Differenz zwischen den beiden ist was der PID Regler noch korrigieren müsste
Speed: Die aktuelle Soll-Geschwindigkeit
Throttle: Die microsekunden des PWM Signals, also hier gerade 1,479ms lange, sprich in Neutral (=1,5ms Pulsweite)

Ganz unten sieht man was am seriellen Protokoll gerade so abgeht, aktuell wurde die NanoWii nach dem Throttle Output gefragt "$o*FF" und hat geantwortet mit "$o 1479.00 OK*4e". Das $o zeigt mir zu welchem Befehl der Wert 1479.00 gehört, OK sagt das kein Fehler auftrat und *4e ist die Prüfsumme (XOR, ganz so wie beim GPS NMEA Protokoll auch).

Die nächste Seite "Settings" existiert schon, ich muss noch alle Kommandos im WebServer in NanoWii Kommandos umsetzen, also wenn diese Seite den URL move.cgi?kp=10.0 per AJAX anspricht, dann wird das serielle Kommando $1 10.0*FF abgesetzt, der Befehl 1 ist eben der Kp Wert alleine. (Ja, ich habe das Protokoll vom vorhergehenden Post erweitert)

Sobald ich die Settings per Webseite ändern kann, werde ich mal versuchen wie schön oder schlecht die Regelung am Seil funktioniert.

Jogijo · Jan 5, 2014

Wow, du gibst ja wieder Gas!
Ich bin beeindruckt!

yang · Jan 6, 2014

Übrigens, irgendwo ganz weit oben, hatte ich mal gesagt ich würde gerne den Gimbal abdrehen können, konnte aber keinen Grund nennen. Jetzt weiß ich einen: Um die Kamera oder den Kameraakku zu wechseln. Da möchte ich nicht gegen den Gimbal kämpfen und die CableCam komplett stromlos machen möchte ich für eine Minute ebenfalls nicht, denn dann rollt sie mir z.B. Hangabwärts oder ich muss die Wegbegrenzungen neu programmieren.
Auch beim Einschalten der CableCam schwingt die mitunter für einige Minuten nach, die Gimbal Ausrichtung beginnt noch während die Pendelbewegungen recht stark sind. Das könnte ich dann auch kontrollieren, obwohl ich da nicht wirklich Fehler bekommen hatte.

Jogijo · Jan 6, 2014

Ja, deine gründe kann ich nachvollziehen, ich hab damals einen einfachen Schalter vorgeschlagen.
http://fpv-community.de/showthread.php?34224-CableCam-mit-BL-Gimbal&p=468032&viewfull=1#post468032
(#285)
Das scheint mir auch heute noch die einfachste Lösung zu sein.

yang · Jan 6, 2014

Nix da, der WLAN Controller steuert über einen MSFET die Stromversorgung und bekommt auch einen Spannungsteiler um die Akku Spannung zu überwachen. Später. Viel später.

(Ich habe letzte Woche beim Testen einen 50EUR Akku auf 7V entladen und entsprechend ruiniert. So oft die Cablecam kurz getestet und trotzdem nicht auf die Idee gekommen den Akku mal wieder aufzuladen. Wozu auch, der Fahrtenregler ist sowieso auf 3,2V * 3 Zellen Mindestspannung eingestellt. Blos reagiert der erst nach 2 Minuten oder so und weil ich immer nur für ein paar Sekunden getestet hatte, kam nie eine Warnung. Mist.) Falsch, ein Balancer Pin war nicht okay, deswegen habe ich die falsche Spannung angezeigt bekommen.

Da fällt mir ein weiteres Post in diesem Thread ein, da ging es um ......... Over-Engineering

Irgendwo hatte ich das als Signatur in einem Forum gelesen:
Ich repariere alles solange ganz, bis meine Frau entscheidet, dass wir es wegen Überreparatur wegwerfen können.

Jogijo · Jan 6, 2014

yang hat gesagt.:

Oder so, ist natürlich eleganter, wobei so ein mechanischer Schalter manchmal vielleicht sogar praktischer ist, warum also nicht beides.

yang hat gesagt.:

Oje oje, ja, bei der Testerei kann man sich leicht mit dem Akku verschätzen, hatte das auch schon bei einem Copter, der ist dann bei Vollgas selbstständig gelandet, ich dachte zuerst auch das der Lipo jetzt hinüber sei, war er aber nicht obwohl die Zellenspannungen deutlich unter 3V lag, Glück gehabt. Seitdem verwende ich auch bei kurzen Tests immer einen Lipowarner (Piepser).

CableCam mit BL-Gimbal

Erfahrener Benutzer

Erfahrener Benutzer

hat zu viele Baustellen

Erfahrener Benutzer

hat zu viele Baustellen

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

hat zu viele Baustellen

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer