Druckbare Version
hallo,
besitzt hier jemand die Pixy Cam (cmucam5) und hat sie erfolgreich an Arduino Mega/Due per I2C-Ports (D20+D21) oder auch an UART-Pins (D18+D19) angeschlossen?
Üblicherweise wird ja der SPI-(ICSP-) Header verwendet, nur den möchte ich für andere Zwecke reservieren.
Theoretisch soll es ja wohl gehen, nur: hat das wer schon gemacht ohne das Standard-SPI-Header-Kabel?
update:
es geht prinzipiell per UART, führt aber (edit: ) bei zunehmend längeren Kabeln zu extrem vielen Übertragungsfehlern, sodass rund 50% aller Pixy-Daten unleserlich (corrupted: checksum error!) sind.
I2c ist sogar noch empfindlicher und fehleranfälliger:
http://www.mindstormsforum.de/viewtopic.php?f=78&t=9110
Habe ich durch I2C nicht irgendwelche Verluste? Ich meine ich habe hier im Forum mal einen Beitrag dazu gelesen, dass man da eine Fehleranfälligkeit bekommt durch andere Schnittstellen als SPI.
auf kurze Entfernungen (bis ca. 20cm Kabel) macht das keine so extremen Unterschiede nach meiner Beobachtung, sondern erst, wenn die Kabel deutlich länger werden. Ich hatte seinerzeit ca. 100cm lange Kabel benutzt.
- - - Aktualisiert - - -
zur Ergänzung, da der alte Forumslink mit meinem Pixy-Test derzeit down ist, hier meine damalige Test-Beurteilung:
Zitat:
Beurteilung:
Unsinnig und kritisch:
- die Pixy wird per i2c als Slave betrieben, trotzdem hat sie eingebaute Pullups auf +5V:
Pullups aber hat üblicherweise nur der i2c Master, nicht irgendein Slave (wichtig bei 3.3V MCU sowie ohne oder mit eingebauten, insb. hochohmigen Master-MCU-Pullups)!
- SPI läuft ohne SS-Pin, daher Konflikte und Störungen mit weiteren SPI-Geräten (TFT, SD).
- Kein Beispielcode verfügbar, wie man Pixy mit SPI und SS-Pin verwendet, um weitere SPI Geräte zusätzlich anschließen zu können.
- mit längeren SPI-Kabeln als dem kurzen, mitgelieferten, erhält man zunehmend mehr Übertragungsfehler (erkennbar an Checksum errors).
- die Pixy-SPI-Libs takten offenbar den SPI-Bustakt herunter, per SPI clock divider, was die Übertragungsrate zusammen mit weiteren SPI-Geräten am selben Bus zusätzlich unnützerweise verlangsamt.
- es geht prinzipiell zwar auch per UART, führt aber sogar zu noch viel mehr Übertragungsfehlern als SPI, sodass rund 50% aller Pixy-Daten unleserlich sind (corrupted: Checksum errors! - bei längeren UART-Kabeln sogar noch zunehmend mehr).
- I2c ist sogar noch empfindlicher und fehleranfälliger als UART.
- Checksum errors bei Übertragungsfehlern lassen sich generell nicht programm-mäßig erfassen, z.B. zählen und auswerten:
- Checksum errors tauchen nur als sporadische Meldung im Serial-Monitor auf, wenn der PC zusätzlich per USB am Arduino angeschlosssen wird und der Serial-Monitor aktiviert wurde, das geht aber natürlich nicht bei autonomem Betrieb.
Beurteilung der Detektions-Leistung:
- Farbenerkennung nur in der Nähe in farbneutraler Umgebung, ansonsten extreme Störung durch "ähnliche" Hintergrund- oder Umgebungsfarben
(Beispiel: orange, pink oder magenta gegenüber rot, violett gegen blau, cyan gegen grün, beige oder hautfarben gegen gelb oder orange)
- Farben wie die Lego-Standard-Farben blau + grün werden extrem schlecht erkannt, wenn die Beleuchtung nicht absolut optimal ist (keine Spiegelungen und indirektes, sehr helles Licht von allen Seiten)
- Farbobjekte in Entfernung von über 2m werden ebenfalls sehr schlecht und unzuverlässig erkannt, ganz besonders gilt das für Color Code-Erkennung
- sehr schlecht detektierte+selektierte Color Code Labels, extrem verrauscht: Farbcode Labels wie 1-2-3 werden häufig als 1-2 oder 2-3 verstümmelt, verschwinden komplett, oder erscheinen auch als 1-2-3-1 Artefakte, daher können sie im Programm dann überhaupt nicht zugeordnet werden (im Cooked Mode scheinbar OK, im Default Programm per Arduino dann aber völlig fehlerhaft)
- sehr schlechte Trennung nebeneinander stehender Color Code Labels, oft fälschlich als nur 1 großer Block fehlinterpretiert statt 2er getrennter
- keine Möglichkeit, die "Farben" schwarz und/oder weiß anzutrainieren, daher keine Chance für weiße Rubik's Cube Flächen oder Verfolgung schwarzer Linien
- keine Möglichkeit, Barcodes oder April-Tags zu erkennen
- keine Formenerkennung (Rechtecke vs. Kreise, Dreiecke, Pfeile etc. oder sogar Gesichter)
- völlig ungeeignet, um Altagsgegenstände in einer normalen Wohn-Umgebung eindeutig zu detektieren (Cocacola-,Fanta-, Bier- oder Wein-Flaschen, Tassen, Gläser, Stuhl- oder Tischbeine, und z.B. ein diagonal liegender Buntstift erscheint nicht als schmales Rechteck sondern als großes Quadrat, genau wie ein Buch, ein Karton oder ein Ball).
Bleibt zu ergänzen, dass der Kundensupport von Pixy extrem miserabel ist: Steht irgend etwas nicht in den Übersichtsseiten und man fragt nach, bekommt man zunächst tagelang überhaupt keine Antwort, und wenn man nochmal nachfragt, kommt als Antwort nur ein Link zu dieser Übersichtsseite (wo ja bekanntermaßen die Frage nicht gelöst wurde), oder man bekommt als Antwort: es wäre absolut simpel, man solle es gefälligst selber lösen. "Guter" Kundensupport sieht IMO anders aus.