Betriebsstörungen nach dem Flashen der Testprogramme

[anonybot]

Hallo zusammen,

ich wollte meinen jüngst fertig gebauten ct-Bot flashen und habe mich dafür an den Hinweisen im ct-Bot-Wiki/Flash und am FAQ/Flashen orientiert.

Nur zur Erklärung, warum ich mich dabei so dämlich anstelle, hier meine Zusammenfassung des Lesestoffes:
Im Wiki werden unterschiedliche Adapter (mit Hinweis auf .hex-Dateien in den Beispiel-Befehlen), Flashen von EEPROM-Abbildern (.eep-Dateien ), Setzen der Fuse-Bits und der Bootloader (mit dem Hinweis, diesen auch erstmal ignorieren zu können) erklärt. Ob und welche Reihenfolge es dabei gibt, erschloss sich mir dabei nur indirekt bzw. durch blindes Vertrauen, dass der Artikel mit der Reihenfolge der Abschnitte auch eine Reihenfolge für das Flashen nahelegen wollte. In den FAQ stand dann, man müsse nur die .hex-Datei flashen sowie Fuse-Bits setzen (und das möglichst nur einmal, wovon aber wiederum im Wiki nichts steht).

Daraus habe ich folgende Abfolge zusammengedichtet:

1. apt-get install avrdude
2. Test-Programme herunterladen.
3. ct-Bot anschalten (dem Hinweis der c't entsprechend, der Bot müsste immer über eine eigene Stromquelle verfügen, um sich nicht über den Parallelport zu versorgen)
4. ct-Bot mit blueMP3-ISP-Adapter verbinden
5. Flashen von ct-Bot-analog.hex:

Code: Alles auswählen

$ sudo avrdude -c stk200 -P /dev/parport0 -p m32 -U flash:w:"ct-Bot-analog.hex":i

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: Expected signature for ATmega32 is 1E 95 02
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

6. Fuse-Bits setzen:

Code: Alles auswählen

$ sudo avrdude -c stk200 -P /dev/parport0 -p m32 -U lfuse:w:0xFF:m -U hfuse:w:0xD1:m -v

avrdude: Version 6.1, compiled on Sep 11 2014 at 20:00:34
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/root/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/parport0
         Using Programmer              : stk200
         AVR Part                      : ATmega32
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom         4    10    64    0 no       1024    4      0  9000  9000 0xff 0xff
           flash         33     6    64    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  2000  2000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  2000  2000 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
           calibration    0     0     0    0 no          4    0      0     0     0 0x00 0x00

         Programmer Type : PPI
         Description     : STK200
           VCC     =  (not used)
           BUFF    =  4,5
           RESET   =  9
           SCK     =  6
           MOSI    =  7
           MISO    =  10
           ERR LED =  (not used)
           RDY LED =  (not used)
           PGM LED =  (not used)
           VFY LED =  (not used)

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9705
avrdude: Expected signature for ATmega32 is 1E 95 02
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

7. Bot komplett aus- und wieder eingeschaltet entsprechend der Wiki-Anleitung.

Ergebnis: Bot leuchtet wie der Weihnachtsbaum im "Auslieferungszustand", Räder drehen sich entgegengesetzt. Sollte das Flashen also irgendeine Änderung bewirkt haben, fällt mir keine auf.

1. Frage: Was hab ich falsch gemacht?
2. Frage: Schmort es die Bot-Hardware irgendwie durch, wenn man die Motoren beim Flashen vom Strom abzieht? Das Laufgeräusch der Räder ist in späten Stunden etwas nervig.
3. Frage: Muss der Bot beim Flashen überhaupt angeschaltet sein oder reicht es, wenn er mit Akkupack oder Netzteil verbunden, aber ausgeschaltet ist?
4. Frage: betrifft den Hinweis des Wikis:

Um neue Mikrocontroller erstmals zu programmieren, muss man eventuell die Taktgeschwindigkeit des Programmieradapters heruntersetzen, weil der Mikrocontroller im Auslieferungszustand mit einem sehr niedrigen Takt läuft. Dazu hängt man beim Setzen der Fuse-Bits -B 1000 an die Befehlszeile an. Anschließend setzt man beim Übertragen des Programm mit -B 1 die Taktgeschwindigkeit wieder hoch.

-> Woher weiß ich, wann "eventuell" der Fall ist?

Es tut mir leid, wenn diese Fragen trivial sind, aber die heise-Dokumentationen wirken in alter Tradition eher wie Notizen für diejenigen, die eh schon wissen wie es geht.

Vielen Dank im Voraus!

Edit: Titel geändert (war: "Bot geflasht, aber keine Änderung? Fragen zum Flash-Vorgang.")

[tobi]

Hi,

das entscheidende Problem ist, dass du wohl den neuen ATmega1284P (Device signature = 0x1e9705) und nicht den alten ATmega32 hast. Segor hat irgendwann mal angefangen mit den Bots den neuen Controller auszuliefern (was auch gut ist ), keine Ahnung ob da was dabei steht. Jedenfalls musst du beim Flashen deshalb das angepasste Kommando verwenden und auch das Testprogramm aus dem passenden Ordner verwenden.

Kurze Zusammenfassung der Schritte:

1. Fuse Bits setzen:

   Code: Alles auswählen

   avrdude -c stk200 -P /dev/parport0 -p m1284p -U lfuse:w:0xF7:m -U hfuse:w:0xD1:m -U efuse:w:0xFF:m -v

2. Wenn das erfolgreich war (avrdude gibt die neue Einstellung mit aus), Bot aus- und wieder einschalten.
3. Testprogramm (aus Ordner atmega1284p) flashen (das erste Mal inkl. EEPROM)-File:

   Code: Alles auswählen

   ​avrdude -c stk200 -P /dev/parport0 -p m1284p -U flash:w:"ct-Bot-analog.hex":i -U eeprom:w:"ct-Bot-analog.eep":i -v

4. Fertig. Zum Übertragen eines anderen (Test-) Programms braucht man dann natürlich nur noch Schritt 3 (ohne EEPROM):

   Code: Alles auswählen

   avrdude -c stk200 -P /dev/parport0 -p m1284p -U flash:w:"ct-Bot-analog.hex":i -v

Ob man die Taktgeschwindikeit anpassen muss, hängt vom Programmer ab. Sie darf max. 1/4 der Frequenz des ATmegas betragen, der läuft - bevor man die Fuse Bits umstellt - mit 1 MHz, also max. 250 kHz zum Programmieren. Wenn man zu faul ist, das genau auszurechnen, stellt man die Frequenz halt runter, wenn das Setzen der Fuse Bits nicht funktioniert hat... Ich glaube das betrifft aber sowieso nur die schnellen USB-Programmer.

Die Motoren kannst du problemlos abziehen, eingeschaltet muss der Bot aber auf jeden Fall sein beim Flashen. Um das nervige Drehen der Motoren beim Reset zu beheben, siehe Hardware-Mods aus Aufbauanleitung. Die anderen Mods 3-5 sind übrigens auch sehr sinnvoll.

Ich hoffe das hilf schon mal weiter,
Tobi

[anonybot]

Hey Tobi,

tausend Dank, er lebt (oder besser: er "zuckt", dazu komme ich noch)!

das entscheidende Problem ist, dass du wohl den neuen ATmega1284P (Device signature = 0x1e9705) und nicht den alten ATmega32 hast. Segor hat irgendwann mal angefangen mit den Bots den neuen Controller auszuliefern (was auch gut ist ), keine Ahnung ob da was dabei steht. Jedenfalls musst du beim Flashen deshalb das angepasste Kommando verwenden und auch das Testprogramm aus dem passenden Ordner verwenden.

Du hast genau richtig vermutet. Da ich wieder ein kurzes Tutorial schreiben möchte: Wie finde ich heraus, welchen Typ ich habe? Zunächst einen Auslesevorgang ala

Code: Alles auswählen

avrdude -c stk200 -P /dev/parport0 -p m32 -U eeprom:r:"ct-Bot.eep":i -u

starten und auf die Rückmeldungen warten? Das geht doch sicher "eleganter".

Kurze Zusammenfassung der Schritte:

1. Fuse Bits setzen:

   Code: Alles auswählen

   avrdude -c stk200 -P /dev/parport0 -p m1284p -U lfuse:w:0xF7:m -U hfuse:w:0xD1:m -U efuse:w:0xFF:m -v

2. Wenn das erfolgreich war (avrdude gibt die neue Einstellung mit aus), Bot aus- und wieder einschalten.
3. Testprogramm (aus Ordner atmega1284p) flashen (das erste Mal inkl. EEPROM)-File:

   Code: Alles auswählen

   ​avrdude -c stk200 -P /dev/parport0 -p m1284p -U flash:w:"ct-Bot-analog.hex":i -U eeprom:w:"ct-Bot-analog.eep":i -v

4. Fertig. Zum Übertragen eines anderen (Test-) Programms braucht man dann natürlich nur noch Schritt 3 (ohne EEPROM):

   Code: Alles auswählen

   avrdude -c stk200 -P /dev/parport0 -p m1284p -U flash:w:"ct-Bot-analog.hex":i -v

Hat wunderbar funktioniert, aber:

1. Frage: Warum hast Du den Parameter -u rausgenommen? Oder anders: Wenn dieser "Disable the safemode fuse bit checks." bedeutet, warum führt ihn dann das offizielle Wiki auf? Ist das nicht "problematisch", die Selbsttests standardmäßig auszuschalten?

2. Frage: Ich habe nun *analog.hex, *digital.hex und *motor.hex ausprobiert. Der Bot zuckt rum, blinkt wild und scheint mir nach jedem aus- und anschalten eines von zwei/drei anderen Programmen zu aktivieren (mal rotiert er nach dem Anschalten langsamer, mal schneller, mal mit 4 leuchtenden LEDs, mal mit nur 2en - habe es nicht genau erfasst, kann ich aber gerne tun, sollte sich das schon eigenartig anhören). So wie ich S. 212 in ct 04/2006 ("Jagd den Fehlerteufel") verstehe, sollen die Testprogramme ja zeigen, ob die Sensoren korrekt funktionieren. "Technisch" funktionieren sie (per "Digicam-Trick" die Infrarot-Sensoren getestet, die allesamt leuchten). Jedoch ging ich davon aus, dass die Testprogramme die Sensoren auch "reagieren" lassen, also Beispielsweise: Irgendeine LED geht an oder aus, je nachdem, ob ich einen der Bodensensoren mit dem Finger verdecke oder nicht. Habe ich da etwas falsch verstanden und die Programme "triggern" nur Funktionen durch, sodass ich nur darauf achten soll, ob "jede Lampe einmal geblinkt hat"?

3. Frage: Die Platine wird auf der Seite der kleinen ICs doch recht warm, um nicht zu sagen, heiß, wenn ich den Bot, sagen wir, 5min laufen lasse. Ist das okay?

Ob man die Taktgeschwindikeit anpassen muss, hängt vom Programmer ab. Sie darf max. 1/4 der Frequenz des ATmegas betragen, der läuft - bevor man die Fuse Bits umstellt - mit 1 MHz, also max. 250 kHz zum Programmieren. Wenn man zu faul ist, das genau auszurechnen, stellt man die Frequenz halt runter, wenn das Setzen der Fuse Bits nicht funktioniert hat... Ich glaube das betrifft aber sowieso nur die schnellen USB-Programmer.

Da ich es nicht eilig habe und das Setzen der Fuse-Bits nun klappte, gehe ich mal davon aus, dass ich hier erstmal nichts verändere.
Mir fällt jedoch in Bezug auf die Fuse-Bits noch etwas ein:

Frage 4: Warum konnte ich jetzt problemlos noch einmal die korrekten Fuse-Bits setzen? In ct 04/2006 steht ja auch, dass ein falsches Setzen der Bits den Controller "nachhaltig den Dienst verweigern lässt" (imd ich hatte zuvor aus Unkenntnis versehentlich lfuse:w:0xFF:m statt lfuse:w:0xF7:m im Befehl zu stehen).

Die Motoren kannst du problemlos abziehen, eingeschaltet muss der Bot aber auf jeden Fall sein beim Flashen. Um das nervige Drehen der Motoren beim Reset zu beheben, siehe Hardware-Mods aus Aufbauanleitung. Die anderen Mods 3-5 sind übrigens auch sehr sinnvoll.

Danke für die Erklärung und die Hinweise. Die nötigen Bauteile sind für die nächste Segor-Bestellung notiert.

Ich hoffe das hilf schon mal weiter,
Tobi

Sehr sogar!
Ohne Deine Infos wäre es frustrierend geworden. Ich packe zum Dank alles an Infos gebündelt in die Tutorial-Sektion dieses Forums, sobald mir alle Schritte ganz klar sind.

Je nachdem, ob mein Bot bis hierher richtig "tickt", würde ich als nächsten Schritt entsprechend des Abschnitts Erste Geh- und Modifikationsversuche mit der Demo-Firmware mich erst einmal an die Hardware-Modifikationen machen und mich dann bezüglich der erwähnten "Demo-Firmware" belesen, die ja erstmal mofidiziert werden muss, soweit ich es aktuell verstanden habe.

[tobi]

Hi,

um herauszufinden, welchen Controller du hast, gibt es 2 einfache Möglichkeiten:

1. den Aufdruck auf dem Chip anschauen
2. mit avrdude versuchen die Device-ID auslesen ohne etwas zu programmieren

   Code: Alles auswählen

   avrdude -c stk200 -P /dev/parport0 -p m32 -v

   oder halt

   Code: Alles auswählen

   avrdude -c stk200 -P /dev/parport0 -p m1284p -v

   Dann muss man aber noch nachschauen, welche Device-ID zu welchem Controller gehört.

Zu 1: Das Deaktivieren vom safe-mode (-u) braucht man glaube ich nur, wenn der Programmer die Fuse Bits nicht richtig auslesen kann, oder so. Ich hatte ohne -u nie Probleme.

Zu 2: Klingt so, als ob etwas nicht richtig funktioniert. Auf dem Display sollten immer alle Sensorwerte angezeigt werden, egal welches Testprogramm du benutzt. Damit kann man am einfachsten die Werte überprüfen, siehe ct-Artikel. Die LEDs zeigen den Sensorstatus auch an, ist aber schwieriger abzulesen, weil eben nur an oder aus und keine Wertanzeige.

Zu 3: welches IC wird denn warm oder heiß? Das ist auf jeden fall nicht okay, eigentlich sollte da nichts mehr als handwarm werden, außer der Spannungsregler vielleicht, der aber auch nicht heiß.

Zu 4: Es kommt darauf an, welche Fuse Bits du falsch setzt. Kritisch ist es dann, wenn du damit auf externe Taktversorgung umschaltest, die es in der Schaltung nicht gibt.

Tobi

[anonybot]

Hi,

um herauszufinden, welchen Controller du hast, gibt es 2 einfache Möglichkeiten:

1. den Aufdruck auf dem Chip anschauen

Weniger fragen, mehr denken... sry!

[*]mit avrdude versuchen die Device-ID auslesen ohne etwas zu programmieren

Code: Alles auswählen

avrdude -c stk200 -P /dev/parport0 -p m32 -v

oder halt

Code: Alles auswählen

avrdude -c stk200 -P /dev/parport0 -p m1284p -v

Dann muss man aber noch nachschauen, welche Device-ID zu welchem Controller gehört.[/list]

Danke, notiert!

Zu 1: Das Deaktivieren vom safe-mode (-u) braucht man glaube ich nur, wenn der Programmer die Fuse Bits nicht richtig auslesen kann, oder so. Ich hatte ohne -u nie Probleme.

Okay, nehme ich als Anmerkung auf.

Zu 2: Klingt so, als ob etwas nicht richtig funktioniert. Auf dem Display sollten immer alle Sensorwerte angezeigt werden, egal welches Testprogramm du benutzt. Damit kann man am einfachsten die Werte überprüfen, siehe ct-Artikel. Die LEDs zeigen den Sensorstatus auch an, ist aber schwieriger abzulesen, weil eben nur an oder aus und keine Wertanzeige.

Das Display zeigt durchaus alle Sensorwerte an - leider irgendwie nur manchmal. Da ich dieses "manchmal" schlecht beschreiben kann, habe ich kurze Videos (jew. 2min) zu jedem der 3 Test-Flashvorgänge erstellt. Da der Bot bereits geflasht war, kann ich schlecht bei "Null" anfangen, aber ich starte mit einem Flash-Vorgang und lasse den Bot dann einfach mal gut eine Minute vor sich hin "testen", unterbrochen von jeweils einem Aus-/Anschaltvorgang (falls das für die Beurteilung auch wichtig ist).

Geflash habe ich von *LeiderVergessen.hex* zu analog.hex (Video 1) zu digital.hex (Video 2) zu motor.hex (Video 3):

Video 1: ct-bot test-firmware ct-bot-analog.hex
Video 2: ct-bot test-firmware ct-bot-digital.hex
Video 3: ct-bot test-firmware ct-bot-motor.hex

(falls wichtig: beim letzten Video (3) wurde ich beim Aufnehmen unterbrochen, daher startet das Video vom "motor.hex"-Flashvorgang mit bereits geflashter ct-bot-motor.hex)

Frage 1: Ersteindruck? "Kommt der Patient durch?"

Frage 2: Ich kann dem ct-Artikel zum Aufbau und dem Wiki nicht entnehmen, was denn genau (und wann) leuchten muss bzw. welche Werte das Display anzeigen sollte. Dort steht lediglich, dass der Bot bei einem der Programme mal gegen den Uhrzeigersinn dreht, was auch der Fall ist. Die Tabelle in der ct 4/2006 ordnet nur LED-Farben bestimmten Baugruppen zu, sagt dann aber nicht, ob die LEDs, sofern die Baugruppe funktioniert, dauerhaft leuchten, blinken bzw. gar nichts tun sollte (ich hatte es mir so vorgestellt, dass z. B. die LED "weiß" für den Kantensensor links dann aufleuchtet, wenn sie ihr ausgestrahltes Licht nicht mehr messen kann oder umgekehrt). Gibt es dazu genauere Infos oder habe ich das Prinzip hinter den Testprogrammen falsch verstanden?

Zu 3: welches IC wird denn warm oder heiß? Das ist auf jeden fall nicht okay, eigentlich sollte da nichts mehr als handwarm werden, außer der Spannungsregler vielleicht, der aber auch nicht heiß.

Die Einschätzung kann ich mangels Thermometer (und wo sollte man es genau messen) nur sehr subjektiv abgeben, aber: IC3 scheint mir auf der Oberseite recht warm, noch wärmer P1 auf der Oberseite (Kühlfahne, falls man das geschwungene Blech über der Buchse so nennt). Auf der Unterseite (also auf den Lötstellen) wird es unter IC3 so warm, dass ich den Finger wegziehe.

Zu 4: Es kommt darauf an, welche Fuse Bits du falsch setzt. Kritisch ist es dann, wenn du damit auf externe Taktversorgung umschaltest, die es in der Schaltung nicht gibt.

Verstanden, danke!

[tobi]

Also in den Videos sieht man deutlich, dass sich der ATmega nach kurzer Zeit immer wieder resettet (Display wird leer), darum ist das Verhalten so seltsam.
Wenn es auf P1 warm wird und unter IC3 sogar heiß, dann hast du vermutlich irgendwo einen Kurzschluss zwischen vcc und gnd, der wahrscheinlich auhc die Resets auslöst. Du solltest also auf jeden Fall erstmal den Kurzschluss beseitigen, da helfen die E-Tests aus dem Aufbauanleitungsartikel und der Fehlersuchartikel. Außerdem vielleicht mal den Strom messen, den der Bot im Leerlauf aufnimmt. Es sollte nirgendwo warm werden, außer IC10 ein wenig, aber auf keinen Fall heiß.

Tobi

[anonybot]

Hi tobi,

vielen Dank für Deine Ideen zur Problemklärung!

Also in den Videos sieht man deutlich, dass sich der ATmega nach kurzer Zeit immer wieder resettet (Display wird leer), darum ist das Verhalten so seltsam.
Wenn es auf P1 warm wird und unter IC3 sogar heiß, dann hast du vermutlich irgendwo einen Kurzschluss zwischen vcc und gnd, der wahrscheinlich auhc die Resets auslöst. Du solltest also auf jeden Fall erstmal den Kurzschluss beseitigen, da helfen die E-Tests aus dem Aufbauanleitungsartikel und der Fehlersuchartikel. Außerdem vielleicht mal den Strom messen, den der Bot im Leerlauf aufnimmt. Es sollte nirgendwo warm werden, außer IC10 ein wenig, aber auf keinen Fall heiß.

Die Stromaufnahme schwankt bei abgezogenen Motoren, Display und Klappen-Servo zwischen 225 und 250mA (mehr kann ich mit meinem einfachen Multimeter auch nicht messen). Der Support von Segor meinte, das sei okay so.
Ungewollte Lötbrücken konnte ich auch bis jetzt leider auch keine finden.
Ich habe mir den Fehlersuchartikel angeschaut und bin kurz davor, die Leitungen entsprechend durchzugehen. Bevor das jedoch eine Sisyphos-Arbeit wird, wollte ich nur zur Sicherheit nochmal bestätigen:

Du bist ganz sicher, dass ich durch mein erstes Setzen der falschen Fuse-Bits ($ sudo avrdude -c stk200 -P /dev/parport0 -p m32 -U lfuse:w:0xFF:m -U hfuse:w:0xD1:m -v) keinen dauerhaften Fehler in den ICs verursacht habe, der die ICs eventuell unbrauchbar gemacht hat (sodass das akt. Verhalten entsteht)?

(Ich frage nur, weil der ct-Artikel ja so eindringlich darauf hinwies.)

Vielen Dank!

[tobi]

Hi,

Die Stromaufnahme schwankt bei abgezogenen Motoren, Display und Klappen-Servo zwischen 225 und 250mA (mehr kann ich mit meinem einfachen Multimeter auch nicht messen). Der Support von Segor meinte, das sei okay so.

das sieht schon mal okay aus, wie ist die Stromaufnahme mit Motoren? Und hast du die Resets auch bei abgezogenen Motoren? Wird es mit abgezogenen Motoren auch so warm an den genannten Stellen?

Du bist ganz sicher, dass ich durch mein erstes Setzen der falschen Fuse-Bits ($ sudo avrdude -c stk200 -P /dev/parport0 -p m32 -U lfuse:w:0xFF:m -U hfuse:w:0xD1:m -v) keinen dauerhaften Fehler in den ICs verursacht habe, der die ICs eventuell unbrauchbar gemacht hat (sodass das akt. Verhalten entsteht)?

Ja, sonst würde auch das Display nichts anzeigen. Mit lfuse = 0xff verwendest du den low-power mode für den Quarz, der evtl. nicht so stabil ist, aber auch funktioniert. Problematisch wird es nur (und davor warnt der Artikel), wenn das obere Byte != 0xf ist, dann bootet der ATmega nicht mehr, weil der Takt fehlt. Kaputt ist dann auch nichts, aber man kann ihn nicht mehr auf diese Weise flaschen (braucht einen externen Takt, siehe FAQ). Endgültig zerstören kann man die ICs durch falsche Fuse Bits also nicht.

Tobi

[anonybot]

Hi,

Hi, entschuldige, dass es so lange gedauert hat. Die "Analyse" selbst, dann die Videos aufzunehmen, zu sortieren und hochzuladen hat recht viel Zeit gekostet. Hat aber einiges an interessanten Informationen gebracht. Hier nun im Einzelnen:

das sieht schon mal okay aus, wie ist die Stromaufnahme mit Motoren?

Habe ich versucht zu messen, aber da schlug mein Billig-Multimeter schon ans Limit der Skala. Kann ich also leider nicht sagen.

Und hast du die Resets auch bei abgezogenen Motoren?

Ja, aber die Resets hatten einen sehr eigenartigen anderen Grund. Der (wenn man dem Bot in die "Augen" schaut:) rechte Abstandssensor erzeugt die Resets. Weiter unten dazu mehr.

Wird es mit abgezogenen Motoren auch so warm an den genannten Stellen?

Die Wärmeentwicklung fiel mir in der Testreihe, die recht lang dauerte, eigenartigerweise nicht mehr auf. Sowohl mit Netzteil als auch mit Akkus. Ich behalte das im Auge, würde es jetzt erstmal als gelöst betrachten.

Ja, sonst würde auch das Display nichts anzeigen. Mit lfuse = 0xff verwendest du den low-power mode für den Quarz, der evtl. nicht so stabil ist, aber auch funktioniert. Problematisch wird es nur (und davor warnt der Artikel), wenn das obere Byte != 0xf ist, dann bootet der ATmega nicht mehr, weil der Takt fehlt. Kaputt ist dann auch nichts, aber man kann ihn nicht mehr auf diese Weise flaschen (braucht einen externen Takt, siehe FAQ). Endgültig zerstören kann man die ICs durch falsche Fuse Bits also nicht.

Sehr wichtige Info, danke und notiert!

Nun zu meiner Fehleranalyse. Ich habe das Botverhalten mit der ct-bot test-firmware ct-bot-motor.hex aufgenommen und zwar so, dass ich zunächst wirklich alles von der Hauptplatine abzog, was sich abziehen ließ und dann Komponente für Komponente wieder verbunden habe. Videos sind etwas dunkel, damit man die LEDs unterscheiden kann:

01. ct-bot_error-diagnostic1_disp -> Hauptplatine + Display -> kein Reset, aber orange LED
02. ct-bot_error-diagnostic2_disp_motor-l-r -> Hauptplatine + Display + beide Motren -> kein Reset, aber orange LED
03. ct-bot_error-diagnostic3_disp_motor-l-r_mouse -> Hauptplatine + Display + beide Motren + Maussensor -> kein Reset, aber orange LED
04. https://vimeo.com/album/3676036/video/147113286 -> Hauptplatine + Display + beide Motren + Maussensor + Sensorboard links (siehe Aufkleber "left") -> kein Reset, aber orange LED
05. ct-bot_error-diagnostic5_disp_motor-l-r_mouse_sensorboard-r -> Hauptplatine + Display + beide Motren + Maussensor + Sensorboard rechts (siehe Aufkleber "right") -> Reset-Fehler
06. ct-bot_error-diagnostic6_disp_motor-l-r_mouse_sensorboard-r_dist-r-off -> Hauptplatine + Display + beide Motren + Maussensor + Sensorboard rechts, aber ohne Abstandssensor (siehe Aufkleber) -> kein Reset-Fehler, aber wieder orange LED
07. ct-bot_error-diagnostic7_disp_motor-l-r_mouse_sensorboard-r_dist-r-check -> Funktionstest des Abstandssensors, der die Resets verursacht -> funktioniert, sofern Licht aussenden mit "funktionieren" gleichgesetzt werden kann?
08. ct-bot_error-diagnostic8_disp_motor-l-r_mouse_sensorboard-l-r_dist-r-off -> Hauptplatine + Display + beide Motren + Maussensor + beide Sensorboards, ohne rechten Abstandssensor -> kein Reset, aber orange LED
09. nur Hauptplatine "ohne alles" -> konnte ich aufgrund des Upload-Limit von Vimeo nicht mehr hochladen, ist aber das selbe Verhalten wie bei den anderen Videos -> LED orange, gelb und türkis leuchten, manchmal die LED links vorne

Auswertung/Fragen:
1. Reset-Verursacher gefunden, aber warum funktioniert der Abstandssensor und kann trotzdem Resets verursachen (Verpolung würde doch sofort einen Totalschaden verursachen)?

2. Orange "Fehler"-LED blinkte immer. Kann man es irgendwie eingrenzen, was diese meldet?

3. Bei jedem Test blinkte manchmal die LED über dem (wenn man dem Bot in die "Augen" schaut:) linken Abstandssensor auf. Im Testprogramm der motor.hex soll dies ja Funktionalität des einen Rad-Ecnoders anzeigen (je nachdem, was die c't mit "links" und "rechts" meint). Aber wie kann das sein, wenn die kleinen Sensorplatinen, die dafür zuständig sind, gar nicht angeschlossen sind? Oder anders: Kann man den Fehler eingrenzen, der diese LED blinken lässt, obwohl gar nichts registriert werden kann?

4. In der c't 04/2006 gibt es auf S. 211 ein Bild mit dem Bot-Display, das neben "I=0000" auch "M=00 00" anzeigt. Die Werte für "M" fehlen bei mir völlig. Ist das normal?

5. Dir ist sicher aufgefallen, dass ich die Verbindung von Abstandssensor zur Sensorplatine etwas anders gelötet habe. Ich versprach mit beim ersten Aufbau davon, dass die Kabel des Abstandssensors sich dadurch besser verlegen lassen. Habe erst später festgestellt, dass die Verschraubung für den Abstandssensor mit den Kabeln ziemlich ins Gedränge kommt, da ich aber die Metallschrauben durch Plastikschrauben ersetzt habe, dachte ich nicht, dass es langfristig mit meiner Variante keine Probleme geben würde. Der Abstandssensor funktioniert ja auch. Sollte ich trotzdem nochmal zur Standardbauweise umlöten, also die Kabel des Abstandssensors nicht um den Pfeiler herumlegen?
Hier ein älteres Bild von meiner Lösung (noch mit Metallschrauben):

Sry, sau viel Text... aber ich hoffe, es macht die Hilfe eher leicht als nervig...

[tobi]

1. Wie ist denn die Stromaufnahmen mit angesteckten, aber nicht laufenden Motoren? Die sollte ja nicht höher sein als mit abgesteckten Motoren, also messbar. Ansonsten gibt es da irgendwo ein Probem.
2. Die Resets kommen dann sicherlich von den Distanzsensoren, das ist ein bekanntes Problem, gibt auch viele Foreneinträge dazu hier. Die Lösung findest du unter https://www.heise.de/ct/projekte/machmi ... bilisieren und http://www.segor.de/L1Bausaetze/gp2d12.shtml. Das Hauptproblem ist, dass das Gehäuse der Sensoren leitend ist, also mit Isolierband auf der Rückseite isolieren und Kunstoffschrauben benutzen.
3. Die orange Fehler-LED entspricht der Anzeige F= im Display, F=1 bedeutet LED AN und alles okay. F=0, LED AUS, bedeutet entweder zu geringe Eingangsspannung (< 6V oder so etwas in der Richtung glaube ich) oder zu großer Strombedarf. Letzteres ist für den Fall gedacht, dass ein angeschlossener Servo blockiert und zu viel Strom zieht.
4. Wenn Sensoren nicht angeschlossen sind, ist die Anzeige dazu meistens rein zufällig, weil der Eingang floatet. Um da einen konstanten Wert zu erhalten, müsste man den Eingang auf Masse ziehen. Von daher kannst du das ignorieren, solange der Sensor nicht angeschlossen ist.
5. Die Anzeige M= ist für den Maussensor, vermutlich ist der bei den Testprogrammen nicht aktiv. Firmware mit MOUSE_AVAILABLE compilieren sollte da helfen.
6. Ich denke die Kabellage ist da kein Problem, solange die Kabel richtig isoliert sind (erkennt man so nicht).

Tobi

[anonybot]

Hallo Tobi,

ich habe es heute endlich geschafft, mir den Bot nochmal genau anzuschauen. Danke erstmal für die vielen Zusatzinfos. Hier meine aktuellen Ergebnisse:

1. Wie ist denn die Stromaufnahmen mit angesteckten, aber nicht laufenden Motoren? Die sollte ja nicht höher sein als mit abgesteckten Motoren, also messbar. Ansonsten gibt es da irgendwo ein Probem.

Ich habe es bei lediglich angeschlossenen Motoren gemessen (alles andere abgezogen). Bei nicht laufenden Motoren habe ich ~70mA gemessen, bei laufenden nicht ganz 150mA.

Siehe: ct-bot_error-diagnostic10_motor-power-measurement

2. Die Resets kommen dann sicherlich von den Distanzsensoren, das ist ein bekanntes Problem, gibt auch viele Foreneinträge dazu hier. Die Lösung findest du unter https://www.heise.de/ct/projekte/machmi ... bilisieren und http://www.segor.de/L1Bausaetze/gp2d12.shtml. Das Hauptproblem ist, dass das Gehäuse der Sensoren leitend ist, also mit Isolierband auf der Rückseite isolieren und Kunstoffschrauben benutzen.

Die Problematik war mir bekannt, daher hatte ich schon vor dem ersten Flashen Plastikschrauben verwendet und die Sensorgehäuse auch mit Plastikmuttern "entkoppelt".
Ich habe nun noch eine zweite Mutter hinzugenommen, um den Abstand vom Alu-Träger zu erhöhen und zudem den betreffenden Maussensor entsprechend der Anleitung so gelötet wie vorgesehen (also nicht mehr wie im Bild oben das Kabel um den Träger herumgelegt, sondern die Standardvariante).
Gleiches Ergebnis: Bot resettet ständig, obwohl der Sensor selbst funktioniert (Optiktest mit Handycamera).

Das ist sehr eigenartig. Kann der Sensor in einer Art defekt sein, dass er zwar Licht aussendet, aber seine Elektronik den Bot durcheinanderbringt?

3. Die orange Fehler-LED entspricht der Anzeige F= im Display, F=1 bedeutet LED AN und alles okay. F=0, LED AUS, bedeutet entweder zu geringe Eingangsspannung (< 6V oder so etwas in der Richtung glaube ich) oder zu großer Strombedarf. Letzteres ist für den Fall gedacht, dass ein angeschlossener Servo blockiert und zu viel Strom zieht.

Okay, das erklärt dann auch, warum die orange LED bei einem Universalnetzteil auf 6V flackert und bei Akku-Betrieb konstant leuchtet?

4. Wenn Sensoren nicht angeschlossen sind, ist die Anzeige dazu meistens rein zufällig, weil der Eingang floatet. Um da einen konstanten Wert zu erhalten, müsste man den Eingang auf Masse ziehen. Von daher kannst du das ignorieren, solange der Sensor nicht angeschlossen ist.

Verstehe. Nachdem ich die Reset-Ursache durch Abziehen des einen Distanzsensors beheben konnte, habe ich mich nochmal an die Testprogramme gemacht. Leider gibt es auch hier eigenartige Phänomene:

Code: Alles auswählen

LED			Test ANALOG
rechts		(Distanz rechts) reagiert korrekt, leuchtet aber immer schwach (zwischen AUS und AN)
links		 (Distanz links) [Sensor abgezogen, verursacht Resets, leuchtet aktuell, wenn rote LED leuchtet]
rot			(Linie links) reagiert korrekt
orange		(Linie rechts) reagiert korrekt
gelb		  (Licht links) reagiert nie, LED leuchtet aber, wenn rote LED leuchtet [wegen abgezogenem Sensor?]
grün		  (Licht rechts) reagiert nie, LED nie an
türkis		(Kante links) reagiert korrekt
weiß		  (Kante rechts) reagiert nie, LED immer an

Kurzfassung:
a.) rechte LED hat schwaches Dauerleuchten anders als linke LED
b.) gelbe LED/Lichtsensor links reagiert nie, gelbe LED leuchtet aber immer dann, wenn rote LED leuchtet ("Linie links")
c.) weiße LED (Kante rechts) immer an, Sensor reagiert nicht

