Ich arbeite gerade an einem mechatronik Projekt für die Uni, bei dem Bilddaten von einer Kamera über ein bestehendes Netzwerk geschickt werden sollen. Die Kamera ist auf einem Fahrzeug montiert, dass mit einem Cortex A5 gesteuert wird (Linux). Dieses Fahrzeug ist mit einem weiteren Fahrzeug über einen RS485 Bus verbunden. Beide haben zwar eine WLAN Antenne, sind aber nicht ständig mit dem Netzwerk verbunden. Aus diesem Grund sind sie über einen RS485 Bus verbunden. Die Controller senden dann Statusdaten an den Host-PC. Ist ein Controller nicht im Wlan, so sendet dieser die Status an den anderen Controller der diese Nachricht dann weiterleietet. Diese Funktion ist bereits implementiert und getestet. Bei der Kamera handelt es sich um eine Industrie Kamera die mit GenICam (ein Protokollstandard) gesteuert bzw. ausgelesen werden kann. Ich suche momentan nach Ideen oder ähnliche Beispielprojekte zur Umsetzung. Soll ich z.B. die Kameradaten GenICam Protokoll einfach über RS485 weiterleiten und erst am Host-PC in ein lesbares Bild umwandeln? Oder soll ich daraus eine Art Videostream machen? Nachfolgend noch einige technische Daten zum System: Kamera - GenICam - 100Mbit/s Ethernet - 736x480px Embedded Linux Device - Atmel SAMA5D3 with ARM Cortex-A5 Processor - 128MB RAM / 128MB Flash - Linux Kernel 3.1 - busybox - Eigene Applikationen entwickelt in C++ PC - muss noch festgelegt warden, wahrscheinlich Windows
Angehängte Dateien:
-
1614651361.png
9,5 KB
:
Verschoben durch Moderator
Für GenICam Kameras gibt es Avaris, eine Library: https://wiki.gnome.org/action/show/Projects/Aravis?action=show&redirect=Aravis Bin mir jetzt aber nicht sicher, inwieweit das für so einen ARM funktioniert.
Hendrik S. schrieb: > Ich suche momentan nach Ideen oder ähnliche Beispielprojekte zur > Umsetzung. Soll ich z.B. die Kameradaten GenICam Protokoll einfach über > RS485 weiterleiten und erst am Host-PC in ein lesbares Bild umwandeln? Das Fahrzeug mit der Kamera sollte die Bilddaten komprimieren. > Oder soll ich daraus eine Art Videostream machen? Wenn Du die Rechenleistung für Videokompression unter Berücksichtigung Eurer Anforderungen hast, ja.
Welche Datenrate hat dein Video 1:1 von der Kamera? Hast du volle Kontrolle über den RS485? Brauchst du auf den Linux-Devices Zugriff auf die Bilder, oder reicht es, wenn diese am PC ankommen? => zweimal pppd starten, IP-over-RS485. Ein paar Routing-Einträge, voila, der Windows-PC kann transparent mit seiner Windows-Software auf die Kamera zugreifen. Nur halt etwas langsamer als mit Direkt-Link. Aber: Man muss dann nichts programmieren. Je nach Studiengang kann das bei einem UNI-Projekt ein Nachteil sein.
Nachtrag: Ganz so einfach ist es dann doch nicht. PPP erwartet eine Full-Duplex-Verbindung, out-of-the box beißt sich das mit RS485. d.H, man braucht ein kleines Programm/Script, dass auf der Leitung Handshake etc handhabt, und dem PPPd einen "full duplex" Datenstrom simuliert. Macht vmtl. eh Sinn, wenn da noch andere Daten rüberwandern sollen.
Zu der Datenrate kann ich noch nicht viel sagen, da ich erstmal nur einzelne Bilder verschicken möchte. Die Kamera wird für jedes Bild einzeln getriggert (24V Eingang oder Software-Trigger). Dann wäre ein Bild: 8 bit 736 px * 480 px = 2,82 Mbit = 0,35 MByte Ich schätze ich brauche so 10 Bilder pro Sekunde, dann wäre die Datenrate 3,5MB/s. Gar nicht mal so wenig... Ja der RS485 Bus ist Half-Duplex. Ich schaue mir das Thema PPP mal an, habe bisher gar keine Erfahrung damit. Wie aufwändig wäre denn so eine Lösung? Könnten man denn theoretisch mit diesem kleinen Prozessor eine Art Bildverarbeitung machen? Sollte ich mir die Themen Bildkompromierung oder auch OpenCV mal etwas genauer angucken, oder macht das keinen Sinn auf dem "kleinen" 498 Mhz Prozessor und 128MB RAM/Flash? Hat da jemand Erfahrung?
Habe ich das richtig verstanden und die Fahrzeuge sind über ein Kabel für den RS485 verbunden? Wie sieht da der genaue Anwendungsfall aus? Fahren die dann hintereinander oder parallel? :)
Hendrik S. schrieb: > Sollte ich mir die Themen Bildkompromierung > [...] mal etwas genauer angucken[...]? Lars R. schrieb: > Das Fahrzeug mit der Kamera sollte die Bilddaten komprimieren.
Sind die Fahrzeuge über eine Drei-Draht-Leitung (D+, D-, GND) miteinander verbunden, oder steckt zwischen denen evtl ein voll bestücktes 9-poliges D-SUB-Kabel? Wenn D-SUB vorhanden ist, könnte man den 485 auch voll-Duplex laufen lassen. dazu braucht man nur auf beiden Seiten den geeigneten Treiberbaustein, MAX491 z.B. Gruß Florian
Johannes H. schrieb: > Habe ich das richtig verstanden und die Fahrzeuge sind über ein Kabel > für den RS485 verbunden? > Wie sieht da der genaue Anwendungsfall aus? Fahren die dann > hintereinander oder parallel? :) Drohne1 arbeitet als Reichweiten-Extender für Drohne2 und RS485 ist ein Quatsch, der zwecks Verschleierung irgendwo in der Kette Firma mit Geld->Zulieferer->Prof->Betreuer->Student eingefügt wurde.
Johannes H. schrieb: > Habe ich das richtig verstanden und die Fahrzeuge sind über ein Kabel > für den RS485 verbunden? > Wie sieht da der genaue Anwendungsfall aus? Fahren die dann > hintereinander oder parallel? :) Nein, die fahren auf Schienen und sind wie Waggons miteinander verbunden. Es sind eigentlich auch nicht nur 2, ich wollte hier der Einfachheit halber nur ein Beispiel mit 2 Fahrzeugen machen. Der RS485 (2-Draht) ist als Ring aufgebaut.
:
Bearbeitet durch User
Hendrik S. schrieb: > Der RS485 (2-Draht) ist > als Ring aufgebaut. GND dann über die Schiene? Aber egal: Wenn's mehr als zwei Teilnehmer sind, ist PPP nicht mehr wirklich geeignet. Sagt schon der Name...
Lars R. schrieb: > Hendrik S. schrieb: >> Sollte ich mir die Themen Bildkompromierung >> [...] mal etwas genauer angucken[...]? > > Lars R. schrieb: >> Das Fahrzeug mit der Kamera sollte die Bilddaten komprimieren. Ok, ich würde vorab nur gerne wissen wieviel Performance denn so eine Komprimierung frisst und ob jemand dazu Erfahrung hat.
Hendrik S. schrieb: > Ok, ich würde vorab nur gerne wissen wieviel Performance denn so eine > Komprimierung frisst und ob jemand dazu Erfahrung hat. Auf einem Cortex-A5? So einiges. Aber VGA, 5 - 10FPS mit JPEG könnten gerade noch klappen je nachdem was sonst noch läuft.
Hendrik S. schrieb: > Ok, ich würde vorab nur gerne wissen wieviel Performance denn so eine > Komprimierung frisst und ob jemand dazu Erfahrung hat. Ich würde zuerst prüfen, ob die Kamera statt unkomprimierten Einzelbildern nicht sowieso einen komprimierten Videostrom ausgeben kann. Solche Kameras haben die Video-Komprimierung in Hardware dabei (ASIC oder DSP-Block im µC oder ...). Besser/Energieeffizienter/Schneller kriegst du das mit deinem ARM rein in Software nicht hin.
Planlos schrieb: > Aber egal: Wenn's mehr als zwei Teilnehmer sind, ist PPP nicht mehr > wirklich geeignet. > Sagt schon der Name... OK. Also muss ich das Bild zuerst abspeichern, dann per RS485 weiterleiten, empfangen, und per Wlan verschicken. Wenn das aber zu aufwendig wird hätte ich noch eine andere Idee: Die WLan Lücken sind eigentlich pro Rundlauf nur ca. 5 Sekunden. Trotzdem könnte dabei (auch falls man doch eine Kamera mit besserer Auflösung braucht) einiges an Daten anfallen. Leider ist die Platine auf dem der Cortex sitzt fertig entwickelt und es lässt sich kein Speicher erweitern. Eine Möglichkeit über RS485, um quasi ein "Live" Bild zu haben wäre schon eleganter. Was gäbe es denn für Möglichkeiten das Bild über Wlan zu übertragen? Da ich mich etwas in der Linux-Welt auskenne würde mir spontan einfall ein Laufwerk auf dem PC zu mounten und dann das Bild zu übertragen. Ich bin mir aber etwas unsicher wie gut das funktioniert, wenn die Wlan Verbindung ständig auf- und abgebaut wird... britzl schrieb: > Auf einem Cortex-A5? > So einiges. > > Aber VGA, 5 - 10FPS mit JPEG könnten gerade noch klappen je nachdem was > sonst noch läuft. Das klingt doch gut. Wie sieht es mit OpenCV aus? Die Kamera ist ja eigentlich nur dazu da, Objekte auf der Schiene zu erkennen. Wenn ich die Auswertung direkt im Controller mache, könnte ich die Bilder auch nur senden, wenn tatsächlich etwas endeckt wurde. Planlos schrieb: > Ich würde zuerst prüfen, ob die Kamera statt unkomprimierten > Einzelbildern nicht sowieso einen komprimierten Videostrom ausgeben > kann. > > Solche Kameras haben die Video-Komprimierung in Hardware dabei (ASIC > oder DSP-Block im µC oder ...). Besser/Energieeffizienter/Schneller > kriegst du das mit deinem ARM rein in Software nicht hin. Also eigentlich sind alle Industrie-Kameras die ich bis heute gefunden habe reine Einzelbildkameras.
Hendrik S. schrieb: > britzl schrieb: >> Auf einem Cortex-A5? >> So einiges. >> >> Aber VGA, 5 - 10FPS mit JPEG könnten gerade noch klappen je nachdem was >> sonst noch läuft. > > Das klingt doch gut. Wie sieht es mit OpenCV aus? Die Kamera ist ja > eigentlich nur dazu da, Objekte auf der Schiene zu erkennen. Wenn ich > die Auswertung direkt im Controller mache, könnte ich die Bilder auch > nur senden, wenn tatsächlich etwas endeckt wurde. OpenCV auf nem Cortex-A5 dürfte nicht sonderlich viel Spaß machen. Ob das sinnvoll ist kann ich nicht genau sagen, das nutze ich nur auf schnelleren "Boliden" >800MHz und selbst da ist es oft zu lahm...
Hendrik S. schrieb: > OK. Also muss ich das Bild zuerst abspeichern, dann per RS485 > weiterleiten, empfangen, und per Wlan verschicken. Wieso eigentlich die Schnapsidee mit RS485, wenn die Wagen sowieso einen Ethernet-Kabelanschluss haben? Darüber Videodaten weiterzugeben wäre problemlos. Georg
Georg schrieb: > Wieso eigentlich die Schnapsidee mit RS485, wenn die Wagen sowieso einen > Ethernet-Kabelanschluss haben? Darüber Videodaten weiterzugeben wäre > problemlos. > > Georg Falls ein Fahrzeug ausfällt, braucht man bei RS485 keine aktiven Komponenten wie bei Ethernet. RS485 wird auf dem Controller einfach durchgeschliffen. Das ganze ist für Steuerbefehle eine gute Sache, für Daten anscheinend nicht :D
:
Bearbeitet durch User
Hallo, Hendrik S. schrieb: > Ja der RS485 Bus ist Half-Duplex. Ich schaue mir das Thema PPP mal an, > habe bisher gar keine Erfahrung damit. Wie aufwändig wäre denn so eine > Lösung? PPP ist das Protokoll, womit man früher mal über eine serielle Leitung IP gefahren hat. Der - deutlich einfachere - Vorgänger dazu wäre SLIP (oder CSLIP mit Headerkompression). Beides sind Technologien, die genau einen Teilnehmer an jedem Ende erwarten (PPP = Point-to-Point Protocol). Da ihr die RS485-Leitung aber schon für andere Dinge (du erwähntest Sensordaten) benutzt, ist es vielleicht besser, die vorhandene Infrastruktur zu benutzen. Das heißt, ihr definiert drei neue Messages auf dem Bus ("Bild-Anfang, Nummer N, Typ T, Größe XxY, Farbtiefe Z", "Bild-Datenblock Nummer N", "Bild-Ende Nummer N, Prüfsumme Q"), und behandelt die einzelnen Bilder wie ganz normale Sensordaten. Das Fahrzeug mit der Kamera muss das Bild von der Kamera abholen und die Daten in kleine Blöcke schneiden, die sich übertragen lassen, evtl. eine kleine Prüfsumme oder einen Timestamp dazu. > Könnten man denn theoretisch mit diesem kleinen Prozessor eine Art > Bildverarbeitung machen? Hängt davon ab. Wenn die Kamera selbst schon JPEG auswerfen kann, dann behalte die Daten wie sie sind. Ansonsten reicht es u.U. schon, die Daten einfach durch die Zlib zu schicken oder selbst einen simplen RLE-Kompressor zu basteln. Das hängt vom Datenmaterial ab. OpenCV ist auf dem Cortex-A5 vielleicht nicht gerade das Mittel der Wahl. Für simple Objekterkennung (Binarisieren, dann Schwerpunkt) auf einem 640x480-Bild bei 30 fps war mir ein 1 GHz-ARM zu langsam. Mit 320x240 ging es gerade so. Gruß, Svenska
S. R. schrieb: > Da ihr die RS485-Leitung aber schon für andere Dinge (du erwähntest > Sensordaten) benutzt, ist es vielleicht besser, die vorhandene > Infrastruktur zu benutzen. Das heißt, ihr definiert drei neue Messages > auf dem Bus ("Bild-Anfang, Nummer N, Typ T, Größe XxY, Farbtiefe Z", > "Bild-Datenblock Nummer N", "Bild-Ende Nummer N, Prüfsumme Q"), und > behandelt die einzelnen Bilder wie ganz normale Sensordaten. > > Das Fahrzeug mit der Kamera muss das Bild von der Kamera abholen und die > Daten in kleine Blöcke schneiden, die sich übertragen lassen, evtl. eine > kleine Prüfsumme oder einen Timestamp dazu. Ja, das klingt doch nach einem Plan. Bleibt trotzdem noch die Übertragung per W-Lan. Zum PC besteht bis jetzt noch keine Verbindung die ich benutzen kann, also da bin ich frei was Lösungsvorschläge angeht. S. R. schrieb: > OpenCV ist auf dem Cortex-A5 vielleicht nicht gerade das Mittel der > Wahl. Für simple Objekterkennung (Binarisieren, dann Schwerpunkt) auf > einem 640x480-Bild bei 30 fps war mir ein 1 GHz-ARM zu langsam. Mit > 320x240 ging es gerade so. Hast du für die Binarisierung auch OpenCV benutzt?
:
Bearbeitet durch User
Ich würde RS485 mit 100Mbit Ethernet ersetzen und einfach mit den W-Lan's eine Ethernet-Brigde bauen (mit STP protokoll).
asdf schrieb: > Ich würde RS485 mit 100Mbit Ethernet ersetzen und einfach mit den > W-Lan's eine Ethernet-Brigde bauen (mit STP protokoll). Das geht leider nicht. Die Controller haben nur eine Ethernet-Buchse die dann von der Kamera bennutzt wird. Wie schon erwähnt sind die Controller fertig entwickelt und ich muss mit den vorhandenen Schnittstellen auskommen. LAN -> RS485 -> WLAN
Hendrik S. schrieb: > Das geht leider nicht. Die Controller haben nur eine Ethernet-Buchse die > dann von der Kamera bennutzt wird. Kleiner Switch dazwischen? Über RS485 Megabytes von Daten in Sekundenbruchteilen zu übertragen kannst Du Dir von der Backe putzen. > Wie schon erwähnt sind die Controller > fertig entwickelt und ich muss mit den vorhandenen Schnittstellen > auskommen. LAN -> RS485 -> WLAN Zuerst wird die Hardware entwickelt und dann erst übers Konzept nachgedacht?!? Als erstes empfehle ich Dir, den Projektleiter zu feuern. Er ist untauglich für den Job.
Frank M. schrieb: > Über RS485 Megabytes von Daten in Sekundenbruchteilen zu übertragen > kannst Du Dir von der Backe putzen. Das habe ich auch nicht vor. RS485 mit 10MBit/s wären grob 3 Bilder/s bei meiner Auflösung (umkomprimiert 8Bit/px). 1 Bild/s würde mir für den Anfang aber auch schon reichen. Frank M. schrieb: > Zuerst wird die Hardware entwickelt und dann erst übers Konzept > nachgedacht?!? > > Als erstes empfehle ich Dir, den Projektleiter zu feuern. Er ist > untauglich für den Job. Die Kamera ist nur eine Erweiterung zu einem fertigen Projekt. Es war nie geplant Bilddaten über das System zu schicken.
Hendrik S. schrieb: > Das habe ich auch nicht vor. RS485 mit 10MBit/s wären grob 3 Bilder/s > bei meiner Auflösung (umkomprimiert 8Bit/px). 1 Bild/s würde mir für den > Anfang aber auch schon reichen. Sind immer noch 3MBit/sec bei 1 Bild/sec über RS485. Vergiss es. > Die Kamera ist nur eine Erweiterung zu einem fertigen Projekt. Es war > nie geplant Bilddaten über das System zu schicken. Es geht nicht. Finde Dich damit ab und denke über Alternativen nach. Wenn der Controller nur einen ETH-Port hat, nimm einen ETH-Switch dazu.
Frank M. schrieb: > Sind immer noch 3MBit/sec bei 1 Bild/sec über RS485. Vergiss es. Unkomprimiert. Daher: Nachschauen was die Kamera anbietet. ein 64kBit h264-Stream geht bestimmt noch irgendwie mit über die Leitung. Zwar dann mit vielen Artefakten, aber zum Anschauen sicher noch irgendwie tauglich. Nur besch**** wenn der "Empfänger" da noch Bildverarbeitung, Objekterkennung etc. machen will. OpenCV wurde schon genannt. Das schluckt zwar auch einen komprimierten Videostream, aber starke Artefakte stören trotzdem.
Wäre es nicht sinnvoller, den Linux-Geräten ein WLAN-Mesh Protokoll beizubringen, welches dann die Verbindung zum Host-PC selbsttätig "Verlängert"? Die Jungs von Freifunk haben damit eher Erfahrung, auch auf wenig leistungsfähiger Hardware - schliesslich sind die gängigen WLAN-Router, die da verwendet werden auch eher auf Kosten als auf Leistung getrimmt. Die Software, die dazu verwendet wird, nennt sich batman - siehe hier: https://wiki.freifunk.net/BATMAN-Konfiguration _.-=: MfG :=-._
Hendrik S. schrieb: > Beide haben zwar eine WLAN Antenne, sind > aber nicht ständig mit dem Netzwerk verbunden. Das allein ist doch schon barer Unsinn. Wenn das gekoppelte Waggons sind, wird es sich doch noch hinkriegen lassen, auf 2 m Entfernung eine Wifi-Verbindung aufrecht zu erhalten, und wenn der Zug durch die Hölle fährt. Es genügt eben nicht, ein unbrauchbares Konzept mit ungeeigneten Mitteln zu verbessern. Georg
Hendrik S. schrieb: > Ja, das klingt doch nach einem Plan. Bleibt trotzdem noch die > Übertragung per W-Lan. Zum PC besteht bis jetzt noch keine Verbindung > die ich benutzen kann, also da bin ich frei was Lösungsvorschläge > angeht. Da hast du im Zweifelsfall zwei Möglichkeiten: - du verpackst die RS485-Pakete in IP-Pakete und schickst die so; +: Du kriegst die Sensordaten auch gratis auf deinen PC. -: Der PC muss mit jeder RS485-Meldung irgendwie klarkommen. - der Empfänger stückelt die Pakete zusammen und schickt nur Bilder; +: Das WLAN enthält nur die Bilder, keine sensitiven Sensordaten. -: Der Empfänger braucht genug Speicher, um mehrere Bilder zu puffern. Was du wählst, hängt vom Anwendungsfall ab. Für ein Forschungs-/Bastel-/Unisystem sind die Ansätze gerade gut genug, aber erwarte keine Erweiterungsmöglichkeiten mehr. Für ein Produktivsystem ist schon der Ansatz scheiße, wie dir schon gesagt wurde: RS485 ist das falsche Medium. Außerdem musst du die Prioritäten richtig setzen können, sonst blockiert dir die Bildübertragung die Leitung so sehr, dass deine Sensordaten nicht mehr durchkommen. Ein besserer Ansatz: Der Access Point fürs WLAN fährt auf einem der Waggons mit, alle Waggons sind ständig mit dessen WLAN verbunden. Die Bilder überträgst du dann immer, wenn eine Verbindung zum PC da ist, bei Aussetzern werden die Bilder automatisch im Betriebssystem gepuffert. Oder du setzt auf der Strecke ein paar Repeater ein. > S. R. schrieb: >> OpenCV ist auf dem Cortex-A5 vielleicht nicht gerade das Mittel der >> Wahl. Für simple Objekterkennung (Binarisieren, dann Schwerpunkt) auf >> einem 640x480-Bild bei 30 fps war mir ein 1 GHz-ARM zu langsam. Mit >> 320x240 ging es gerade so. > Hast du für die Binarisierung auch OpenCV benutzt? Ja, für die Schwerpunktsberechnung auch. Allerdings galt das nur, wenn die Kamera auch einen YUV-Stream ausgegeben hatte (OpenCV hat immer MJPEG genommen und dekodiert, was grundsätzlich zu langsam war). Am Ende habe ich die Daten selbst aus der Kamera gepopelt und als Graustufenbild in OpenCV injiziert.
Du bist doch an der Uni und ihr habt doch das Wissen mit Löffeln gefressen. Wie wäre es wenn Du RS485 durch nen IIC-Bus oder One-Wire-Bus ersetzt? Frag mal Deinen Projektleiter, was er von der Idee hält.
Uni'Gscheitle schrieb: > Wie wäre es wenn Du RS485 durch nen IIC-Bus oder One-Wire-Bus > ersetzt? Frag mal Deinen Projektleiter, was er von der Idee hält. Ah so... also solange immer schlechter werdende Vorschläge machen, bis der Projektleiter seinen Fehler einsieht und das RS485 auch entfallen kann.... Könnte funktionieren. Also weiter, bei One-Wire ist noch lange nicht Schluss: I2S oder Midi. ... NMEA 183 ... Telefonleitung mit Analog-Modems. ... ... Farbdrucker bei Kamera druckt jedes Bild aus, Roboter-Arm plaziert Ausdruck neben Bahn, letzter Wagon greift die Zettel wieder und jagt sie durch einen Scanner. ... Funker fährt mit der Kamera mit, und verschickt textuelle Bildbeschreibungen per Morsecode und Knallfunkensender. ... Anhand des Punktes, bei dem der Projektleiter seinen Fehler einsieht, kannst du seine Unfähigkeit gemäß der nach oben offenen BER-Skala ermitteln.
Also ich fände ja Bongo Trommeln schick. Ist auch drahtlos und kommt relativ weit, evtl. sogar durch geschlossene Türen!
> Funker fährt mit der Kamera mit, und verschickt textuelle > Bildbeschreibungen per Morsecode und Knallfunkensender. Ich denke nicht, dass das mit dem WLAN gut zusammen funktioniert. Evtl. wäre eine Infrarot-Übertragungsstrecke besser. Wenn man dann z.B. 8 (16, 32 oder 64) Sende-Dioden mit jeweils unterschiedlichen Frequenzen betreibt, kann man ggf. sogar die Bandbreite soweit erhöhen, dass das mit der Bildübertragung evtl. doch noch was wird. Oder das Bild auf einem kleinen LCD am Ende des Wagons wiedergeben, was dann der andere Wagon mit Kamera+Zoom-Linse aufnimmt und via WLAN zur Verfügung stellt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.