«

Dez 15 2015

RoPi – Autonomer Roboter mit RaspberryPI & Arduino

UnderConstruction

Dieses Projekt ist noch nicht abgeschlossen, möchte aber schon mal eine übersichtlichere Zusammenfassung erstellen. Stay tune.

Original Beitrag: http://www.forum-raspberrypi.de/Thread-robotik-ropi-autonomer-roboter-mit-raspberrypi-arduino

sensors_IRSLAM

Einleitung

Ziel dieses Projekts ist es einen Autonomen Roboter zu erschaffen.
Der Roboter soll selbstständig umherfahren und die Umgebung erkunden, sowie Berechnungen anstellen um möglichst Effektiv zu einem Ziel zu gelangen. Also nicht jede Bewegung ferngesteuert werden sondern tatsächlich Autonom handeln und bewegen.
Es gibt aber auch ein cooles Web-Interface mit dem man das Gefährt auch manuell steuern kann – wem also die Autonomität zu kompliziert ist lässt das einfach weg 😀

Warnung:

So ein Projekt geht schnell ins Geld, auch wenn diverse Komponenten für weniger als 1$ zu bekommen sind. Mit Anschaffungskosten im Bereich um 500€ sollte man rechnen. Man sollte auch etwas Bastelbegabung mitbringen, denn es gibt einiges zu sägen, bohren, schrauben, löten.

 


 

(geplante oder bereits umgesetzte) Features

Yes = Fertig/Vollständig umgesetzt.
No = Noch nicht, oder nur teilweise, umgesetzt

  • Modularer Aufbau: Yes
    • Ein Hauptprogramm (‚the Brain‘). Optionale Nebenprogramme, wie z.B. Web-Interface etc.Interne Kommunikation zwischen den Programmen mithilfe Socket’s (wie bei ROS).
  • Kommunikation zwischen RaspberryPI Arduino über USB Yes
    • Sofortige Verarbeitung neuer Daten/Befehle (dank threading).
  • Web-Interface dient nur zur Kontrolle. Im Notfall kann aber auch eingegriffen werden oder der Roboter vollständig darüber gesteuert werden. Yes
    • Kommunikation zwischen Web-Interface und RaspberryPI über WebSocket (extra Script. interne Anbindung an Hauptprogramm via Socket). Dadurch kann das Web-Interface bzw der Webserver auch auf einem anderen Rechner im Netzwerk laufen.
    • Kein ständiges neu laden der Webseite dank Javascript und WebSocket.
    • RaspiCam auf Pan/Tilt mit eigenem Ultraschall Sensor. Kann ebenfalls im Web-Interface über Schieberegler gesteuert werden.
    • Motor Geschwindigkeit pro Seite, oder alle zusammen über Schieberegler einstellbar.
    • Ständiges aktualisieren (500ms) der Sensor- / Fahrt- Werte.
    • GRID-MAP Aktualisierung bzw Anzeige.
    • Kompass Anzeige.
  • Verschiedene Mode’s: Yes
    • Explore: Umgebung erkunden und Map erstellen.
    • AutoDrive: Selbstständig durch Umgebung fahren um definiertes Ziel zu finden.
    • Und natürlich auch manuelles steuern übers Web-Interface.
  • Veränderbare Regeln die der Roboter nach einstellbaren Kriterien verändern kann. No
    • z.B. die Standardaktion beim erkennen eines Hindernisses zu verändern wenn diese 10x fehl schlug: Standardmäßig nach rechts zu fahren. Wenn sich herausstellt das rechts aber auch ständig ein Hindernis ist, kann der Roboter nach 10 Fehlversuchen die Regel auf „Standardmäßig nach Links“ o.ä. ändern.
  • Globale Regeln die der Roboter nicht verändern kann. Yes
    • z.B. nicht über Bereiche zu fahren die als „Abgrund“ gekennzeichnet sind.
  • Lokale und Globale Map. No
    • Die Lokale Grid-Map befindet sich im Speicher des Arduino’s und wird stetig aktualisiert sowie an ‚the Brain‘ übermittelt. Diese repräsentiert die aktuelle, unmittelbare Umgebung.
    • Die Globale Grid-Map wird erst aktualisiert wenn Objekte bzw Wegpunkte 2x verifiziert wurden. Diese wächst dynamisch.
      Außerdem wird wärend des AutoDrive Modes die Globale-Map zu Rate gezogen um sicher zu stellen keinen Fehler zu machen, wie z.B. ein Abgrund den der Arduino aber noch nicht kennt.
      Bei der Verwendung von 2 Karten steigt die Genauigkeit, wie man zB auch hier nachlesen kann.
  • Manuelle Anpassung der Globalen GRID-Map. No
    Um Räumen sowie Objekten einen Namen geben zu können, sowie Gefahrenbereiche wie „Abgrund“ (grob) zu kennzeichnen.
  • Angabe eines Ziels durch GRID-Map.
    • Wahlweise durch anklicken auf GRID-Map, oder als Sprachbefehle wie z.B. „Fahre ins Wohnzimmer unter den Esstisch“.
      Voraussetzung hierfür ist natürlich ein bereits benannter Raum sowie Objekt.