Code: Alles auswählen

LED			Test DIGITAL
rechts		(Rad-Encoder rechts) reagiert korrekt
links		 (Rad-Encoder links) reagiert korrekt
rot			(Transportfach) reagiert korrekt
orange		("Fehler") OK (leuchtet)
gelb		  (Klappe) reagiert korrekt (leuchtet, wenn offen)
grün		  (Maus dx) reagiert nie, LED nie an
türkis		(Maus dy) reagiert nie, LED nie an
weiß		  (IR-Fernbedienung) [mangels Fernbedienung kein Test mgl., LED aus]

Kurzfassung:
d.) Maussensor reagiert nicht (grün/türkis aus)

Code: Alles auswählen

LED			Test MOTOR
rechts		(Rad-Encoder rechts) reagiert nicht, blinkt sporadisch auf
links		 (Rad-Encoder links) reagiert nicht, leuchtet nie
rot			(Transportfach) reagiert nicht, LED immer aus, dafür reagiert die _gelbe_ LED
orange		("Fehler") OK (leuchtet)
gelb		  (Klappe) reagiert nur auf Transportfach
grün		  (Maus dx) reagiert nie, LED nie an
türkis		(Maus dy) reagiert nie, LED nie an
weiß		  (IR-Fernbedienung) [mangels Fernbedienung kein Test mgl., LED aus]

