Baro Code Änderungen

martinez · Okt 8, 2012

Also der ACC...

Das Crius AIO hat den MPU6050 drauf. Verwendet noch jemand diesen Sensor?
Mhh, ich habe gerade mal nachgeschaut, das FreeImu 0.4.3 hat auch den MPU6050 drauf...
Ich habe noch ein kleines Board nur mit dem MPU6050 drauf und könnte die zwei QFNs in der Arbeit untereinander tauschen.
Ob das etwas bringt?

Gruß
Martinez

Scotch · Okt 8, 2012

Moin,
ich war dann auch mal kurz testen. Hab das Datenkabel vergessen darum war nur der Flug mit der Final 3 möglich.
Auch Konnte ich keine werte ändern.
Meine Subjektive Erfahrung war sehr Positiv. Geflogen bin ich mit Defaultwerten.

MultiWiiConf_2_1 by mr_sc0tch, on Flickr
Die Höhe wurde bei mir sehr genau gehalten. Beim Landen ist er mir dann aber mal durch gesackt konnte ihn aber noch abfangen. Beim Steigen ging er auch etwas Ruckartig hoch hat aber dann gleich wieder die Höhe gehalten.

Mein Quad ist ca. 800g schwer hat einen Achsabstand von ca. 40cm. Als Sensor hab ich das FreeIMU 0.3.5 MS (MPU6050 ab ich auch noch liegen aber dann hab ich kein Baro)
Ich hab mal mit dem Handy ein Video gemacht. (gar nicht so einfach, mit nur einer Hand zu Fliegen und dabei zu Filmen)
http://youtu.be/UfXDUafwVk4?hd=1

Gruß Ingo

Roberto · Okt 9, 2012

@Scotch: Herzlichen Dank für Dein Video!
Das Durchsacken lässt sich leider nicht vermeiden. Wenn Du im Höhehalten bist, wird das Gas automatisch passend angehoben. Auch eine Akkuentladung wird über einen guten Bereich kompensiert. Wenn Du jetzt noch den Stick nach unten, ausserhalb der Neutralzone (z.B 20) bewegst, dann hast Du Echtes Gas - 20 - dem bisherigen Regelungsaufschlag. Es geht nach unten. Im Fall der gewollten Abwärtsbewegung im Baromode ohne Mittensteuerung (nach Sollhöhe) ist es besser, erst nach oben Gas zu geben und die Neutralzone zu durchbrechen (diese wird dann aufgelöst) und dann Gas zu reduzieren. Wenn dann die neue Zielhöhe erreicht ist, den Stick nicht mehr bewegen und er rastet nach knapp einer Sekunde ein.

LG
Rob
LG
Rob

Roberto · Okt 9, 2012

@Martinez:

Ich habe mir im Quelltext die ganze MPU6050 Geschichte noch einmal angeschaut.
Grundsätzlich nimmt die MPU dort eine Sonderstellung ein.
1. ACC und Gyro in einem Chip
2. Unterschiedliche Wertzuweisung für acc_1G (Freeimu 256, sonst "512")

Für die jetzige "Formel" ist die grösse des acc_1G Absolutwertes unerheblich, aber bei 512 können natürlich mehr Störungen durchgegeben werden. Die anderen Acc -(einzel) Sensoren haben jeweils einen eingeschalteten Lowpassfilter (LPF) von 20 oder 25Hz (Nunchuk habe ich jetzt nicht nachgeschaut, aber BMA020, BMA180 etc), der direkt von ihrer Hardware erledigt wird. Bei der MPU ist keinerlei Filter eingeschaltet! D.h. alle Minivibrationen gehen glatt durch. Ich weiss nicht warum, vielleicht kann man bei der MPU nur GYRO und ACC Filter gemeinsam definieren? Dort steht: "default DLPF_CFG = 0 => ACC bandwidth = 260Hz GYRO bandwidth = 256Hz)". Jedenfalls solltest Du unbedingt in der config.h //#define MPU6050_LPF_42HZ oder sogar //#define MPU6050_LPF_20HZ setzen. So wie ich das sehe, sind dann bei der MPU sowohl Gyro(unerwünscht) und ACC(erwünscht) betroffen. Wenn z.B mit 20Hz das Höhehalten klappt, er aber fliegt wie ein Eimer (Gyro), dann mache ich noch einen Softwarelowpassfilter rein, der nur das ACC betrifft, d.h. den Harware LPF kann man dann auch reduzieren/abschalten. Den vorhandenen "//#define ACC_LPF_FACTOR 100" kann man leider überhaupt nicht für unsere Zwecke verwenden - VIEL zu träge, da ist sogar der Baro noch schneller.
Ich bin mir sehr sicher, dass da der Hund begraben ist!! Die Regelung selbst ist nicht das Problem, sonst hätte die 2b nicht funktioniert. Irgendwie bekommen wir das in den Griff.
Mache unbedingt einen MPU6050_LPF_42HZ Versuch! Ich suche mal nach dem Datenblatt, ob man getrennte LPF bei der MPU für den Gyro und Acc Anteil angeben kann.

