Probleme und schlechte Dokumentation der Pixy Cam

Atmel, PIC, VEX, Fischertechnik

Moderator: Moderatoren

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5398
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Probleme und schlechte Dokumentation der Pixy Cam

Beitragvon HaWe » 4. Feb 2015 09:29

hi,
wen es interessiert -
die Pixy Cam hat auf den ersten Blick zwar scheinbar viele neue Möglichkeiten, die Dokumentation ist aber leider auf unübersichlich strukturierte Wiki-Seiten verteilt (und versteckt) und es exisiert nur ein absolut simples Beispielprogramm z.B. zu SPI oder UART-Modus - mit dem Rest wird man allein gelassen oder aufs Pixy-eigene "Hersteller-Forum" verwiesen.
Leider sind die Entwickler aber auch im Forum nicht sehr auskunftsfreudig zu Problemen und geben z.B. keine Hilfe in Form von funktionierendem Code, sondern man muss tagelang warten bis überhaupt eine Antwort kommt und erhält selbst dann auch nur grobe Hinweise und Links, bei denen man sich die Lösung mühsam zusammensuchen muss (wenn man es überhaupt schafft) - absolut nicht geeignet für Anfänger.

Ich hatte die grundsätzliche Problematik ja bereits hier angesprochen - immerhin mit einem kleinen Start-Teilerfolg nach langem nervigen Herumprobieren und Herumfragen:
viewtopic.php?f=78&t=8508#p66139

Nach gezieltem Nachfragen bekam ich heute sogar eine Email, "andere User wären besorgt oder fühlten sich gestört" oder so ein ähnlicher Unsinn - die einzigen, die sich gestört fühlen, sind natürlich die Entwickler, die ihre Supportmängel nicht offengelegt haben möchten und nicht wollen, dass die ganzen Probleme öffentlich werden.
Regarding my message about your multiple posts. Three users have sent us messages expressing concern about your multiple posts.

Jetzt wird scheinbar Druck gemacht, um User, die Fragen und Probleme haben, auch noch mundtot zu machen. Mal schauen, ob sich der Verdacht bestätigt


Da kann ich nur sagen:
Wer schlechten Support bietet und dies nicht öffentlich werden lassen will, muss halt seinen Support verbessern - und auf Foren verzichten in der stillen Hoffnung auf "Problemlösung durch andere". Man kann sich doch wohl nicht so einfach aus der Verantwortung stehlen wollen und dann unliebsame Fragesteller mundtot machen wollen!

http://cmucam.org/projects/cmucam5/boards/9
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5398
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: Probleme und schlechte Dokumentation der Pixy Cam

Beitragvon HaWe » 4. Feb 2015 11:45

ps,
wohlgemerkt: seit über 1 Woche noch immer keine Lösung erhalten, weder wie man ColorCodes erfasst, noch wie man am SPI-Bus - wie üblich - mehrere Geräte anschließen kann, nachdem die Pixy Cam momentan den kompletten Bus für sich alleine blockiert!

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5398
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: Probleme und schlechte Dokumentation der Pixy Cam

Beitragvon HaWe » 6. Feb 2015 17:46

also langsam ist es zum laut "Sch******" schreien!

Die devs sind nicht in der Lage, einen verständlichen Beispielcode zu schreiben und zu posten, und wenn man sie fragt, wo man denn dann bitteschön im eigenen Code Anpassungen für den SPI-SS pin oder für die Auswertung des erhaltenen CC einfügen soll, dann kommt als Antwort:

Ich solle aufhören, die Leute zu nötigen dass die meinen Code schreiben!!

Also das schlägt doch echt dem Fass den Boden ins Gesicht. So eine bornierte Frechheit habe ich noch nicht erlebt!!

Update:
und JETZT gerade stellt sich heraus, nach über 1 Woche:
SPI mit SS pin geht überhaupt nicht, es sei denn man wäre professioneller Embedded-C-Programmierer und wäre in der Lage, die Pixy-C++ Libs selber zu hacken und umzuprogrammieren! Das kann ja wohl nicht deren Ernst sein!

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5398
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: Probleme und schlechte Dokumentation der Pixy Cam

Beitragvon HaWe » 26. Mär 2015 10:26

Die Pixy Cam sendet nach wie vor häufig falsche Daten und abgebrochene Daten und hängt sich auf!
das kann man sogar seitenweise im Pixy Forum nachlesen.
Ich halte das Ding inzwischen schlicht für unausgereift, darüberhinaus ist sie hundsmiserabel dokumentiert, es fehlen z.B. komplett die für die verschiedensten Funktionen notwendigen detaillierten Beispielprogramme insb. für Arduino.
Hier ein serial-log per UART (reorder= ~Datenübertragungsfehler, cs error=checksum error):

Code: Alles auswählen

Detected 3:
  block 0: sig: 1 x: 127 y: 100 width: 17 height: 32 angle 0
  block 1: sig: 1 x: 261 y: 125 width: 86 height: 19 angle 0
  block 2: sig: 2 x: 74 y: 165 width: 75 height: 20 angle 0
reorder
reorder
reorder
reorder
reorder
reorder
Detected 1:
  block 0: sig: 2 x: 283 y: 180 width: 14 height: 3 angle 0