Kurzfassung:
e.) LED rechts/links reagieren nicht, obwohl die ja nichts anderes registrieren sollten als bei der analog.hex
f.) Transportfach-LED ist bei mir nicht die rote, sondern die gelbe
g.) auch hier reagiert die Maus nicht, jedenfalls zeigen die LEDs keine Aktivität

Daneben habe ich festgestellt, dass manchmal das Display nur schwarze Balken zeigt (wie im nicht geflashten Zustand) bzw. einen "wandernden Unterstrich". In den FAQ steht was von falschen FUSE-Bits, aber das sollte bei mir eigentlich nicht der Fall sein. Ich habe schon an sämtlichen Kabeln "gewackelt", der Fehler lässt sich nicht reproduzieren.

Sofern die Infos oben auch bei Dir keine klare Ursache erkennen lassen: Würde es helfen, auf "gut Glück" die Bot-Modifikationen einzubauen oder würdest Du an meiner Stelle eher dazu tendieren, vielleicht die Hauptplatine nochmal komplett neu zu löten (mit einem neuen Bausatz nur für die Hauptplatine)?

Edit: Hab vergessen zu erwähnen, dass es natürlich eigentlich wenig Sinn macht, alle Testprogramme zu flashen, da ja durch das Display alle Werte bei jedem der Testprogramme abgefragt werden können. Es ist trotzdem eigenartig, dass die Programme auf den LEDs nicht das ausgeben, was sie sollten (auch in den Bereichen, die die eigentlich funktionieren sollten, zB die Radencoder-Sensoren bei digital.hex und motor.hex).