LG
Rob

Derjunior · Okt 9, 2012

Moin Martinez,
ich hab auch den MPU6050 auf meiner FreeIMU 0.4.3. bei mir funzt es auch erst seit dem ich den Lpf auf 42Hz hab.
Viel glück bei deiner Fehlersuche

Gruß Micha

martinez · Okt 9, 2012

Roberto hat gesagt.:

@Martinez:

Ich habe mir im Quelltext die ganze MPU6050 Geschichte noch einmal angeschaut.
Grundsätzlich nimmt die MPU dort eine Sonderstellung ein.
1. ACC und Gyro in einem Chip
2. Unterschiedliche Wertzuweisung für acc_1G (Freeimu 256, sonst "512")

Für die jetzige "Formel" ist die grösse des acc_1G Absolutwertes unerheblich, aber bei 512 können natürlich mehr Störungen durchgegeben werden. Die anderen Acc -(einzel) Sensoren haben jeweils einen eingeschalteten Lowpassfilter (LPF) von 20 oder 25Hz (Nunchuk habe ich jetzt nicht nachgeschaut, aber BMA020, BMA180 etc), der direkt von ihrer Hardware erledigt wird. Bei der MPU ist keinerlei Filter eingeschaltet! D.h. alle Minivibrationen gehen glatt durch. Ich weiss nicht warum, vielleicht kann man bei der MPU nur GYRO und ACC Filter gemeinsam definieren? Dort steht: "default DLPF_CFG = 0 => ACC bandwidth = 260Hz GYRO bandwidth = 256Hz)". Jedenfalls solltest Du unbedingt in der config.h //#define MPU6050_LPF_42HZ oder sogar //#define MPU6050_LPF_20HZ setzen. So wie ich das sehe, sind dann bei der MPU sowohl Gyro(unerwünscht) und ACC(erwünscht) betroffen. Wenn z.B mit 20Hz das Höhehalten klappt, er aber fliegt wie ein Eimer (Gyro), dann mache ich noch einen Softwarelowpassfilter rein, der nur das ACC betrifft, d.h. den Harware LPF kann man dann auch reduzieren/abschalten. Den vorhandenen "//#define ACC_LPF_FACTOR 100" kann man leider überhaupt nicht für unsere Zwecke verwenden - VIEL zu träge, da ist sogar der Baro noch schneller.
Ich bin mir sehr sicher, dass da der Hund begraben ist!! Die Regelung selbst ist nicht das Problem, sonst hätte die 2b nicht funktioniert. Irgendwie bekommen wir das in den Griff.
Mache unbedingt einen MPU6050_LPF_42HZ Versuch! Ich suche mal nach dem Datenblatt, ob man getrennte LPF bei der MPU für den Gyro und Acc Anteil angeben kann.

LG
Rob

Das hört sich vielversprechend an, heute Abend mache ich mich ans Werk!!!

Vielleicht sollte ich das Teil umtaufen, Bumblebees (Hummeln) sollen ja auch von der Physik her nicht richtig fliegen können

@Micha:
Danke, das werde ich testen!

LG
Martinez

JinGej · Okt 9, 2012

martinez hat gesagt.:

falsch!

Flugfähigkeit – das „Hummel-Paradoxon“