Technischer Ablauf

Auf der Roboter Plattform sind ein bis zwei Arduino’s verbaut die das ansteuern der Sensoren und Motoren übernehmen, und an den RaspberryPI angeschlossen sind.
Die Arduino’s schicken ihre Daten, was sie machen oder von den Sensoren an den RaspberryPI, aber sollen selber nichts entscheiden sondern nur der PI.
Der RaspberryPI entscheidet dann zum Beispiel, dass das Objekt (eine Wand oder allg. Hindernis) zu nah ist und übermittelt an den jeweiligen Arduino mit der Motorsteuerung entsprechende Befehle das Objekt zu umfahren.

Zur Orientierung bedarf es mindestens einen Ultraschall Sensor um Hindernisse zu erkennen, bei nur einem Ultraschall Sensor auch einen Pan/Tilt.
Desweiteren benötigt man einen Kompass um die Himmelsrichtung, in die der Roboter guckt, bestimmen zu können um entsprechend zu wissen wo genau sich ein Hindernis befindet usw.

Für Autonomität muss man sich aber auch auf mehrere Sensoren stützen, da nur einer nie perfekt präzise ist. Zusätzlich kämen also auch noch Odometriedaten in Frage, um die zurückgelegte Stecke zu kennen. Damit diese möglichst genau sind sollte die Roboter Plattform Reifen statt Ketten haben, denn Ketten haben einen gewissen Schlupf und rutschen, in Kurvenfahrten haben die Encoder zudem Abweichungen…

Das schwierigste ist die Software.
Die Arduino’s brauchen nur die Sensoren und Motoren ansprechen, die Daten werden bei mir über die Serielle Schnittstelle (USB) in beide Richtungen verschicken.
Der RaspberryPI muss diese Daten möglichst schnell und permanent empfangen (quasi in Echtzeit, wobei das nicht wirklich geht), aber muss gleichzeitig auch in der Lage sein etwas zurück zu schicken also Befehle für die Arduino’s.

Desweiteren möchte man den Roboter ja auch mal selber steuern bzw dem PI Befehle geben die er dann umsetzt.. Dafür benötigt man bei der PI–>Arduino Kommunikation also auch noch eine Schnittstelle um über Funk/WLAN Befehle umzusetzen. Dabei erscheint mir der Weg über einen Socket-Server am einfachsten.


In Punkto Wegfindung (PathMap, Karten) und Lernmodus will ich sowas wie folgendes erreichen: http://www.societyofrobots.com/images/sensors_IRSLAM.gif
Dabei wird das sog. SLAM (Simultaneous Localization And Mapping) verwendet, was Bestandteil der aktuellen Robotik Forschung und sehr komplex ist…

Um also nicht gleich von 0 auf 100 durchzustarten werde ich zunächst mit dem sog. wavefront algorithm anfangen (der Link beschreibt das recht gut, auch mit Codebeispielen)
Soweit ich das verstanden habe wird das in etwas so aussehen:

Ein Raum wird in viele kleine Quadrate eingeteilt (sog. Nodes), die von der Größe her die Abmessungen des RoPi’s entsprechen (so lässt es sich präziser navigieren) und als X und Y Koordinaten festgelegt werden.
Dann werden die Quadrate in denen Objekte bzw Hindernisse stehen rot markiert bzw mit einer 1 versehen. Quadrate mit einer 0 darf er befahren, mit einer 1 nicht.