[tobi]

Hi,

Strom mit Motoren sieht gut aus würde ich sagen.

D.h. du bekommst Resets, sobald der Distanzsensor angeschlossen ist, egal ob am Bot montiert oder nicht? Hast du die HW-Mods (3 und 4) eingebaut?
Das Checken des Sensor mit einer Kamera ist nur ein sehr rudimentärer Test, d.h. er ist nicht ganz kaputt, aber ob er 100%ig funktioniert weißt du damit nicht.

Also ich denke 6,0V sind evtl. zu wenig als Eingangsspannung, denn an der Diode fallen schon mal 0,6V ab IIRC und der Spannungsregler braucht vermutlich schon so mindestens 5,5V als Eingangsspannung um stabile 5V zu erzeugen. Wenn das Netzteil nur 6,0V oder vielleicht noch etwas weniger liefert, wird das wahrscheinlich knapp. Am besten einfach mal VCC messen, z.B. an J3.

Einige der Analog-Sensoren scheinen nicht richtig zu funktionieren, da am besten mal die Eingänge am ATmega checken.

Maussensor ist vermutlich im Testprogramm nicht aktiviert, s.o.

Beim Motor-Test werden die LEDs glaube ich gar nicht angesteuert, wenn ich das richtig in Erinnerung habe. Der Motor-Test ist ja auch zum Testen der Motoren, also Drehung hin- und zurück nach dem Booten.