Hartnäckig hält sich in populärer Literatur die Legende, dass eine Hummel nach den Gesetzen der Aerodynamik nicht fliegen könne. Die Geschichte kursierte zunächst als Scherz Anfang der 1930er Jahre unter Studenten des renommierten Aerodynamikers Ludwig Prandtl an der Universität Göttingen, und sie wurde begierig von der Presse aufgenommen. Nach dieser Geschichte soll eines Abends in einer Gaststätte ein Biologe einen Aerodynamiker gefragt haben, warum eine Biene oder Hummel fliegen könne. Die Antwort des Aerodynamikers soll nach einer kurzen Berechnung auf einem Bierdeckel oder einer Serviette in etwa so gelautet haben:
Die Hummel hat 0,7 cm² Flügelfläche und wiegt 1,2 Gramm. Nach den Gesetzen der Aerodynamik ist es unmöglich, bei diesem Verhältnis zu fliegen.
Dazugedichtet wurden meist noch anschließende Sätze wie:
Die Hummel kümmert das nicht und sie fliegt trotzdem. oder
Da die Hummel die Gesetze der Aerodynamik nicht kennt, fliegt sie dennoch.
Der Aerodynamiker soll seine Berechnungen vor dem Hintergrund, dass er die Flügel der Hummel fälschlich als steif angenommen hatte, nochmals überdacht haben. Aus der späteren Antwort ließ sich aber wohl keine Schlagzeile machen. Es ist umstritten, wer dieser Aerodynamiker war. In einigen Quellen wird vermutet, dass es sich um den Schweizer Gasdynamiker Jacob Ackeret (1898–1981) gehandelt haben könnte. Eventuell war es auch André Sainte-Laguë, ein Mathematiker und Mitarbeiter des französischen Entomologen Antoine Magnan. Letzterer erwähnt eine ähnlich lautende Behauptung seines Assistenten zum Flug der Insekten 1934 in seinem Buch Le Vol des Insectes.
Tatsächlich gibt es hier kein Paradoxon. Hummeln sind sehr viel kleiner als Flugzeuge. Sie bewegen sich jedoch in der gleichen Luft mit der gleichen Dichte und der gleichen Viskosität. Das hat zur Folge, dass die Reynolds-Zahl für den Hummelflug viele Größenordnungen kleiner ist als die für den Flugzeugflugs. Damit unterscheidet sich die Form des Strömungsfelds um die Flügel erheblich. Theorien hierzu wurden schon in den 1930er Jahren entwickelt. Dabei spielten insbesondere Wirbel eine entscheidende Rolle. Der experimentelle Nachweis dazu wurde 1996 erbracht, als Charles Ellington von der Universität Cambridge Versuche zum Insektenflug vornahm: Durch den Flügelschlag werden Wirbel erzeugt, die der Hummel den nötigen Auftrieb verschaffen, und die Existenz dieser Wirbel ließ sich mit optischen Mitteln zeigen.

[Quelle: Wikipedia]

JUERGEN_ · Okt 9, 2012

JinGej hat gesagt.:

manchmal halte ich die Wissenschaft, auch nur für eine andere Art der Religion.

was hat man uns noch vor 50 Jahren eingebläut, das das was in Lehrbüchern steht "das einzig Wahre ist".

heute werden viele Theorien wieder ad Absurdum geführt.

JinGej · Okt 9, 2012

JUERGEN_ hat gesagt.:

...mag sein, nur im Gegensatz zur Religion entwickelt sich die Wissenschaft weiter und kommt zu neuen Erkenntnissen (ob die dann 100% richtig sind mag dahingestellt sein, aber man beschäftigt sich weiter damit und verfeinert das ganze), was man von der Religion nicht behaupten kann....

upapa · Okt 9, 2012

upapa hat gesagt.:

Hi Roberto,
inzwischen habe ich es getan.
Da mein Crius_SE grundsätzlich mit aktiviertem Bluetooth unterwegs ist, habe ich absichtlich das Modul nicht abgeklemmt. Es sollte ein realistischer Test werden.

Die Cycletime schwankte in der GUI um 5000.
Das Testresultat hat mich jedoch nicht überzeugt. Die Regelung war nicht spürbar weicher. Dafür zeigte der Copter während der Testflüge durchgängig Mikroruckler, so, als würde er zittern (es ist auch recht frisch momentan hier bei uns...).
Nachdem ich Dein MOD mit //#define ConstantPID5000 erneut aufgespielt hatte, war das Zittern wieder weg.

upapa

JUERGEN_ · Okt 9, 2012

upapa hat gesagt.:

eigentlich läuft der AVR mit 16MHz ja auch noch mit angezogener Handbremse.

