Hallo! Wie aus dem Betreff hervorgeht möchte ich eine kleine Kamera auf meinem Roboter installieren und die Bilddaten müssen von einem leistungsstarken Chip verarbeitet werden, bevor die Ergebnisse via I²C an den ATmega2560 (der hat sonst noch genug zu tun) weitergeleitet werden. Ein Raspberry Pi (Modell A) würde die Arbeit auf jeden Fall tun, programmieren würde ich am liebsten in C oder C++, geht mir beides zügig von der Hand. Da ich bloß überlege, das ganze in vielfacher Ausfertigung (für andere Roboter) zu bauen, sollte die bildverarbeitende Einheit möglichst kostengünstig sein. Welche Möglichkeiten gibt es da? Oder ist der Raspberry Pi die beste Möglichkeit? Die Kamera hat übrigens einen USB-Ausgang. Viele Grüße, Fabian
Fabian S. schrieb: > Wie aus dem Betreff hervorgeht tut es nicht abgesehen davon: Deine "Anforderungen" sind viel zu allgemein und nichtssagend, als das dir jemand ernsthaft helfen könnte, außer er kann sehr gut hellsehen...
Kommt ganz drauf an was du möchtest. Du schreibst du suchst "Hardware" für die Bildverarbeitung. Naja... da gibt's viel. Was du brauchst ist also ein halbwegs leistungsfähigen Prozessor mit USB-Host + das drum herum. Die Frage ist: Was willst du auf der Softwareseite? Willst du unter Linux arbeiten? Dann schau mal hier: [1]. Hier kannst du natürlich relativ schnell zu einem Ergebnis kommen und hast einfachen Zugriff auf entsprechende Libraries (z.B. OpenCV). Linux-Boards gibt es viele, es kommt auf deine Anforderungen an. Die Frage ist wie viele Ressourcen (CPU + Speicher) du brauchst. HDMI, Ethernet und den ganzen Schnickschnack des PIs brauchst du ja eigentlich nicht. Leider sind die Boards die ohne das ganze Geraffel daherkommen meist auch leistungstechnisch deutlich weiter unten angesetzt oder unverhältnismäßig teuer. Man kann das ganz natürlich auch auf "bare metal" aufziehen, sprich direkt auf dem Controller programmieren. Ich vermute aber mal auf dich wird ersteres zutreffen. [1] http://www.mikrocontroller.net/articles/Linux_Boards
:
Bearbeitet durch User
Es kommt zu 100% darauf an was du machen willst mit "Bildverarbeitung". Das ist wie wenn du sagst: Ich entwickle Elektronik. Das kann von LED mit Vorwiderstand bis zum Computermainboard oder 120 GHz Radar alles sein. Entsprechend auch die Komplexität. Da musst du schon mehr sagen und den Rechenaufwand abschätzen. Nur um dir ein Beispiel zu geben: Fix installierte Verkehrszählung und Fahrzeugklassifizierung mit OpenCV auf einer Verkehrsbrücke, 3 Spuren, 25fps = mittlere Workstation mit CUDA fähiger Grafikkarte auf Vollast. Rspberry Pi wird da bisschen schwach auf der Brust sein für solche Sachen. Oftmals verwendet man da dezidierte FPGAs, DSPs oder ImageProcessoren.
Rpi ist günstig, es gibt für Roboter aber ein kickstarter Projekt, wo ein ARM (stm32 glaube ich) dies erledigt. RPi ist nicht so günstig, hat keine Hardwarebeschleunigung welche unterstützt wird, ist problematisch in der Wartung usw da die HW Versionen unterschiedliche FW benötigen, hat keinen Resetbaustein und sollte die Versorgungsspannung zu tief sein, gibt es Probleme ... . Würde dir eher zu carambola raten, oder einem billig android tablet.
chris schrieb: > Rpi ist günstig > RPi ist nicht so günstig Ah ja :D chris schrieb: > Würde dir eher zu carambola raten Du weißt aber, dass die Carambolas mit <=400MHz und 32-64MB RAM daher "dümpeln"? Wie Carsten sagt: CV kann schon Leistung fordern (in Abhängigkeit davon was man vor hat). Wenn du nicht dauernd auf die verbleibenden Ressourcen schielen müssen willst würde ich mich (zumindest für den Prototyp, siehe unten) schon eher in der etwas stärkeren CPU-Liga umschauen (Cortex A: Freescale i.Mx, OMAP, oder, oder...). Wobei das jetzt nicht heißen soll, dass es der RPi nicht vllt auch kann - kann man wie gesagt schwer einschätzen. Aber wenn die HW Luft nach oben hat schadet das nicht. Fabian S. schrieb: > Da ich bloß überlege, das ganze in vielfacher Ausfertigung > (für andere Roboter) zu bauen, sollte die bildverarbeitende Einheit > möglichst kostengünstig sein. Ich würde zumindest für den Prototypen ein recht potentes Board nehmen, für die "Serie" nimmst du dann ein kleineres (falls dieses dann auch reichen sollte). Wenn du deine App. unter Linux schreibst musst du ja nur kleinere Anpassungen vornehmen, wenn du die HW wechselst.
:
Bearbeitet durch User
Ich weiß, dass der STM32F407 ein DCMI(DigitalCameraInterface)[1] hat, vielleicht hat das Raspi das auch? Könnte allerdings schwer werden, das in Gang zu kriegen. [1] >The digital camera is a synchronous parallel interface able to receive a >high-speed data flow >from an external 8-, 10-, 12- or 14-bit CM >OS camera module. It supports different data >formats: YCbCr4:2:2/RGB565 progressive video and compressed data (JPEG). >This interface is >for use with black & white cameras, X24 and X5 cameras, and it is >assumed that all pre-processing like resizing is performed in the camera >module. Reference Manual STM32F4xx
Was du sagst ist alles sehr unspezifisch, ich glaube mit den Informationen kann dir keiner helfen. Ich mache auch Bildverarbeitung unter Linux und nutze OpenCV. Ich beschreibe das mal etwas: Ich nutze einen AMD (Desktop) und Intel(Laptop) Dualcore zur Berechnung. Im Desktop-PC ist noch eine Grafikkarte drin die OpenCL tauglich ist. Ich nehme mit meiner Webcam ein 640x480 Pixel Bild auf und suche dort nach Rändern, vergleiche Farben und so, dabei sinkt die Anzahl der Bilder die ich verarbeiten kann auf unter 1 Bild pro Sekunde. Wenn ich zusätzlich meine Grafikkarte einsetzen würde kann ich ca. 5 bis 10 Bilder pro Sekunde verarbeiten. Wenn das Bild größer ist, z.B. 1280x960 Pixel habe ich nur noch 1/4 der Leistung. Wenn ich aber mehr Details aus dem Bild bekommen möchte steigt der Rechenaufwand weiter an. Jetzt muss ich diese Linien noch mit bekannten Informationen (Mustern) vergleichen und sie mit gespeicherten Mustern vergleichen, das ist eine ganze Menge Arbeit so dass ich zum Schluss alles mit einer OpenCL fähigen GPU oder Grafikkarte machen muss um eine adäquate Bildrate zu bekommen. Vielleicht willst du aber auch nur jede Sekunde rausfinden ob sich in einem 320x160 Pixel großem Bild 20% der Pixel stark verändert haben, dann ist das nur eine Art Bewegungsmelder der nichts weiter berechnet und mit dem RaspBerryPi wohlmöglich machbar. Ich nehme aber mal an du willst so ein kleines Auto mit einer Webcam und einem RaspBerryPi ausstatten und dieses soll dann einen roten Ball folgen oder sowas, in dem Fall musst du das Bild mit dem RaspBerryPi aufnehmen, zum PC übertragen (per W-Lan), die Bilder auf dem PC verarbeiten und die Steuerungs-/Positionierungsaufgaben zurück zum RaspBerryPi schicken welcher dann das Auto entsprechend steuert.
Danke für die Antworten! Also der Roboter soll eigtl. bloß einer schwarzen Linie auf weißem Untergrund folgen. Die Kamera wird vlt. so 3MP oder so haben, aber davon wird höchstens jeder zwanzigste überhaupt verarbeitet. Die übrigen sind Datenmüll, der bei Zeiten wieder gelöscht/überschrieben wird. Das laufende Programm muss außerdem keine nicht mehr aktuellen Bilder aufbewahren, der Speicherplatz kann gleich wieder überschrieben werden. Auch der nichtflüchtige Speicher beschränkt sich auf Betriebssystem + Programm (+das ein oder andere Byte für Konfigurationen). Da der Roboter eine maximale Geschwindigkeit von 0,45m/s erreichen kann, die meiste Zeit jedoch eher 0,1m/s bis 0,2m/s fahren wird, strebe ich mal eine Bildauswerterate von so 10 bis 40 Hz an. Das ist zwar sehr weit gefasst, aber da muss ich mal sehen... Wie die Linienerkennung genau aussehen soll: Im Bild stelle man sich zehn horizontale Ebenen mit gleichem Abstand zueinander vor. Auf jeder dieser Ebenen soll dann die Linie erkannt werden. Die Breite der Linie ist irrelevant, nur die Position ihrer Mitte (auf der entsprechenden Ebene). Damit entstehen pro Auswertungsprozess 10 Punkte, deren Y-Koordinate ja schon vorgegeben ist. Wie der Mittelpunkt der Linie gefunden werden soll, weiß ich noch nicht genau, habe da mehrere Ansätze. Ein sehr primitiver Ansatz wäre einfach perfektes Weiß als 0 und perfektes Schwarz als 1 zu definieren und dann eine Häufigkeitsverteilung auf der Ebene zu betrachten und das Arithmetische Mittel zu berechnen. Aber vlt. sind die anderen Ansätze effektiver. Mal sehen... Folgende Hardware bleibt jetzt noch übrig: - Der Raspberry Pi Model A bleibt weiter im Rennen, auch wenn er mit SD-Karte etwa 35€ kostet... - Direkt auf einem ARM-Prozessor zu programmieren meide ich auch erstmal, "im Internet" wird davon auch eher abgeraten. - Das von chris erwähnte stm32 könnte mit seinen 192kB SRAM etw. knapp sein. - Bei dem Carambola bin ich mir auch nicht so sicher, 400MHz sind ja auch nicht die Welt. - Die Prozessoren, die Dominik S. erwähnt hatte, nehme ich jetzt mal unter die Lupe. Viele Grüße, Fabian
ihr elendigen Verschwender... ;) http://www.roboternetz.de/community/threads/29906-Minimall%C3%B6sung-Kamera-f%C3%BCr-den-RP6?p=283010#post283010 wenn es wirklic nur um eine schwarze linie geht dann kan man da ganz ordentlich sparen. sg
zoggl schrieb: > ihr elendigen Verschwender... ;) > > http://www.roboternetz.de/community/threads/29906-Minimall%C3%B6sung-Kamera-f%C3%BCr-den-RP6?p=283010#post283010 > > wenn es wirklic nur um eine schwarze linie geht dann kan man da ganz > ordentlich sparen. Selber Verschwender! http://www.heise.de/hardware-hacks/projekte/Simpelmobil-Robot-Spurt-1745722.html
ElmChan hat sowas auf einfacher Art und Weise schon realisiert. http://elm-chan.org/works/ltc/report.html
Sowas wird seit Jahren regelmäßig von Schülern in diversen Wettbewerben oder einfach so zum Spaß realisiert. Bausätze wie der ASURO hams direkt eingebaut (zwei Fototransistoren und eine Leuchtdiode... billig genug?).
Hallo, ich wollte nochmal klarstellen, dass ich speziell eine Kamera verbauen wollte. Erfahrungen mit Fototransistoren (auch in größeren Mengen) habe ich mehr als genug. Da gab es von mir schon diverse Linienfolger, von Lego bis Arduino und von zwei Lego-Lichtsensoren bis 8 Fototransistoren von Conrad. Der Link von zoggl war ziemlich hilfreich, jetzt suche ich erstmal nach einer günstigen Kamera mit Composite-Video-Signal-Ausgang. Die ganzen billigen Dinger (brauche ja kaum Bildqualität) haben bloß alle einen USB-Anschluss. Bin am Recherchieren. Viele Grüße, Fabian
Nur mal so, aus Neugier gefragt: Meinst du, dass es noch deutlich günstiger als ein Raspberry mit Kamera-Modul geht? Z.B. 38€ bei Watterott für "Raspberry Pi Modell A (256MB RAM) + Raspberry Pi Kamera v1.3 (Set)".
Zu Konrads Frage: Mit der SD-Karte und Versand wären das dann ca. 50€ und das finde ich für so eine Aktion auch sehr günstig. Dennoch frage ich mich weiterhin, ob es nicht noch einfacher/günstiger/kleiner geht. Noch beschäftige ich mich ein bisschen mit Composite-Video-Signal plus AVR, aber ansonsten läuft es sicherlich darauf hinaus! Viele Grüße, Fabian
Dominik S. schrieb: > chris schrieb: >> Rpi ist günstig >> RPi ist nicht so günstig Ich wollte sowas schreiben wie, er ist der Günstigste mit moderater Rechenleistung, da ihm jedoch der NEON Coprozessor fehlt, welche eine 12Fache Geschwindigkeit rausholen, ist sein Preis/Leistungsverhältnis nicht so toll. Bei Gauss, Fourier, Soebel usw ist dieser Unterschied da. Ohne Neon Optimierung ist es aber das gün Ein Beispiel, Beagle Board 30fps. Rpi 1.2 fps. Carambola 5.6 fps. Interessant ist auch der Olimexuino mit A10, bzw Upgrade auf A20. Preislich ok und der hat auch den NEON sowie weniger Probleme als RPI, ist aber nur in größerer Stückzahl interessant, was hier ja gegeben ist. Wenn nicht viele Pins gebraucht werden, dann kann man auch ein tablet mit A10 importieren. Vorteil von A10/20 ist, dass man die Pins remappen kann. So kann man z.B. RS232 / i2c usw auf den SD-Stecker rausführen. Rpi hat ein digitale camera interface, was jedoch nur über den DSP Prozessor ansprechbar ist, wo es null Spezifikationen gibt. Daraus folgt, dass nur die von RPI Foundation angebotenen Kamera
Günstiger: Mouse sensor, uC deiner Wahl mit spi, und Optik von Pollin. Ohne Versandkosten ca 3€, eventuell inkl. uC welcher die Auswertung macht und das Resultat auf i2c rausgibt.
Tatsächlich! Es geht sogar mit weniger als 20€! Auf das Ergebnis wäre ich aber mal gespannt... Hier ist eine Billigkamera mit geeignetem Ausgang: http://www.amazon.com/Vision-Reverse-Backup-Camera-LAB503/dp/B00HSHDCK8 Hier ist der 12V-Step-Up-Converter, eigtl. soll das ganze ja an einen 7,4V-LiPo angeschlossen werden: http://nodna.de/STEP-UP-12V-Spannungsregler-U3V12F12 Und zoggl hatte ja schon diesen Link gepostet: http://www.roboternetz.de/community/threads/29906-Minimall%C3%B6sung-Kamera-f%C3%BCr-den-RP6?p=283010#post283010 Und den ein oder anderen AVR kann man überall finden. Ich frage mich, ob das meinen Anforderungen entspricht... Viele Grüße, Fabian
ich habe einen RPi mit motion und einer MS USB LifeCam (Reichelt, 8,50€). Bei 640 x 480 bekomme ich nur 3-4 Frames/s, mehr geht durch den USB Flaschenhals beim RPi nicht durch. Das Pixelformat ist YUYV, vielleicht geht mehr mit MJPG, aber das unterstützt die Kamera nicht. Unterstützen 'bessere' Kameras das? Würde mich auch interessieren für ein flüssigeres streaming. Die 3MP die weiter oben genannt wurden sind jedenfalls schon ein sehr sportliches Ziel für die Sparhardware. Die Rückfahrkamera hat einen analogen Ausgang, das fehlt noch ein schneller A/D Wandler. Der RPi hat noch den Vorteil das man eine Shell hat über die man alles machen kann. Dateien transferieren, Behfehlsinterpreter, einfachen Webserver für Parametrierung muss man bei sparsamerer Hardware alles selber implementieren.
Angehängte Dateien:
-
Clipboard06.png
260 KB
ich habe mir die hier geholt, um mit einem AVR ein kleines LIDAR zu basteln. http://www.exp-tech.de/Sensoren/Optisch/JPEG-2M-Pixel-Color-Camera-Serial-Interface-TTL-level-.html Die kamera sitzt 100mm über dem boden und blickt 45° nach vorne. ein kleiner Servo schwenkt laser und kamera dann. damit könntest du den analogwandler umgehen. Ich würde aber mit dem jetzigen wissen eher DEUTLICH mehr hardware auf das problem werfen und mindestens einen IC mit ordentlich debugging schnittstelle verwenden. zudem kann so ein kleiner popel-MEGA8 auch nicht das gesamte bild einlesen sondern muss direkt im eingangsstream nach der linie suchen und bei der helligkeits/kontrastregelung total auf die kamera vertrauen (und das geht hin und wieder schief). bei voller Auslastung und je nach auflösung komme ich auf 2-6 Bilder die sekunde und um die 1000-2000 brauchbare Punkte/s (die ich aber im moment nicht schnell genug aus dem avr ruas bekomme). das Testbild ist mit 640*480 auswerten tu ich aber nur 480*200. (ja ich weiß ich hätte die kamera drehen können, die auflösung veringern und dann vertikal auswerten, dazu muss ich aber das ganze Bild in den AVR laden müssen) Fazit von dem Projekt: *Kamera ungeeignet, da es durch den rolling shutter bei bewegung nicht klar ist woher welcher punkt jetzt genau kommt. Kamera muss immer stoppen einlesen und dann weiterfahren, wenns gut werden soll ( dann ist aber nur noch 1 bilder/sec drin) *Prozessor zu klein und scheiße zu debuggen (und ich ein Anfänger mit begrenzten fähigkeiten) *Helligkeitsregelung der Kamera kommt mit dem hellen Laser durcheinander step 2: *Pi+Kamera ist bestellt *zum spass noch eine von denen hier bestellt und auch einen satz linsen mit verschiedenen Brennweiten dazu http://www.aliexpress.com/snapshot/6102966404.html *Laser mit mehreren parallelen Linien und einen mit Punktmatrix bestellt, das schwenken war eher ein irrweg. *passende Sperrfilter bestellt, die das umgebungslicht ordentlich blocken. sg und einen schönen Feiertag.
Carsten schrieb: > Nur um dir ein Beispiel zu geben: Fix > installierte Verkehrszählung und Fahrzeugklassifizierung mit OpenCV auf > einer Verkehrsbrücke, 3 Spuren, 25fps = mittlere Workstation mit CUDA > fähiger Grafikkarte auf Vollast. Na ja, früher hat man das mit 3*2 Entfernungssensoren gemacht. Dann reicht sogar ein alter C64 zur Signalverarbeitung...
Schreiber schrieb: > früher hat man das mit 3*2 Entfernungssensoren gemacht Wie will dein Auto oder Roboter-Pokemon damit einen roten Ball erkennen? Clemens S. schrieb: > *Pi+Kamera ist bestellt Und einen kleinen W-Lan Stick damit du die Bilder zu einem richtigen Rechner transportieren kannst, dort die Berechnungen durchführst und dann wieder Daten zum Raspi zurück schickst damit die IO-Pins entsprechend angesteuert werden und das Fahrzeug so bewegt wird, anders ist das meiner Meinung nach nicht machbar. Es macht überhaupt keinen Spaß wenn man ewig auf die Bildauswertung warten muss, auf der Grafikkarte kann man einen Sobelfilter blitzschnell auf ein Bild anwenden. Vielleicht kann man das Problem später so weit verkleinern dass die Software auch auf dem Raspi schnell genug läuft, aber das ist recht schwer da die Hardware sehr beschränkt ist.
Der Tipp von chris mit dem Maussensor war sehr hilfreich! Der AD2620 (https://www.sparkfun.com/products/12907) - ist lächerlich günstig, - 18×18 Pixel (also 324) sind hoffentlich ausreichend, - 6-Bit-Auflösung sollte für eine schwarze Linie auf einem weißen Untergrund schon fast mehr als genug sein (eine aktive Beleuchtung ist geplant) und - 324 Bytes SRAM sind auch nicht die Welt. - Die Übertragung per SPI an einen AVR ist auch sehr bequem. Was noch fehlt ist eine Linse, aber da wird sich schon irgendetwas auftun! Interessant ist auch, dass auf 324 Pixeln eine Linie eigtl. ganz gut zu erkennen sein sollte und ein AVR davon nicht gleich erschlagen wird. Und ich wollte eine richtige Webcam verbauen, verrückt... Sollte ich am Ende völlig enttäuscht sein, wären die Ausgaben von weniger als 10€ auch völlig OK. Ich bedanke mich noch mal ganz besonders für den Tipp mit dem Maussensor bei chris. In etwa einer Woche geht es dann an die Umsetzung, ich bin gespannt! Viele Grüße, Fabian
Der Maussensor sollte für das Linienfolgen schon ausreichen. Besser als 18 Einzelsensoren mit Fototransistoren sollte das schon sein - und das ist beim Limienfolgen schon fast Overkill. Allerdings wird es mit dem 8 Bit AVR noch etwas sportlich von der Rechenzeit, wenn man die Daten komplett auswerden will - schließlich ist der Sensor recht schnell (wenn man will). Da wäre der Raspi oder ggf. ein kleines ARM Board (z.B. mit STM32F3...) schon besser.
Wie viel ein 8-Bit-AVR mit den 324 Pixeln herumzaubern kann, weiß ich noch nicht richtig einzuschätzen. Ansonsten reicht es aber auch, wenn in der Vertikalen nur 5 bis 9 Reihen verarbeitet werden. Da der ADNS2620 selbst die Belichtungszeit steuert, lässt sich hoffentlich ganz billig mit Schwellwerten arbeiten. Ich bin am Bestellen! Fabian
Hallo nochmal! Der ADNS2620 ist viel zu langsam für meine Zwecke. Ich probiere jetzt mal die Variante "USB-Webcam plus Rasberry Pi". Da scheint der eine oder andere schon gute Ergebnisse erzielt zu haben! Viele Grüße, Fabian P.S.: Dieses Video dazu ist ziemlich beeindruckend: https://www.youtube.com/watch?v=AsoLF6NsqBI
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.