Wenn das Display nur manchmal nicht funktioniert, klingt das eher nach schlechten Lötstellen (wenn das Kabel OK ist).
Die Hauptplatine kannst du ja auch so nachlöten mit den vorhandenen Bauteilen, ich denke neue Bauteile lohnen sich da nicht, vermutlich sind einfach ein paar Lötstellen nicht okay.

Tobi

[anonybot]

Hi Tobi,

entschuldie die späte Antwort. Ich habe bezüglich meiner Probleme jemanden im IRC getroffen, der mir geholfen hat, mit den Schaltplänen hilreich umzugehen. Zumindest einen krassen Fehler konnte ich dadurch beheben.

D.h. du bekommst Resets, sobald der Distanzsensor angeschlossen ist, egal ob am Bot montiert oder nicht? Hast du die HW-Mods (3 und 4) eingebaut?
Das Checken des Sensor mit einer Kamera ist nur ein sehr rudimentärer Test, d.h. er ist nicht ganz kaputt, aber ob er 100%ig funktioniert weißt du damit nicht.

Ja, egal ob verschraub oder nicht, resettet der linke Distanzsensor den Bot. Die Mods habe ich noch nicht eingebaut, aber wenn es daran liegen würde, würde ja auch der andere Sensor die Resets hervorrufen.