dabei gibt es sogar ausserhalb der Spezifikationen, bei 24MHz kaum Probleme.

also Reserven wären beim AVR noch drinnen.

Roberto · Okt 9, 2012

@Upapa: Die eingeschaltete, serielle Schnittstelle scheint echt der Killer für diese Funktion zu sein - also auch serielles GPS.
Naja, bei mir bringts was, und es ist auch per default auf aus.

@Martinez @MPU6050 User.
Es ist wohl tatsächlich so, dass bei der MPU per Hardware, die Filtereinstellungen für GYRO und ACC nur gleichzeitig eingestellt werden können. Das Mehrfiltern ist natürlich bei dem Gyro eher unerwünscht durch die steigende Latenz.
Ich habe mir folgenden Software Lowpass Filter überlegt, der unabhängig von der config.h Einstellung (herunter bis //#define MPU6050_LPF_42HZ) den Acc mit einem 20Hz Filter versorgen soll. Hier sind die Faktoren und die Rechenvorschrift

Die 21Hz werden als 100% gesetzt und entsprechen ergibt sich z.B der Faktor für die Acc 94Hz Einstellung ( "defined(MPU6050_LPF_98HZ)" ist auf den Gyro bezogen) 21/94= 0.2234 . Ich hoffe, dass es mit den Faktoren so hin kommt, und kein Denkfehler vorliegt. Die Faktoren kann man natürlich auch selbst anpassen. Im Grunde funktioniert der Lowpassfilter, das konnte ich immerhin ohne mpu 6050 testen.
Die ganze Änderung der IMU/getEstimatedAltitude(), mit den aufwändigen Kompileranweisungen sieht dann so aus:

Code:

///////////////////////////////////////////////
//Crashpilot1000 Mod getEstimatedAltitude ACC//
///////////////////////////////////////////////
#define VarioTabsize 8                                           // Increasing over 8 -> Risk of 16 Bit Overflow in Baro Climbrate
#define BaroTabsize 5

/* LPF FOR MPU 6050
DLPF_CFG 0: ACC 260Hz = 100% F= 0.0808  // GYRO 256Hz
DLPF_CFG 1: ACC 184Hz =  70% F= 0.1141  // GYRO 188Hz
DLPF_CFG 2: ACC 94Hz  =  36% F= 0.2234  // GYRO  98Hz
DLPF_CFG 3: ACC 44Hz  =  17% F= 0.4773  // GYRO  42Hz
DLPF_CFG 4: ACC 21Hz  =   8% OK F= 1.0  // GYRO  20Hz
DLPF_CFG 5: ACC 10Hz  =   4% OK         // GYRO  10Hz
DLPF_CFG 6: ACC  5Hz  =   2% OK         // GYRO   5Hz

Value = Oldvalue*(1-Factor) + Newvalue * Factor
*/
#if defined(MPU6050)
  #if !defined(MPU6050_LPF_256HZ) && !defined(MPU6050_LPF_188HZ) && !defined(MPU6050_LPF_98HZ) && !defined(MPU6050_LPF_42HZ) && !defined(MPU6050_LPF_20HZ) && !defined(MPU6050_LPF_10HZ) && !defined(MPU6050_LPF_5HZ)
    #define MPU6050_LPF_256HZ
  #endif
  #if defined(MPU6050_LPF_256HZ)
    #define MPULPF_FACTOR 0.0808f
  #endif
  #if defined(MPU6050_LPF_188HZ)
    #define MPULPF_FACTOR 0.1141f
  #endif
  #if defined(MPU6050_LPF_98HZ)
    #define MPULPF_FACTOR 0.2234f
  #endif
  #if defined(MPU6050_LPF_42HZ)
    #define MPULPF_FACTOR 0.4773f
  #endif
#endif

void getEstimatedAltitude()
{
  static uint8_t Vidx=0,Bidx=0;
  static int32_t LastEstAltBaro=0;
  static int8_t VarioTab[VarioTabsize];
  static int32_t BaroTab[BaroTabsize];
  static float velz = 0.0f, accalt = 0.0f;
  int8_t IdxCnt,ThrAngle;

#if defined(MPU6050)
  #if defined(MPU6050_LPF_256HZ) || defined(MPU6050_LPF_188HZ) || defined(MPU6050_LPF_98HZ) || defined(MPU6050_LPF_42HZ)
    static float MPUACCLPF[3];
    for (IdxCnt = 0; IdxCnt < 3; IdxCnt++) MPUACCLPF[IdxCnt] = (MPUACCLPF[IdxCnt]*(1.0f-MPULPF_FACTOR))+ (accADC[IdxCnt] * MPULPF_FACTOR);
    int16_t accZ = (MPUACCLPF[ROLL]*EstG.V.X+MPUACCLPF[PITCH]*EstG.V.Y+MPUACCLPF[YAW]*EstG.V.Z)*InvSqrt(fsq(EstG.V.X)+fsq(EstG.V.Y)+fsq(EstG.V.Z)) - acc_1G;
  #else
    int16_t accZ = (accADC[ROLL]*EstG.V.X+accADC[PITCH]*EstG.V.Y+accADC[YAW]*EstG.V.Z)*InvSqrt(fsq(EstG.V.X)+fsq(EstG.V.Y)+fsq(EstG.V.Z)) - acc_1G;
  #endif
#else
  int16_t accZ = (accADC[ROLL]*EstG.V.X+accADC[PITCH]*EstG.V.Y+accADC[YAW]*EstG.V.Z)*InvSqrt(fsq(EstG.V.X)+fsq(EstG.V.Y)+fsq(EstG.V.Z)) - acc_1G;
#endif
 
  velz = velz+accZ*accVelScale*ACCDeltaTime;
  accalt = accalt+velz*ACCDeltaTime*0.000001f;
  ThrAngle = EstG.V.Z/acc_1G * 100.0f;
  if (newbaroalt!=0)
   {
    newbaroalt = 0;                                                               // Reset Boolean
    BaroTab[Bidx] = BaroAlt-GroundAlt; Bidx++;                                    // Get EstAltBaro
    if (Bidx==BaroTabsize) Bidx=0;
    int32_t tmp32=0; IdxCnt = 0;
    while(IdxCnt<BaroTabsize){tmp32 = tmp32 + BaroTab[IdxCnt]; IdxCnt++;}
    int32_t EstAltBaro = tmp32/BaroTabsize;
    VarioTab[Vidx] = constrain(EstAltBaro - LastEstAltBaro,-120,120); Vidx++;     // Baro Climbrate 
    if (Vidx==VarioTabsize) Vidx=0; 
    LastEstAltBaro = EstAltBaro;
    int16_t tmp16 = 0; IdxCnt = 0;
    while(IdxCnt<VarioTabsize){tmp16 = tmp16 + VarioTab[IdxCnt]; IdxCnt++;}
    int16_t BaroClimbRate = (tmp16*33)/VarioTabsize;                              // BaroClimbRate in cm/sec // + is up // 30ms * 33 = 990ms
    velz = velz * 0.982f + BaroClimbRate * 0.018f;                                // velz= Baro&Acc Climbrate
    accalt = accalt * 0.85f + EstAltBaro * 0.15f;
   }
  int16_t ClimbRate = velz/50;                                                    // put float into 16Bit
  EstAlt = accalt;
  BaroP = 0; BaroI = 0; BaroD = 0;
  if (ThrAngle < 40) return;                                                      // Don't do BaroPID if copter too tilted// EstAlt & Baroclimbrate are always done :)
  BaroP = ((AltHold-EstAlt)*conf.P8[PIDALT])/200;
  BaroI = constrain(ClimbRate*conf.I8[PIDALT],-150,150);
  BaroD = (((int16_t)conf.D8[PIDALT]) * (100 - ThrAngle))/25;
}

Natürlich braucht das mehr Rechenzeit und satte 96 Byte des kostbaren EEPROM Speichers.

LG
Rob

JinGej · Okt 9, 2012

hm... wäre es nich fast besser den kompletten code mal.... zu überdenken?? :O

martinez · Okt 9, 2012

Roberto hat gesagt.:

Guten Abend,

ich war heute wieder testen!
Was ich da erlebt habe war echt sehr komisch.

Als erstes habe ich die Zeile #define MPU6050_LPF_42HZ aktiviert. (Ich habe vorher nochmal zur Sicherheit eeprom_clear per Arduino eingespielt und danach die "MultiWii_2_1_NewBaroPIDVario3Final" drauf geschmissen, ACC kalibriert und ab auf die Wiese.
Das Quad flog sich normal, also Baro rein und......
....die komischen Sprünge und Pumpbewegungen waren weg

(ALT PID war auf Standard 10 0.030 80)
Erfolg!
Aber sobald ich den Baro aktiviert hatte stieg der Kopter immer weiter nach oben.
Mhhh....
Ich habe mir dann gedacht "mal schauen ab wann der Kopter wieder über den ACC pumpt".
Also nach der Reihe die Optionen durch probiert bis ich bei der 256Hz LPF war.
//#define MPU6050_LPF_256HZ // This is the default setting, no need to uncomment, just for reference
//#define MPU6050_LPF_188HZ
//#define MPU6050_LPF_98HZ
//#define MPU6050_LPF_42HZ
Wobei die 256HZ Variante ja laut den Kommentar sowieso per default aktiviert ist.
Bei 256Hz wieder angekommen, war das Pumpen beim Baro immer noch NICHT wieder da!!!!
Daraufhin habe ich alles wieder auskommentiert, das Pumpen ist immer noch nicht wieder da. Ähhhh!!!! Was ist jetzt los????
Ich habe sogar alles per EEPROM_CLEAR gelöscht. Das Pumpen ist weg!!! Ich habe nichts am Kopter Hardware technisch geändert!
Wie kann das sein? Hat sich der LPF eingebrannt

das kann doch nicht sein?!?! Ich verstehe das nicht.

Zu der Höhenregelung von heute.
Am Anfang mit den LPF und den Standard ALT PID ist der Quad ständig gestiegen.
Eine Verbesserung war nur zu erreichen in dem ich I auf 0.004 reduzierte. ??? Sehr seltsam.

Ich habe dann nochmal alles zurückgesetzt und bin dann zu den besten Ergebnis mit den ALT PID 6.0 0.020 80 hält mein Bumblebee jetzt auf ca. 1m die Höhe, also schlechter als die MultiWii_2_1_NewBaroPIDVario2b.

Zusammengefasst war das heute sehr, sehr komisch!!!

Gruß
Martinez

Roberto · Okt 9, 2012

@JinGej

Klar, kann man auch einen generellen, zusätzlichen Lowpassfilter für die Accz Integration anlegen, den man dann in der config.h einstellen und zuschalten kann. Dafür muss man gottlob nicht den kompletten Barocode neu machen. Kein Harakiri erforderlich.
Durch die ausreichend sauberen Werte des BMA180, habe ich bislang keine Notwendigkeit gesehen. Wenn eine MPU Einstellung von "#define MPU6050_LPF_42HZ" reicht, ist das natürlich die beste Lösung (kein Speicherverbrauch).

@Martinez: Da blicke ich jetzt allerdings auch nicht durch. Sehr merkwürdig. Deine Acc Werte sind doch in alle Richtungen bei max 512 (nicht nur z).

LG
Rob

martinez · Okt 9, 2012

Wow, Rob! Hast du dir das alles heute überlegt! Mensch, das sieht ja echt heftig aus

Roberto · Okt 9, 2012

Das sieht schlimmer aus, als es ist. Dieser ganze Kompilermist blässt es so auf.
Wenn Du z.B keinen LPF Filter in der config.h angibst, kannst Du z.B hier
#if defined(MPU6050_LPF_256HZ)
#define MPULPF_FACTOR 0.0808f
#endif
auch einen anderen Faktor eintragen. Je kleiner, desto mehr Filter und Latenz.

LG
Rob

martinez · Okt 9, 2012

Soll das in das config File?
Hier hin, oder?

/**************************************************************************************/
/******** Gyro filters ********************/
/**************************************************************************************/

Gruß
Martinez

Roberto · Okt 9, 2012

Nein, das:
...
#if defined(MPU6050_LPF_256HZ)
#define MPULPF_FACTOR 0.0808f
#endif
...
ist nur ein Ausschnitt von dem Codevorschlag (unter IMU) von oben, da kannst Du den Filter ändern.

LG
Rob

martinez · Okt 9, 2012

gecheckt

Baro Code Änderungen

Erfahrener Benutzer

Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

JinGej

Gast

Generation 60++

JinGej

Gast

Erfahrener Benutzer

Generation 60++

Erfahrener Benutzer

JinGej

Gast

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer

Erfahrener Benutzer