reorder
Detected 2:
  block 0: sig: 2 x: 108 y: 187 width: 7 height: 10 angle 0
  block 1: sig: 3 x: 75 y: 174 width: 7 height: 9 angle 0
cs error
Detected 2:
  block 0: sig: 2 x: 109 y: 188 width: 8 height: 12 angle 0
  block 1: sig: 3 x: 97 y: 178 width: 8 height: 6 angle 0
cs error
reorder
Detected 3:
  block 0: sig: 2 x: 109 y: 188 width: 8 height: 10 angle 0
  block 1: sig: 3 x: 75 y: 174 width: 8 height: 10 angle 0
  block 2: sig: 3 x: 96 y: 176 width: 9 height: 8 angle 0
cs error
Detected 2:
  block 0: sig: 2 x: 108 y: 189 width: 7 height: 6 angle 0
  block 1: sig: 3 x: 97 y: 176 width: 8 height: 8 angle 0
cs error
Detected 3:
  block 0: sig: 2 x: 109 y: 187 width: 8 height: 9 angle 0
  block 1: sig: 3 x: 75 y: 174 width: 8 height: 9 angle 0
  block 2: sig: 3 x: 97 y: 175 width: 8 height: 3 angle 0
cs error
Detected 2:
  block 0: sig: 2 x: 109 y: 187 width: 8 height: 10 angle 0
  block 1: sig: 3 x: 97 y: 176 width: 8 height: 9 angle 0
cs error


ich habe daher jetzt die Retoure innerhalb der Garantiezeit eingeleitet.
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E

andi1965
Neuer Schreiber
Neuer Schreiber
Beiträge: 2
Registriert: 2. Jul 2015 09:30

Re: Probleme und schlechte Dokumentation der Pixy Cam

Beitragvon andi1965 » 21. Jul 2015 16:44

Hallo,
vielleicht hilft das :

http://www.ftcommunity.de/ftpedia_ausga ... 2014-4.pdf

Gruß Andreas

Benutzeravatar
HaWe
Administrator
Administrator
Beiträge: 5398
Registriert: 11. Jan 2006 21:01
Wohnort: ein kleiner Planet in der Nähe von Beteigeuze

Re: Probleme und schlechte Dokumentation der Pixy Cam

Beitragvon HaWe » 22. Jul 2015 08:03

das Problem mit der Pixy Cam ergab sich (wie von mir beschrieben) im UART-Modus, nicht per I2C, wie es bei ft gemacht wurde. I2C ist beim Arduino für mich nicht möglich, da diese Schnittstelle im Slave-Modus gebraucht wird. Aber selbst für I2C wären noch viel zu viele unzumutbare Rumprogrammierereien in den Pixy-Treiber-Libs nötig gewesen, das tu ich mir nicht an.
Aber auch SPI ging nicht, weil es keinen Code für SPI-Hardware-Chipselect-Steuerung gab, um die Cam gemeinsam mit anderen Geräten (SD, TFT) am SPI Bus betreiben zu können - auch da hätte man selber noch viel zu viel low-level-Patchereien machen müssen. Weiterhin war Arduino-SPI clock von den Pixy-Bauern willkürlich runtergetaktet auf 1 MHz - unzumutbar, wenn das 16- bis 84-fache an SPI-Bus-Speed möglich ist!!!
Hinzu kommt, das die meisten Probleme auch noch verstärkt mit dem leistungsfähigeren Due auftraten, der insgesamt von Pixy aber extrem stiefmütterlich supportet wird.

Ehrlich, kein Bock auf so einen Mist, sowas müssen die Hersteller fix-und fertig, plug-and-playmäßig liefern können.
Also:
Kein Plug-and-Play, keine Pixy, basta.
Ich hatte sie ja deswegen auch ganz schnell wieder an den Lieferanten zur Gutschrift retourniert.

Bezügl. ft Controller:
Ein ganz grundsätzliches Problem bei ALLEN ft-Interfacen/Controllern aber ist, dass sie für autonomen Betrieb nur mit den Bildchen programmiert werden können und nicht mit einer einfachen, aber mächtigen C-ähnlichen Sprache samt simpler API und simpler IDE wie NXC oder Arduino Sketch/Wiring. So etwas gab es bei Lego schon vor 15 Jahren.
Weiterhin haben ft Controller NULL (!!) Encoder-Eingänge für Rotationsencoder (Quadratur-Encoder): die Lego Bricks (NXT, EV3) haben 2 Encoder-Kanäle für alle angeschlossenen Motoren (also 4x 2 beim EV3) !!
Das ist IMO absolut lächerlich bei ft.
Daher kommen ft Controller mE überhaupt nicht in Betracht, weder die alten inkl. TX noch der neue TXT.
Gruß,
HaWe
±·≠≈²³αβγδε∂ζλμνπξφωΔΦ≡ΠΣΨΩ∫√∀∃∈∉∧∨¬⊂⊄∩∪∅∞®
NXT NXC SCHACHROBOTER: https://www.youtube.com/watch?v=Cv-yzuebC7E


Zurück zu „allgemeine / Nicht-Lego-Robotik und Elektronik“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste

Lego Mindstorms EV3, NXT und RCX Forum : Haftungsauschluss