Also ich denke 6,0V sind evtl. zu wenig als Eingangsspannung, denn an der Diode fallen schon mal 0,6V ab IIRC und der Spannungsregler braucht vermutlich schon so mindestens 5,5V als Eingangsspannung um stabile 5V zu erzeugen. Wenn das Netzteil nur 6,0V oder vielleicht noch etwas weniger liefert, wird das wahrscheinlich knapp. Am besten einfach mal VCC messen, z.B. an J3.

Okay, danke, teste ich bei der nächsten Käferjagd.

Einige der Analog-Sensoren scheinen nicht richtig zu funktionieren, da am besten mal die Eingänge am ATmega checken.

Der rechte Bodensensor funktionierte nicht, weil die Verbindung zwischen R26 und Pin5 von ST9 unterbrochen war. Eigentlich war es nicht mal die Leitung, sondern der betreffende kleine Metallring in der Platine bei R26 war wohl beim Auslöten beschädigt worden (ich hatte beim Zusammenbau einen falschen Widerstand für R26 genommen). Ich musste eine Brücke einlöten:

Brücke-R26-ST9pin5

Nun funktionieren endlich beide Bodensensoren:

Funktionstest-Bodensensoren-per-Smartphonecam

Das herauszufinden hat leider ewig gedauert... ich vermute ähnliche Probleme bei meinen anderen beiden Problemen (linker Distanzsensor und rechter Lichtsensor).