Im Algorithmus sind diese Werte allerdings etwas anders:
Nicht befahrbare Quadrate haben den Wert 255
Befahrbare Quadrate haben den Wert 0
Der Roboter selbst hat den Wert 254
Das Ziel wohin der Roboter fahren soll hat den Wert 1

Der Algorithmus fängt nun ab seiner Position (oder oben rechts) an zu zählen und geht jede einzelne Node Wellenförmig durch, ignoriert alle 255’er Werte und natürlich auch sich selbst, zählt die dann zusammen und legt den kürzesten Weg zum Ziel anhand der geringsten Summe fest (geringste Zahl an Nodes die durchfahren werden müssen).

Auch wird der RoPi ausgebremst wenn man nach jeder Fahrbewegung stehen bleiben muss um den Bereich in Fahrtrichtung nach unbekannten Objekten zu scannen.. Aus diesem Grund möchte ich den vorderen Bereich mit 3 Ultraschall Sensoren versehen (einer Mittig und die anderen im 45° Winkel jeweils zur Seite) und diese ständig auslesen um möglichst schnell auf Veränderungen reagieren können. Eine Optimierung hierfür wäre an einen Halbkreis mehrere Sensoren vertikal anzubringen (zB an eine doppelt halbierte Plastikflasche, erst Flasche in der Mitte durchsägen sowie den Boden abtrennen und dann halbieren sodass man einen Halbkreis hat woran man dann die Sensoren dran schraubt. Profis nehmen dafür Blech/Metal oder eine CNC-Fräse :))

 



Chassis

Die Basis bildet der DAGU – Rover 5 Robot Platform (2 motors + 2 encoders) (aber gekauft bei HobbyKing).

Vorteil bei diesem Chassis sind die bereits integrierten Encoder und einige gute Beispiele vom Hersteller oder andere Projekte mit diesem Chassis wie z.B. dieses.

Aber auch die zusätzliche DAGU – Rover 5 Explorer PCB für dieses Chassis bietet eine sehr gute Basis sowie Anschlussmöglichkeiten.
Dort sind auch bereits Bereiche vorgesehen um einen Pan/Tilt sowie Arduino zu befestigen, sowie den im Chassis beigefügten Akku-Halter anzuschließen sowie aufzuladen usw. Es können bis zu 4 Motoren inkl. Encoder angesprochen werden, wobei die Handhabung ziemlich einfach gehalten wurde und für die Motoren auch ein current-Pin vorhanden ist um ’stall‘ oder andere Probleme feststellen zu können (wenn die Motoren in ’stall‘ geraten verbrauchen sie schlagartig viel Strom und können die Antriebs-Akkus sehr schnell leer saugen).
Auch die bereits jeweils in den Ecken befindlichen IR-Sensoren sowie leistungsstarker MotorDriver runden das ganze angenehm ab. Das PCB ist ebenfalls sehr gut dokumentiert und vom Hersteller mit Beispielen gut verständlich illustriert.

Der Stromverbrauch des Explorer PCB’s ist minimal und soll laut Hersteller 50mA betragen, wobei die IR-LEDs am meisten verbrauchen sollen – diese aber ja auch nicht ständig an sind sondern wenn dann nur maximal 100ms.

Bei dem Explorer PCB waren auch einige Steckbrücken in verschiedenen Längen dabei..

SparkFun hat zu diesem Chassis (aber einem eigenen MotorDriver) auch ein kurzes Video gemacht: https://www.youtube.com/watch?v=jO3wrNsQmv0

 


 

 

Wie eingangs bereits erwähnt sollte man lieber Reifen anstatt Ketten verwenden. Man muss sich deshalb aber nicht nach einem anderen Chassis umsehen sondern kann sich zum Beispiel > diese < von SparkFun kaufen – die passen super für das Rover5 Chassis :)
Man kann aber auch andere Reifen verwenden solange sie für eine 4mm dicke Welle ausgelegt sind. Orientiert euch dabei aber an besagten Reifen und derer Befestigung!

 



 

Sensoren

