ct-Bot - Komplikationen und Probleme

• Die Abstandssensoren: Die im Bot verbauten Abstandssensoren sind extrem empfindlich gegen Verpolungen (will sagen: einmal verpolt heißt, die Dinger sind kaputt). Die Bauanleitung ist an dieser Stelle nicht so eindeutig, wie aufgrund der Empfindlichkeit der Bauteile möglichweise gegeben. Ich habe nach Bilder der Roboter anderer Leute im Internet gesucht, um ganz sicher zu sein. Ok, im Nachhinein ist die offizielle Bauanleitung sowohl korrekt als auch eindeutig, aber man hätte hier vielleicht ein wenig deutlicher sein können, zumal (vielleicht aus Nachlässigkeit) einige Leute ihre Abstandssensoren geschrotet haben.
  Die Abstandssensoren haben übrigens auch noch einige andere Tücken (z.B. teilweise unruhige Werte), zu denen es bereits Lösungsvorschläge auf der offiziellen Seite gibt (Einbau von Kondensatoren, um die Signale zu glätten).
• Der Maussensor: dadurch, daß es sich um eine Optik handelt, die in Mäusen verbaut wird, ist der angedachte Abstand vom Boden eigentlich klar festgelegt - und zwar recht niedrig, denn so eine Maus liegt ja nun einmal flach auf dem Tisch. Durch das Roboterkonstrukt liegt die Mausplatine aber etwas höher als eigentlich vorgesehen. Dadurch kommt es, daß die im Sensorchip enthaltene Minikamera verschwommene Bilder aufnimmt und es je nach Untergrund zu Problemen bei der Ermittlung der Position kommen kann. es hilft, den Maussensor tiefer zu legen (sofern man Probleme hat), um bessere Ergebnisse zu bekommen. Anleitungen und Tipps gibt es auf den u.g. Seiten.
  Inzwischen habe ich den Sensor auch etwas "tiefer gelegt". Viel tiefer geht nicht mehr, da sonst die beiden Reflexsensoren dort auf dem Boden schleifen. Auf hellem "Testboden" haben sich die Ergebnisse auch entsprechend verbessert.
• Der Programmieradapter: Ich benutze den (nicht ganz billigen) USB-Adapter mkII von Atmel (Hinweis: In einer ct-Ausgabe gibt es eine Anleitung zum Eigenbau eines Programmieradapters). Beim Schreiben der Firmware (also der Software für den Roboter) gab es den Effekt, daß der Vorgang rund 10 Minuten gedauert hat. Unglaublich natürlich, normalerweise dauert das nur wenige Sekunden. Ich habe dann folgenden Tipp gefunden: Die Einstellung der Programmiergeschwindigkeit wurde von der Software auf (etwa) 1048 kHz eingestellt. Stellt man diese glatt auf 1000kHz, dann dauert der Schreibvorgang nur die üblichen wenigen Sekunden. Scheinbar kommt der Adapter mit der ursprünglich eingestellten Geschwindigkeit (woher er die auch immer her hatte ....) nicht klar.
  Wichtig ist auch, beim allerersten Male (also vor dem Setzen der Fuse-Bits, s.u.) die Schreibrate ggf. zu reduzieren. Abhängig von der Initialisierung des Chips läuft dieser mit einer niedrigen, internen Frequenz, so daß die Schreibrate auf 250kHz oder niedriger gesetzt werden sollte, bis die korrekten Fuse-Bits eingesellt sind.
• Die Fuse-Bits: Vor der ersten Programmierung müssen einige Konfigurationsbits (mit dem Programmieradapter) im Prozessor eingestellt werden, u.a. die Taktrate und einige andere Sachen. Wenn man sich dabei besonders "unglücklich" anstellt, dann kann der Prozessor danach zumindest in der Roboterschaltung nicht mehr programmiert werden (es geht noch in einem Parallel-Programmierer). Das macht natürlich auch nervös - auch wenn es (nach einigen Recherchen im Internet) doch gut geklappt hat.
  Hinweis zu den Fuse-Bits im AVR Studio:
  • SPIEN=0 (das Kästchen ist nicht ausgewählt, aber auch ausgegraut)
  • BOOTSZ=11 (Boot flash section size=256, ohne Bootloader der Erweiterungsplatine!)
  • BODLEVEL=1 (Brown-Out detection VCC=2.7V)
  • CKSEL=1111 SUT=11 (Ext Crystal/Res. High Freq, Startup T 16K CK+64ms)
  • JTAGEN darf nicht ausgewählt sein! (also strenggenommen JTAGEN=1)
  Die nicht genannten Checkboxen sind entsprechend nicht ausgewählt. In anderen Programmierprogrammen sind die o.g. Bits tw. auseinandergezogen, im AVR Studio werden die einzelnen Varianten explizit aufgeführt (z.B. vier Möglichkeiten bei BOOTSZ).
• In die Kategorie "lästig" gehört das Drehen der Motoren beim Einschalten bzw. Reset (für etwa eine halbe Sekunde) sowie beim Flashen des ICs (dann solange, wie der Vorgang dauert). Dies liegt am Verhalten des Prozessors, die IO-Pins zu initialisieren. Ein kleiner "Hardware-Patch" behebt das Problem. (Hinweis: Durch den Einbau der offiziellen Erweiterungsschaltung (s.u.) ist diese Ergänzung nicht mehr notwendig)