Wird dauern, aber ich berichte hier, was am Ende zurechtgelötet werden musste.

Maussensor ist vermutlich im Testprogramm nicht aktiviert, s.o.

Okay, danke.

Beim Motor-Test werden die LEDs glaube ich gar nicht angesteuert, wenn ich das richtig in Erinnerung habe. Der Motor-Test ist ja auch zum Testen der Motoren, also Drehung hin- und zurück nach dem Booten.

Der freundliche Helfer im IRC hat im Code nachgeschaut. Die motor.hex zeigt an den LEDs vorne die Aktivität der Distanz-Sensoren an. Steht in der c't falsch und war sicher ursprünglich anders.

Wenn das Display nur manchmal nicht funktioniert, klingt das eher nach schlechten Lötstellen (wenn das Kabel OK ist).
Die Hauptplatine kannst du ja auch so nachlöten mit den vorhandenen Bauteilen, ich denke neue Bauteile lohnen sich da nicht, vermutlich sind einfach ein paar Lötstellen nicht okay.

Nachdem ich nun weiß, wie man ungefähr bei der Fehlersuche mit dem Multimeter vorgehen muss, finde ich Reparieren auch sehr viel bildender als Neubauen.

Vielen Dank bis hierher für die Bewältigung der (für mich) etwas steilen Lernkurve!

[anonybot]

Hallo,

leider konnte ich noch immer nicht alle Probleme lösen:

Nachdem ich das Reset-Problem mit meinem linken Distanz-Sensor gelöst hatte (er brauchte die Mods, jetzt verursacht der DIstanzsensor keine Probleme mehr), habe ich die ct-Bot.hex kompiliert. Dass dies geglückt ist erkenne ich aktuell nur daran, dass der Bot sich erfolgreich weigert, sich über eine Kante schieben zu lassen.

1. Ich habe nach wie vor keine Anzeige für den Maussensor im Display (M= unten rechts fehlt komplett). Muss man dessen Abfrage erste explizit vor dem Kompilieren aktivieren?

2. Meine Linien-Sensoren (L=) sind scheinbar seitenvertautscht. Der linke Wert reagiert auf Abdecken des rechten Sensors und umgekehrt. Laut ct-Aufbauartikel (Tabelle) sollte das nicht so sein. Ist es vielleicht mittlerweile so oder habe ich schlicht "zwei Kabel vertauscht"?

