Guten Tag zusammen! Ich bin neu in diesem Forum und weiß, dass dieses Thema schon oft behandelt wurde. Nach mehreren Stunden mit der Forensuche bzw. dem Lesen von etlichen Threads bin ich allerdings nur bedingt schlauer. Das Projekt ist folgendes: Erstellen einer kleinen Platine (Grundfläche nicht viel größer als 6x8cm, Höhe max. 10cm) mit folgenden Fähigkeiten - zwei Weitwinkelkameras, möglichst hochauflösend - Digitalisierung der Signale - Komprimierung (ich vermute es empfiehlt sich H.264, evtl. auch MPEG2 oder MJPEG) - Senden per WLAN - Kostenpunkt <500€ Leider kenne ich mich weder mit Kamerasystemen noch Hardware sonderlich gut aus, allerdings bin ich dabei mich nach und nach in die Themen einzulesen. Als ersten Schritt würde mich interessieren in wie weit eurer Meinung nach das Projekt möglich ist und ob mein allgemeines Verständnis bzw. mein Lösungsansatz in die richtige Richtung geht. Dieser sieht folgendermaßen aus: Kameras: 1280x960, PAL/NTSC, http://www.wondcam.com/170-degree-wide-angle-micro-camera-5-0-mega-pixel-camera.html Digitalisierung: Da die Auflösung 1280x960 HD720p entspricht brauche ich ICs die damit umgehen können. D.h. dieser hier wäre z.B. nicht geeignet, oder? http://de.farnell.com/rohm/bu9969kn-e2/digital-video-encoder-vqfn36/dp/1716173 Der einzige passende den ich bisher gefunden habe ist http://de.farnell.com/analog-devices/adv7441abstz-5p/ic-decoder-digitizer-144lqfp/dp/2070539. Ist das korrekt so, oder sehe ich da etwas falsch? Komprimierung: Man könnte nun entweder zwei getrennte ICs für Digitalisierung und Komprimierung benutzen, oder aber auch beides in einem IC. Hierzu habe ich zwei Stück gefunden, die meiner Meinung nach brauchbar scheinen http://www.intersil.com/en/products/audiovideo/security-surveillance/codecs/TW5864B1.html http://www.intersil.com/en/products/audiovideo/video-decoders-encoders/codecs/TW5866.html Senden per WLAN: Damit habe ich, abgesehen von ein paar kurzen Gedanken zur benötigten Bandbreite, noch nicht näher beschäftigt, da ich vermute, dass es dafür einige bekanntere Lösungen gibt. Über Vorschläge würde ich mich freuen. Das ist mein aktueller Stand der Planung nach zwei Tagen und ich würde mich über Feedback bzgl. Machbarkeit und meinen vorgeschlagenen Komponenten freuen. Bevor das Thema analoge Videoübertragung wie in vielen anderen Threads wieder aufkommt sei gesagt, dass mir diese Möglichkeit bewusst ist. Allerdings sind die Vorgaben für das Projekt nach Möglichkeit digitale Übertragung zu nutzen. Die Reichweite spielt dabei kaum ein Thema, denn sie muss maximal bei 10m im Raum auf Sicht funktionieren - Kabelverbindung ist jedoch ausgeschlossen, da das ganze auf mobilen Platformen installiert werden soll. Schonmal vielen Dank im Voraus für euer Feedback!
Warum keine IP-fähige Kamera? Diese an einen WLAN-Router und gut ists.
Wenn die Baugröße, Videoqualität, Energieverbrauch und Preis passen wäre auch das möglich. Die Anforderungen für die Kameras sind: - Stereokamerasystem, d.h. beide Kameras nebeneinander bei einer Gesamtbreite von <7cm - Weitwinkel mit >130° - Auflösung min. 1280x960 - niedriger Energieverbrauch, Betrieb über Batterie, Spannung <12V - Preis pro Kamera (inkl. Übertragung) ~ <200€ Bisher habe ich noch keine IP-fähige Kamera gefunden, die diesen Anforderungen gerecht wird. Sollte da jemand eine Lösung kennen würde ich mich natürlich sehr freuen.
Mit dem RaspberryPi, einer WebCam, Wlan-Stick und dem motion Paket kann man eine IP-Kamera bauen. Allerdings ist beim RPi die USB Schnittstelle ein Nadelöhr und HiRes geht nur mit sehr niedriegen Frameraten. Nur so als Ansatz, die suche 'Raspberry Webcam' liefert viele Treffer. Den RPi dann evtl. durch etwas leistungsfähigere Hardware ersetzen. Es gibt Alternativen mit mehr USB Power, aber die kann ich jetzt nicht auf Anhieb nennen. BeagleBoard / BeagleBone evtl.?
Danke für deine Antwort. Ich habe beim Lesen gemerkt, dass ich keine min. Framerate angegeben habe...diese sollte min. 25 sein. Ich meine einige Probleme bei dem RaspberryPi-Ansatz zu sehen: 1. die von dir angesprochen USB Schnittstelle...spätestens wenn zwei Kameras dran hängen wird das wohl nichtsmehr, oder man braucht 2 RaspberryPis 2. Webcams findet man in der Regel nicht mit Weitwinkel-Objektiven und i.d.R. sind die auch so verbaut, dass es schwer werden dürfte, ein passendes Objektiv anzubringen. 3. Es müsste eine Komprimierung auf Softwareebene in Echtzeit passieren, was vmtl selbst den RaspberryPi an seine Grenzen bringen dürfte (vermute ich). Falls ich mit meinen vermeintlichen Problemen falsch liege bitte ich um Korrektur von jemand der es besser weiß.
Ich habe mir die Geschichte mit der IP-basierten Kamera nochmal durch den Kopf gehen lassen und habe etwas recherchiert. Dabei habe ich folgendes gefunden http://www.alibaba.com/product-gs/767820508/GOING_5mp_megapixel_camera_ip_camera.html Allerdings weiß ich das Produkt nicht so ganz einzuschätzen. Es ist zwar per se nicht unbedingt Weitwinkel, aber das sollte sich durch eine entsprechende Linse beheben lassen. Was ich mich frage ist wie ich das ganze anspreche. Es steht zwar dabei, das es ein "802.11N wireless module" enthält, aber bei der Schnittstellenauflistung taucht das nichtmehr auf. Ebenso steht dort etwas von einem RJ45 Anschluss, den ich aber auf dem Bild nicht sehe (evtl. sind nur die entsprechenden Pins vorhanden und die Buchse muss selbst installiert werden). Hat jemand schon Erfahrung mit etwas in dieser Richtung?
ok, dafür ist der RPi zu schlapp. Mit den Anforderungen bist du aber auch eher im Segment für prof. Überwachungskameras. Wenn man so low-cost ActionCams oder DashboardCams ansieht muss es so kompakte Sensoren+Hardwarekomprimierung geben, aber die schreiben ja üblicherweise auf SD-Cards und funken nicht.
Sollen 130° die Sicht beider Kameras umfassen oder einer? wenn einer, also 65° pro Kamera reichen, wären 2 hiervon was für dich http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=40394&refid=SEM_30003&gclid=CPK0iMKywboCFUyV3godhgMATw
Die 130° sind pro Kamera, sonst wären es ja keine Weitwinkelkameras. Des Weiteren ist die Kamera mit 65mm deutlich zu breit für den Anwendungsfall (beide Kameras nebeneinander möglichst <65mm, absolute Grenze <85mm).
Hi Michael, habe in der Vergangenheit ein paar Kamerasysteme gebaut/evaluiert... Wird eng mit Deinen Anforderungen :-) Als erstes würde ich von der analogen Vorstufe absehen und gleich einen digitalen Sensor nehmen. Als nächstes musst Du das Flaschenhalsproblem lösen: zwei mal 720p kriegt man nicht so leicht in die gängigen Chips rein, da gibt es diverse Knackpunkte beim Interfacing (LVDS, MIPI vs. klassisch ITU-656 bzw parallel). Manche Sensoren sind allerdings von Haus auf Stereobetrieb eingerichtet. Für den WLAN-Versand kommt man am schnellsten mit einem Linux-Frontend vom Fleck, Stichwort RTP oder http für MJPEG. Mit h264-Chips wird's schwierig, ich hatte damals keine Chance, ein Einzelstück in die Finger zu kriegen. Musste schlussendlich für die Kompression ein FPGA plus DSP nehmen. MJPEG macht das Ding voll im FPGA SoC, MPEG nur in Verbindung mit dem DSP, die Full HD-Bandbreite ist damit aber nicht zu schaffen. Mit MJPEG wiederum liegt der Flaschenhals im 802.11.. Was verstehst Du unter Kostenpunkt? Endproduktpreis? Stückzahlen? Reine HW-Kosten? Die Entwicklung dauert auf jeden Fall min. 1-2 Mannjahre... Wenn es ein Forschungsprojekt ist: Am besten mal die Anforderungen drastisch runterskalieren und schauen, ob es auch mit weniger geht... Grüsse, - Strubi
Danke für deinen hilfreichen Beitrag Strubi. Per se wird es ja nicht verlangt, dass ich das alles selbst baue. Nach Möglichkeit würde ich das sehr gerne vermeiden, da es zum einen viel Zeit braucht und ich zum anderen auch nicht sonderlich fit darin bin (auch wenn ich genau das schon immer lernen wollte). Was meinst du genau mit den Problemen beim Interfacing? Einen entsprechenden Video Encoder der PAL/NTSC nach ITU-656 wandelt sollte ich doch das PAL/NTSC Signal, das ich von der Kamera bekomme, direkt geben können (so wie ich das bisher aus den entsprechenden Datenblättern entnommen habe). Chips die das Codieren des Videos übernehmen akzeptieren meiner Recherche nach meist ITU-656, d.h. ich könnte nach meinem Verständnis die Ausgabe des Encoders direkt an den Eingang hängen (von Steuersignalen jetzt mal abgesehen). Mit der Frage, wie ich das komprimierte Signal nun an das Board mit WLAN kriege habe ich mich noch nicht weiter beschäftigt. Wo gibt es denn dabei deiner Erfahrung nach Probleme bzw. was übersehe ich oder sehe ich falsch? Heute Mittag meine ich einen H.264 Chip einzeln gesehen zu haben, aber ich finde ich gerade nichtmehr. Unter Kostenpunkt verstehe ich Hardwarekosten. Das Ganze ist ein Uni Projekt, d.h. meine Arbeitszeit kriege ich nicht in Geld bezahlt ;) Ich möchte daraus auch kein serienreifes Produkt machen sondern ich brauche lediglich einen Prototypen. Darf ich fragen, worin deiner Meinung nach der Arbeitsaufwand von 1 bis 2 Mannjahren besteht? Das Projekt ist wie gesagt ein Uni Projekt. Die Vorgaben kommen von außen, sind aber denke ich durchaus diskutabel falls in keinster Weise realisierbar. Jedoch gehe ich davon aus, dass der Aufgabensteller sich besser auskennt als ich und daher auch keine unrealistischen Aufgaben stellt. Ich hatte ihn ganz zu Beginn auch schon auf die Möglichkeit der analogen Videoübertragung angesprochen, woraufhin er meinte, dass es digital besser fände. Wenn ich hinreichend belegen kann, warum digital nicht realisierbar ist ist denke ich auch eine analoge Übertragung akzeptabel. Da ich eine digitale Übertragung intuitiv jedoch nicht für unrealisierbar halte möchte ich gerne erst einmal in diese Richtung weiter forschen und verstehen, wo da genau die Probleme liegen.
Hi Michael, > Danke für deinen hilfreichen Beitrag Strubi. Bitte :-) > > Was meinst du genau mit den Problemen beim Interfacing? Einen > entsprechenden Video Encoder der PAL/NTSC nach ITU-656 wandelt sollte > ich doch das PAL/NTSC Signal, das ich von der Kamera bekomme, direkt > geben können (so wie ich das bisher aus den entsprechenden Datenblättern > entnommen habe). > Chips die das Codieren des Videos übernehmen akzeptieren meiner > Recherche nach meist ITU-656, d.h. ich könnte nach meinem Verständnis > die Ausgabe des Encoders direkt an den Eingang hängen (von > Steuersignalen jetzt mal abgesehen). Mit der Frage, wie ich das > komprimierte Signal nun an das Board mit WLAN kriege habe ich mich noch > nicht weiter beschäftigt. Wo gibt es denn dabei deiner Erfahrung nach > Probleme bzw. was übersehe ich oder sehe ich falsch? > Ok, ausgehend vom ITU/BT.656: Bei den meisten ADCs geht das über ein Parallel-Interface raus, bzw. in die verarbeitende CPU oder den HW-Codec. Ein digitaler Sensor spuckt das Format schon direkt aus. Wenn Du einen Chip findest (und auch in die Finger kriegst), der zwei Kanäle simultan verarbeitet, dann hast Du schon mal viel gewonnen. Der nächste Knackpunkt ist dann, wohin mit den Daten, also die Frage: über welches Interface gehen die komprimierten Daten raus. Ist es ein MIPI/CSI-Interface wie beim RPi, wird es schon mal kniffliger, das ist für den mittelständischen HW-Bastler schlechter zugänglich. Typischerweise habe ich komprimierte Daten über denselben Parallelport wie beim BT.656 rausgehauen, man muss dann nur im Frame die Blocklänge einbetten. Eine Linux-CPU verpackt dann die Pakete und haut sie ans WLAN raus. Dann gibt es ein kleines fieses Detail, das mich damals eine Menge Zeit gekostet hat: die Synchronisierung der Kameras. Kann u.U. blöd für die Nachverarbeitung werden, wenn links/rechts im Clock voneinander wegdriften. Inzwischen gibt es Chips, die speziell für die Stereo-Anwendung konzipiert sind. > Heute Mittag meine ich einen H.264 Chip einzeln gesehen zu haben, aber > ich finde ich gerade nichtmehr. > > Unter Kostenpunkt verstehe ich Hardwarekosten. Das Ganze ist ein Uni > Projekt, d.h. meine Arbeitszeit kriege ich nicht in Geld bezahlt ;) Ich > möchte daraus auch kein serienreifes Produkt machen sondern ich brauche > lediglich einen Prototypen. Darf ich fragen, worin deiner Meinung nach > der Arbeitsaufwand von 1 bis 2 Mannjahren besteht? > In den kleinen fiesen, nicht vorhersehbaren Details :-) Am meisten Zeit haben mich Bugs bzw. Timing-Probleme in den Sensoren gekostet, dazu kamen noch einige FPGA-Workarounds, um zwei Sensoren per i2c synchron konfigurieren zu können, plus Spezialwünsche vom Kunden. Wenn ich da so drüber nachdenke, fährst Du ev. mit einem puren Analogsensor mit fixem Timing ev. gar nicht mal so schlecht - es gibt dann einfach nix zu konfigurieren :-) Die meiste Zeit braucht eigentlich die stabile Datenübertragung, also keine verlorenen Frames und die Software dahinter (brauchbarer[!] Kernel-Treiber, videoserver). Also lose formuliert: Die Kamera liefert Standbilder nach einigen Wochen, und die Optimierung zum stabilen flüssigen Video kann mal ein halbes Jahr dauern.. Übrigens wurde die Stereo-Anwendung schlussendlich wegen grundsätzlicher Probleme (nicht umgehbare Designaspekte des Sensors) gekillt. Drum meine Meinung, das Ganze eher etwas weniger ambitioniert oder in kleineren Schritten anzusetzen, sonst kann es ev. frustrierend werden, und manche Lehrstühle neigen ja auch nicht selten dazu, im Rahmen von Technologietransfers motivierte Studenten zu verheizen. Aber ich würde es nicht für unmöglich halten, dass Du einen Kompressions-Chip findest, der viele Interfacing-Probleme für Dich löst. Würde mich dann freuen, davon zu hören. Viel Erfolg & Grüsse, - Strubi
Du kannst ja mal bei den gängigen Herstellern von Industriekameras reinschauen, was die im Angebot haben. Das wären AVT, Basler und IDS, die mir da jetzt so einfallen. Die produzieren Stückzahlen, und die Produkte sind durchaus preisoptimiert. Wenn die Produkte, die Du da findest, im Preis eine Zehnerpotenz höher liegen als Deine Vorgabe, dann sollte Dir das schon zu denken geben. Immerhin kaufst Du nur Deine Bauteile nur in Einzelstückzahlen ein, die aber in 10^3 bis 10^5 Stückzahlen. Das wäre also der erste Reality Check. Beziehe ruhig die Optik mit ein, denn das ist auch teuer, und dann weißt Du, was Du an Elektronik verbraten kannst. Zweitens: Wie groß ist denn der gesetzte Zeitrahmen? Was soll das werden? Diplom-/Masterarbeit? Studienarbeit? Gehe mal davon aus, dass bei den Herstellern Teams von 5-20 Leuten an so einer Kamera arbeiten, und ein komplett neues Modell wird da nicht einfach so in einem halben Jahr aus dem nichts entwickelt. Was meinst Du denn, wie lange Du für so etwas banales wie das Leiterplattenlayout brauchst, wenn Du 8 oder 10 Layer hast, ein fettes FPGA mit 400 Balls im 0.5mm Raster und beispielsweise 2 oder 4 DDR3-SDRAMs hast, wo alle Verbindungen die gleiche Länge haben müssen. Da sitzt auch ein Profi einen guten Monat an einem komplettes Design, bis alles so ist, wie es sein soll. Und Du als Anfänger darfst diese Zeit stumpf verdreifachen. Mindestens, weil das erste Board mit Sicherheit nicht funktionieren wird. Die Leiterplatten werden im Übrigen ins Geld gehen. 8 Layer als Einzelstück, ja 200€ sind da gar nichts. Bis Du den Kamerachip zum Laufen gebracht hast, kann das auch dauern. CMOS ist noch einfach, CCD hingegen ist heftig. Allein für die Kopplung zwischen Sensorchip, FPGA und RAM können Monate draufgehen, und dann hast Du noch keine Software, kein WLAN, und keine Kompression. Von daher halte ich die Abschätzung von Martin S. über zwei Jahre keinesfalls für untertrieben. Jemand, der Plan von der Sache hat, kann das in der Zeit schaffen, völlig unmöglich ist das nicht. Und dann musst Du ja noch an die schriftliche Ausarbeitung denken. Bei einer Diplom-/Masterarbeit plant man 3 Monate für das Vorhaben und 3 Monate für die schriftliche Ausarbeitung ein. Besser ist das, denn nach 180 Tagen ist halt Schluss, und wenn Du am 181. Tag abgibst, bist Du leider durchgefallen. So war die Regelung jedenfalls zu meiner Zeit (und das war im letzten Jahrtausend). fchk
Hubert G. schrieb: > Warum keine IP-fähige Kamera? Diese an einen WLAN-Router und gut ists. "WLAN-Router" ist Humbug. Du meinst sicher "Accesspoint"?
Man sollte noch dazu sagen, dass der Martin schon etwas länger
Entwicklungsarbeit macht... Also wenn so jemand da schon auf
"Schwierigkeiten" stößt und Du bisher wie Du selbst sagst kaum Ahnung
davon hast - dann sind 1 - 2 Jahre sogar noch sehr optimistisch. ;-)
> ... Video Encoder der PAL/NTSC ...
PAL ist AFAIR 702x576px oder sowas.
NTSC war 720x480px.
Kameras nur mit PAL/NTSC Analogausgang können gar keine HD Formate
ausgeben!
Egal was da für ein Sensor drin ist ;-)
Entsprechendes gilt für die ganzen Komponenten die Du in Deinem ersten
Posting genannt hast - kannste so also direkt vergessen.
Analog geht das nur mit separaten Ausgängen für die Farbkomponenten...
so wie bei VGA.
Wenn es das nicht fertig gibt, dann kauf möglichst fertige IP Kameras
und tausch die Optik aus. Die Bilder sind dann halt nicht ganz synchron
aber es funktioniert wenigstens.
Andernfalls verabschiede Dich schonmal davon mit 500 Euro wegzukommen.
Es wird dann sowieso viel teurer und dauert mindestens so lange wie
Martin gesagt hat und könnte auch einfach gar nix werden weil irgendwas
doch nicht so einfach geht wie gedacht ;-)
Vielen Dank für eure umfassenden Antworten. Das Projekt ist ein etwas umfangreicheres Praktikum an dem 3 Personen 3 Monate lang etwa 1 1/2 Tage pro Woche arbeiten sollen - allerdings gehört da auch noch eine Softwarekomponente dazu, die auf den Videosignalen arbeitet. D.h. es sind etwa 25 Manntage verfügbar. Damit scheint wohl der Ansatz mit eigener Platine komplett auszuscheiden. Bleiben für mich nurnoch zwei Optionen: 1. Fertige IP-Kameras mit digitaler Übertragung über WLAN so wie das hier http://www.alibaba.com/product-gs/767820508/GOING_5mp_megapixel_camera_ip_camera.html Hat jemand in diese Richtung schon Erfahrungen und/oder kann mir etwas dazu sagen ob das für mein Vorhaben geeignet ist. 2. Analoge Videoübertragung, z.B. mit folgenden Komponenten: Kamera http://www.hobbyking.com/hobbyking/store/__32024__hd19_explorerhd_full_hd_1080p_fpv_video_camera_with_integral_recorder.html Übertragung http://www.aliexpress.com/store/product/Plug-N-Play-5-8GHz-200mW-video-transmitter-for-FPV/505678_497477406.html Framegrabber http://www.stemmer-imaging.de/de/produkte/serie/DALSA.PC2-Comp#tags/|Analogue|PCIe| Wären die Komponenten der beiden Ansätze brauchbar eurer Meinung nach? Und wo seht ihr Vor- bzw. Nachteile? Zum Thema PAL/NTSC und 720p. Ich habe mich auch schon gefragt, wie das gehen soll. D.h. für meine beiden Ansätze, dass wohl Ansatz 1 davon nicht betroffen wäre, Ansatz 2 jedoch stark. D.h. wenn ich analoge Übertragung nehme komme ich nicht über die PAL/NTSC Qualität hinaus, außer ich finde passende Kameras, die andere analoge Signal verwenden (falls es das gibt).
Hi Michael, so ganz auf die Schnelle als Echo: Die Dinger von alibaba sind oft schlecht in kleinen Stückzahlen zu kriegen... Günstige Asia-IPcams habe ich ein paar getestet, aber alle hatten ein massives Latency-Problem, das Bild hinkt der Realität teils bis zu einer Sekunde nach. Wenn WLAN kein Muss ist, ist die Analog-Übertragung nach wie vor die simpelste. Ansonsten gibt's da noch aufwendige Spässe per UDP, siehe RFC2435. Für 720p fällt mir gerade nix simples im Analog-Bereich ein, ausser alte klobige Dinger mit mindestens 4 Koaxsteckern :-) Ich hätte einen ganz simplen Vorschlag zur Evaluation: 1) kleinen Embedded-PC mit 3 USB-Ports hernehmen 2) Zwei Logitech C525 oder ähnlich anhängen 3) Ralink/Realtek basierten USB-Stick für WLAN 4) Das ganze unter Linux per vl42/uvcvideo zum Laufen bringen 5) Bilder mit JPEG-Encoder packen und als MJPEG-Movie per Webserver-Mimik raushauen So, das klingt jetzt radikalfies: Das wird schon mal potentiell schiefgehen. Knackpunkte: USB-Flaschenhals (integrierte Hubs machen Ärger). Mit einem RPi wird es vermutlich nicht simultan klappen, oder vielleicht nur bei QVGA stereo. Der nächste Flaschenhals liegt dann beim Encoding, auch mit Assembler-Optimierung wird's ev. für 2xPAL-Format sehr eng. Mit einem flotten ARM dualcore (z.B. Tegra 2) sollte es allerdings gehen. Was Ihr dann als nächstes angehen könntet: Einige Webcams wie die C920 können h264, aber vermutlich nur unter Windows. Das ist dann eine nette Übung, das Protokoll reverse-zu-engineeren und unter Linux anzusprechen. Andere Kameras haben auch JPEG-Encoder direkt auf dem Sensor, aber oft ist das auch für den Endnutzer komplett undokumentiert. Wird also tendentiell eine entweder hardware- oder softwarelastige Sache. Und damit der Spass am Samstag Abend nicht zu kurz kommt, stellt Dich nun die Herzblatt-Susi vor die Wahl: 1) die weichherzige Programmiererin, die auf den Klo einen ganzen Schrank voll RFCs stehen hat und jedes Problem mit einem bash-Zweizeiler löst, oder 2) die latzhosenbewehrte Anpackerin, die jede Highspeedplatine beim Frühstück designen kann und dutzende OPV-Typen in der Nachttischschublade liegen hat... Und nun warten wir auf die Wand.. Schönes WE, - Strubi
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.