Als [b]Kompass[/b] kommt bei mir der [url=http://www.robot-electronics.co.uk/htm/cmps10doc.htm]CMPS10[/url] zum Einsatz der hervorragend dokumentiert ist und sowohl I2C als auch UART oder PWM unterstützt. Ich verwende ihn über I2C: default address: 0x60
Wie man die I2C Adresse ändern kann wird [url=http://www.robot-electronics.co.uk/htm/cmps10i2c.htm]>> hier <<[/url] beschrieben. [url=http://erik-bartmann.de/component/attachments/download/85.html]> Hier <[/url] ist auch noch ein guter Artikel zu dem Module.

Davon verwende ich zwei Stück:
* Einer zeigt die Ausrichtung des Chassis an.
* Ein anderer ist vorne am Pan/Tilt angebracht um die Blick-Richtung des abgeschickten Pings zu kennen. Dies ist wichtig um kontrollierter zu wissen um wie viel Grad ein Objekt geortet wurde, auch um z.B. Kontrollmessungen zu den fest montierten US-Sensoren durch zu führen. Aber auch um Objekten oben oder unten einen Winkel zuordnen zu können (durch den Pitch Wert). Das ist auch für die Kartenerstellung wichtig.

Allerdings muss ich an dieser Stelle anmerken das die Produktion des CMPS10 eingestellt wurde, es sollten aber noch etliche im Umlauf sein. Der Nachfolger ist der [url=http://www.robot-electronics.co.uk/htm/cmps11doc.htm]CMPS11[/url]
Beim Kompass muss man darauf achten das dieser das Erdmagnetfeld verwendet – andere Magnetfeld-Quellen stören also die Genauigkeit, weswegen dieser auch etwas oberhalb des Konstrukts angebracht werden muss, also nicht direkt über dem PI oder Arduino.

 


 

Bezüglich [b]Ultraschall Sensor[/b] (berührungslose Abstandsmessung. Sonar) sei gesagt das es viele verschiedene Ausführungen gibt, die alle ihre Vor- aber auch Nachteile haben. Die meisten jedoch haben einen Erkennungswinkel von ca.15°; eine maximale Reichweite von ca. 4 Metern und eine minimale Reichweite von 2cm.
Leider kann der Ultraschall von glatten Flächen abgelenkt werden.

Generell habe ich die weit verbreiteten [url=http://www.mikrocontroller.net/attachment/218122/HC-SR04_ultraschallmodul_beschreibung_3.pdf]HC-SR04[/url] im Einsatz, die eine maximale Reichweite von 4 Metern und einen Verbrauch von ca. 15mA haben.
Mittlerweile habe ich auf dem Pan/Tilt aber den etwas besseren [url=http://www.ebay.de/itm/371170556739?_trksid=p2059210.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT]US-015[/url] verbaut. Der hat eine maximale Reichweite von 7 Metern und verbraucht nur ca. 2,2mA! (leider habe ich den Link wo ein genauer Vergleich zu sehen war verramscht :( vllt finde ich den wieder..). Entgegen der meisten Beschreibungen hat der US-015 tatsächlich eine Reichweite von 7 Metern, also nicht wundern, das ist kein Schreibfehler meinerseits :)

Von den US hatte ich anfangs nur einen auf dem Pan/Tilt.
Dazu hatte ich im Arduino-Sketch ein Abschnitt programmiert damit sich der Pan/Tilt in einem definierten Bereich in 20er Schritten von links nach rechts Bewegt, dann 10 Schritte nach oben versetzt, dann von rechts nach links scanned, wieder 10 Schritte nach oben – bis das definierten Ende erreicht wurde und dann das Spiel wieder Rückwärts fortsetzte.
Da diese Prozedur aber viel Zeit kostet und die Fahrbewegungen ausbremst, habe ich mich später dafür entschiedene mehrere Ultraschall-Sensoren anzubringen. Vorne 3, jeweils im 45° Winkel versetzt und hinten zZt nur einen, der aber eigentlich überflüssig ist sobald GRID-Map verwendet wird. Den Beweglichen US auf dem Pan/Tilt behalte ich aber um auch Prüfungen nach oben/unten durchführen zu können.

 


 

Die [b]IR-Sensoren[/b] an den Ecken des Explorer PCB’s haben eine (zuverlässige) maximale Reichweite von ca. 1 Meter, aber keine minimale Reichweite. Da die US-Sensoren nichts näher als 2cm erkennen ist es also gut auch IR zu haben.
Allerdings funktionieren diese Sensoren sowohl draussen als auch bei direkter Sonnenbestrahlung nicht mehr (oder wenn andere IR-Quellen im Spiel sind). Deshalb darf/kann man sich wie eingangs erwähnt nicht nur auf einen Sensor-Typ verlassen.
Die Genauigkeit kann durch stärkere IR-LEDs verbessert/erhöht werden, aber da ich mich hauptsächlich auf US stütze kann ich darauf erst mal verzichten.


 

Damit der Roboter weiß wie viel Strecke er zurück gelegt hat – was wichtig für die GRID-Map Erstellung ist – befinden sich wie erwähnt in den Motoren sog. [b]Odometrie-Sensoren[/b].

Diese zu kalibrieren hat mich einiges an Nerven gekostet, da nicht ein Signal auch eine Umdrehung bedeutet: ca. 1000 wechsel zwischen HIGH und LOW (Flankenwechsel) beziffern 6 Umdrehungen der Motoren. Das sagt aber noch nichts darüber aus wie viel Strecke das Gefährt zurückgelegt hat und kann je nach Untergrund (rutschen) variieren.
Ich musste also auf Millimeter genau jeden Untergrund den ich in meiner Wohnung habe genauestens ausmessen bzw den Roboter eine bestimmte Strecke abfahren lassen, die Flankenwechsel zählen und dann konnte ich ermitteln wieviel Impulse 1mm entspricht… :-/ Man mag es kaum glauben, aber ich hatte tatsächlich je nach Untergrund Abweichungen, zwar minimal aber man will’s ja auch irgendwie möglichst genau haben 😀

 



 

[an=OtherHW][u]Andere Hardware:[/u][/an]

Beim [b]Pan/Tilt[/b] habe ich mich für das kleine, ebenfalls von DAGU stammende, [url=http://www.exp-tech.de/dagu-pan-tilt-kit-with-servos?XTCsid=1515eb83bfd84dc4fa8dda407d384fd1]Sensor Pan/Tilt Kit mit Servomotoren[/url] entschieden. Das hat dann auch die passende Größe um es auf der Explorer PCB zu befestigen.
Vorteil ist das der Rahmen aus Aluminium und kein Plastik besteht.
Ein Nachteil, den ich aber auch erst wärend der Entwicklung festgestellt habe ist, dass die Servo’s keine analoge Rückmeldung ausgeben. Also nicht kontrolliert werden kann ob sie wirklich an die gewünschte Position gefahren sind, bzw bräuchte man dann im Programm nur solange warten bis sie die vorgegebene Position erreicht haben bevor man eine US-Messung o.ä. durchführt… Allerdings sind solche Servo’s mit Rückmeldung relativ teuer und müssen dann auch noch die richtigen Abmessungen haben um in den Pan/Tilt zu passen…
Ein weiteres Manko von diesem Pan/Tilt sind leider auch die billigen Schrauben. Bei der Montage sind mir 3 Schraubenköpfe abgerissen, obwohl ich die nicht wirklich ‚zu fest‘ gezogen habe :(

Auf der schwenkbaren Pan/Tilt Befestigung ist oben der Ultraschall Sensor und da drunter die RaspiCam angebracht (derzeit noch provisorisch mit einem doppelseitigem Klebeband-Streifen)

 


 

Als [b]RaspiCam[/b] verwende ich einen [url=http://www.ebay.de/itm/New-Camera-Module-Board-REV-1-3-5MP-Webcam-Video-1080p-OV5647-For-Raspberry-Pi-/161283046704?pt=LH_DefaultDomain_0&hash=item258d37fd30]China-Nachbau[/url], die als rev1.3 beziffert wird.
Die Kamera ist kleiner als rev1.0 und hat eine für mich ausreichende Bildqualität, wobei diese etwas verrauschter als beim Original sein soll. Stört mich aber derzeit nicht wirklich :)

Zusätzlich verwende ich ein längeres (30cm) [url=http://www.ebay.de/itm/Raspberry-Pi-Kamera-Ersatz-Flexkabel-30cm-Flachbandkabel-Flex-Kabel-wie-E244054-/111120043200?pt=DE_Computer_Sonstige&hash=item19df454cc0]Flex-Kabel[/url] damit die Kamera problemlos um 180° geschwenkt werden kann – diese ist nämlich ca. 10cm über dem Explorer PCB befestigt und wenn sie ganz nach rechts oder links geschwenkt wird, ist bereits das 30cm Flex-Kabel schon fast zu stramm.

 


 

Als [b]WLAN-Stick[/b] verwende ich den [url=http://www.amazon.de/gp/product/B00F9OKKIE?psc=1&redirect=true&ref_=oh_aui_detailpage_o01_s00]Edimax EW-7612UAN V2[/url] der eine wesentlich bessere Reichweite und Empfangsqualität besitzt (dank Antenne) als der winzige Edimax EW-7811Un (Nano), aber den selben Chipsatz 8192cu verwendet wodurch er sich ohne aufwendige Treiberinstallation sofort plug&play nutzen lässt.
Aber da er auch wie sein kleiner Bruder nach einiger Zeit in einen Energiesparmodus geht, muss man auch hier den [url=http://www.forum-raspberrypi.de/Thread-hinweise-edimax-ew-7811un-wlan-adapter?pid=63602#pid63602]suspend-Mode abschalten[/url].

 


 

Als [b]USB-Hub[/b] kommt ein [url=http://www.forum-raspberrypi.de/Thread-suche-usb-hub-host-controller-breakout-pcb?pid=124587#pid124587]kleiner passiver 4-Port USB-Hub[/url] zum Einsatz, der schön kompakt ist. Beachten sollte man das dieser auch Zurückspeisen kann – man könnte darüber also auch den PI mit Strom versorgen anstatt über microUSB.

 


 


 

Stromverbrauch überwachen

Um den Strom-bedarf/verbrauch zu überwachen verwende ich derzeit [url=http://www.adafruit.com/product/1549]Adafruit USB Power Gauge Mini-Kit[/url]. Damit kann über UART überwacht werden wie viel Strom/Volt das über USB angeschlossene Gerät schluckt/benötigt/zieht.
Den „USB Power Gauge“ habe ich zwischen PowerBank und RaspberryPI angeschlossen und kann somit überwachen wie viel Ampere der PI aktuell zieht.
Wichtig hierbei ist das zusätzlich auch noch mal GND über ein JumperKabel mit dem PI verbunden wird.

Zusätzlich habe ich mir aber auch noch das [url=http://www.adafruit.com/products/904]INA219 High Side DC Current Sensor Breakout[/url] zugelegt, welches man in Reihe zwischen den Pluspol der Stromversorgung und den Verbraucher anschließt. Ein Kabel kommt vom PowerSupply, geht auf V+ am INA219 und V- geht dann zum Verbraucher. Also: V+ = Eingang von Batterie. V- = Ausgang zum Verbraucher. GND muss gemeinsam zusammengeführt werden.
Wenn man dies nun ebenfalls an die USB-PowerBank anschließen würde, kriegt man aber nur die zur Verfügung stehenden Ampere des gewählten Ausgangs der PowerBank angezeigt (entweder 1A oder 2.1A), da die PowerBank das ja bereits intern reguliert.
Schließt man das INA219 Module an den „Batterie“ Ausgang vom Explorer PCB an werden aber die tatsächlich zur Verfügung stehenden Ampere der „Antriebs Akkus“ (der Batteriehalter vom Chassis) angezeigt, da es hier keine Begrenzung gibt.

Wichtig ist dass das INA219 Modul mit nur 3V3 betrieben wird (VCC) da sonst die I2C Ausgänge nicht auch 3V3 ausgeben sondern 5V. Wenn man nur 5V für VCC zur Verfügung hat brauch mal also noch einen Levelshifter (Logic Level Converter) um es gefahrlos an den PI anschließen zu können!

Eine Alternative zu diesen Modulen wären ggf auch sog. Hall-Effekt Sensoren, worüber ich zwar auch schon einiges gelesen aber bisher nicht ausprobiert habe..

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Sie können diese HTML-Tags verwenden: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

4 Besucher online
2 Gäste, 2 Bots, 0 Mitglied(er)
Meiste Besucher heute: 4 um/am 09:19 pm
Diesen Monat: 23 um/am 11-13-2018 01:35 am
Dieses Jahr: 36 um/am 08-05-2018 09:17 pm
Jederzeit: 36 um/am 08-05-2018 09:17 pm