3. Das Problem, dass es auf der Unterseite der Platine an einer Stelle sehr heiß wird, ist wieder aufgetreten. Mittlerweile bin ich mir ziemlich sicher, dass es auf der Unterseite desjenigen Bauteils ist, das direkt hinter dem Netzteilanschluss sitzt (R28? - schlecht zu lesen auf dem Bestückungsplan). Im Vergleich zu den Fotos der bestückten Platine fiel mir auf, dass dieses Bauteil (blau-grau-gold-gold?) bei mir genau andersherum sitzt. Da es nur ein Bauteil mit der Kodierung "blau-grau-gold-gold" gibt und es ein Widerstand ist, sollte die Richtung doch egal sein, oder?

4. Die Distanz-Sensoren zeigen nun beide keine Reaktion und stehen permanent auf "D=995 995" - muss das im Demo-Code so sein?

(Nur am Rande: 5. Ich wollte eine Firmware mit Bootloader kompilieren, aber es gab wohl kürzlich ein SVN-Update (auf ct-Bot 1970 und ct-Sim 1949). Seitdem spuckt der Clean-Vorgang sehr viele Fehler aus (unter Eclipse Lunar, mit den vorigen Repository-Versionen gab es keine Fehler), ein Auszug:

Code: Alles auswählen

Description	Resource	Path	Location	Type
AmbientLight cannot be resolved to a type	World.java	/ct-Sim/ctSim/model	line 420	Java Problem
AmbientLight cannot be resolved to a type	World.java	/ct-Sim/ctSim/model	line 420	Java Problem
Appearance cannot be resolved to a type	CtBotShape.java	/ct-Sim/ctSim/model/bots/ctbot	line 442	Java Problem
Appearance cannot be resolved to a type	ParcoursLoader.java	/ct-Sim/ctSim/model	line 315	Java Problem
[...]
ArrayList<Point3d> cannot be resolved to a type	CtBotShape.java	/ct-Sim/ctSim/model/bots/ctbot	line 323	Java Problem
ArrayList<Point3d> cannot be resolved to a type	CtBotShape.java	/ct-Sim/ctSim/model/bots/ctbot	line 324	Java Problem
AxisAngle4d cannot be resolved to a type	SimUtils.java	/ct-Sim/ctSim	line 151	Java Problem
BoundingSphere cannot be resolved to a type	MasterSimulator.java	/ct-Sim/ctSim/model/bots/ctbot	line 340	Java Problem
[...]
Javadoc: javax.media cannot be resolved to a type	SceneGraphStreamWriterFixed.java	/ct-Sim/ctSim/model/scene	line 50	Java Problem

Frohe Feiertage!

[tobi]

Hi,

1. Ich habe nach wie vor keine Anzeige für den Maussensor im Display (M= unten rechts fehlt komplett). Muss man dessen Abfrage erste explizit vor dem Kompilieren aktivieren?

Ja, du musst MOUSE_AVAILABLE aktivieren, ich glaub das ist in der Default-Einstellung aus.

2. Meine Linien-Sensoren (L=) sind scheinbar seitenvertautscht. Der linke Wert reagiert auf Abdecken des rechten Sensors und umgekehrt. Laut ct-Aufbauartikel (Tabelle) sollte das nicht so sein. Ist es vielleicht mittlerweile so oder habe ich schlicht "zwei Kabel vertauscht"?

Ich würde sagen Kabel vertauscht

3. Das Problem, dass es auf der Unterseite der Platine an einer Stelle sehr heiß wird, ist wieder aufgetreten. Mittlerweile bin ich mir ziemlich sicher, dass es auf der Unterseite desjenigen Bauteils ist, das direkt hinter dem Netzteilanschluss sitzt (R28? - schlecht zu lesen auf dem Bestückungsplan). Im Vergleich zu den Fotos der bestückten Platine fiel mir auf, dass dieses Bauteil (blau-grau-gold-gold?) bei mir genau andersherum sitzt. Da es nur ein Bauteil mit der Kodierung "blau-grau-gold-gold" gibt und es ein Widerstand ist, sollte die Richtung doch egal sein, oder?

Ja, die Richtung ist völlig egal. Wird R28 selbst auch heiß oder nur darunter? Oder eine von den Lötstellen? Klingt für mich so, als wenn irgendwo ein Kurzschluss ist und deshalb zu viel Strom fließt, so dass es heiß wird.

4. Die Distanz-Sensoren zeigen nun beide keine Reaktion und stehen permanent auf "D=995 995" - muss das im Demo-Code so sein?

Vermutlich das ct-Bot.eep-File nicht ins EEPROM übertragen nach dem Flashen des neuen ct-Bot.hex files? Dann fehlen die Kalibrierungsdaten für die Distanzsensoren und sie zeigen 995 an.

(Nur am Rande: 5. Ich wollte eine Firmware mit Bootloader kompilieren, aber es gab wohl kürzlich ein SVN-Update (auf ct-Bot 1970 und ct-Sim 1949). Seitdem spuckt der Clean-Vorgang sehr viele Fehler aus (unter Eclipse Lunar, mit den vorigen Repository-Versionen gab es keine Fehler), ein Auszug:

Code: Alles auswählen

Description	Resource	Path	Location	Type
AmbientLight cannot be resolved to a type	World.java	/ct-Sim/ctSim/model	line 420	Java Problem
AmbientLight cannot be resolved to a type	World.java	/ct-Sim/ctSim/model	line 420	Java Problem
Appearance cannot be resolved to a type	CtBotShape.java	/ct-Sim/ctSim/model/bots/ctbot	line 442	Java Problem
Appearance cannot be resolved to a type	ParcoursLoader.java	/ct-Sim/ctSim/model	line 315	Java Problem
[...]
ArrayList<Point3d> cannot be resolved to a type	CtBotShape.java	/ct-Sim/ctSim/model/bots/ctbot	line 323	Java Problem
ArrayList<Point3d> cannot be resolved to a type	CtBotShape.java	/ct-Sim/ctSim/model/bots/ctbot	line 324	Java Problem
AxisAngle4d cannot be resolved to a type	SimUtils.java	/ct-Sim/ctSim	line 151	Java Problem
BoundingSphere cannot be resolved to a type	MasterSimulator.java	/ct-Sim/ctSim/model/bots/ctbot	line 340	Java Problem
[...]
Javadoc: javax.media cannot be resolved to a type	SceneGraphStreamWriterFixed.java	/ct-Sim/ctSim/model/scene	line 50	Java Problem

Solche Fehler bekommt man, wenn Java3D nicht richtig installiert ist oder die Java3D-Installation von Eclipse nicht gefunden wird. Am SVN-Update liegt das nicht denke ich.

Schöne Weihnachten,
Tobi