Probleme mit den Liniensensoren

Hallo zusammen.
Ich hab folgendes Problem mit der Biene:

Direkt nach dem Zusammenbau des Roboters hab ich die Kalabrierung der Sensoren nach Tutorial Anweisung durchgeführt und alles war i.O. Danach die ersten Beispielprogramme durchlaufen lassen und bis hier hin noch keine Probleme. Hab dann ein paar Wochen verstreichen lassen hab gestern angefangen ein kleines Programm zur Linienverfolgung zu schreiben. Jedoch hat sich dabei rausgestellt, dass die mir die Funktion (sprich die Sensoren selbst) zur Rücke des Reflexionsgrad "nichts" zurückgibt. Ich also wieder das calibration.hex aufgespielt und wollte neu kalibrieren da taucht dann plötzlich das Problem auf, dass meine Normierung nciht mit einem blinken von LEDs quittiert wird und nach dem Speichern der Werte (beide Fühler nach hinten) zuerst 5 mal die beiden roten Front-LEDs blinken und dann erst mit den anderen 4 LEDs Rückmeldung vom Reflexionsgrad kommt. Danach war aber dennoch kein Benutzen der Sensoren in meinem oder dem Tutorialprogramm zur Auswertung der Liniensensoren möglich. Es scheint so als würde beim Aufspielen eines neues Programms die gespeicherten Werte vollends verschwinden.

Wer weiß einen Rat.
Danke

Falls nicht das mitgelieferte Windows-Flash-Programm zur Übertragung der Software verwendet wird, muss man darauf achten, dass das EESAVE-Fuse-Bit auf 0 (0=aktiviert!!) gesetzt wird, da ansonsten das EEPROM bei jeder neuen Programmierung gelöscht wird.

Du meinst den NIBObee Programmer? Den Benutz ich aber. Mache also alles (für mich zumindest) nach Vorschrift sprich Tutorial.

Hat denn keiner eine Idee?

Die beiden Front LEDs leuchten wie gesagt 5 mal beim Kalibrieren auf. Kann das nicht so eine Art Fehlercode sein?

Ähem, versuchst du eventuell, das Programm "Calibration.C" aus dem src-Ordner zu benutzen?
Hiesse ja, compiliert auch "Calibration.hex"...?

Nein. Benutze einfach die calibration.hex. Hab die C-Datei nicht geöffnet und auch nicht neu compiliert.

Könnte es sein, dass Dein Programm zur Linienverfolgung die gespeicherten Werte für die Sensoren überschreibt?
Ich meine jetzt nicht beim Aufspielen sondern bei der Ausführung.
Das Du eventuell unbeabsichtigt Werte dort ablegst wo die Kalibrierungswerte stehen.

Das erklärt zwar nicht das blinken aber es wäre eine Möglichkeit.

Hast Du die Sensoren mal auf funktionstüchtigkeit hin überprüft?
Ich könnte mir vorstellen das ein Defekt an der Stelle zu einem derartigen Verhalten führen könnte.

MfG JoeBlack

Keine Ahnung ob ich was überschreibe. Kann aber eigentlich nciht sein, weil ich nur die Tools genutzt habe die beim Roboter dabei waren. Und explizit eine Speicherzelle angesprochen habe ich noch nicht. Wüsste also nicht wann und wo das passiert wäre. Das komische ist ja dass wenn ich erneut kalibriere und der "Rote LED Fehler" weg ist die Liniensensoren im calibration.hex funzen aber dann wenn ich dann das Beispielprogramm aus dem Tut aufspiele es nicht mehr geht.

Dem Verständniss halber, Du verwendest also bislang nur die bereits fertigen .hex-programme die bereits mitgeliefert wurden und hast daran auch nichts geändert oder angepasst?
Hast Du am Bot selbst irgendwelche Veränderungen vorgenommen?

Möglicherweise irgend eine Kleinigkeit die erstmal garkeine negativen Auswirkungen gezeigt hat?
Und kann man mögliche Kurzschlüsse an den Signalleitungen der Sensoren ausschliessen durch Litzenadern oder Schmutz oder ähnliches?

Mag weit hergeholt sein, aber manchmal sind die Ursachen recht abstrakt.

MfG JoeBlack

Wie gesagt. Die Sensoren funktionieren ja ABER eben nur beim calibration.hex Programm und nur nach dieser blöder "Fehlermeldung" (wenn es denn eine ist). Hab auch schon eigenen code geschrieben, aber alles mit Befehlen der Standardlib. Aber er/ich muss ja mal was falsch gemacht haben wenn er sich die Messdaten beim Kalibrieren nicht speichert. Keinen Ahnung.

Kann man den Atmega16 "reseten"? Mir fällt nichts mehr ein. Achso: An Hardware habe ich auch noch nicht gearbeitet.

Ist das Folgeprogramm von Dir geschrieben oder war es bereits dabei?
Denn wenn es von Dir ist wäre es durchaus möglich, das es mit Zwischenwerten während der Ausführung überschreibt was für die Sensoren abgelegt war.
Vieleicht könntest Du in diesem Fall einfach mal Dein Programm posten.

Falls es als .hex bereits mitgeliefert wurde denke ich, dass man es als Fehlerquelle erstmal ausschliessen kann.

MfG JoeBlack

Also beim ersten Versuch ein Linienverfolgungsprogramm zu schreiben hab ich ein eigenes Programm verfasst in wlchem ich eine until(<Bedingung>) Befehl verwendet habe. Sonst nur das übliche. Auch habe ich nie ein Speicherzelle im uC direkt angesprochen. Nachdem ich merkte das da was nciht sitmt hab ich einfach das Tut-Programm zum auswerten der Liniensensoren verwandt und es ging dennoch nicht. Also würde ich mal das mal als Fehler ausschließen. Hab mir jetzt mal die aktuelle lib 1.2 besorgt, es gab aber leider immernoch keine Besserung. Hab aber festgestellt, dass die delay-Funktion mit ihren Zeitlichen angaben um den Faktor 10 daneben liegt sprich der Befehl: dealy(100) verzögert nicht 100ms sondern genau 1s sprich 1000ms.
Ich hab das Gefühl die Biene macht was sie will. So komm ich nicht zu Rande. Dreck da. Wirklich. Ich könnte grüne Strahlen kotzen. Sorry dafür aber ich muss mit ein wenig Luft machen. Wie kan das denn sein dass nur bei mir der Mist passiert.

Ach ich vergaß:
Kann ich einfach mal den uC gegen einen anderen Atmega16 tauschen oder würde das nicht gehen?

Nenene, da stimmt was nicht.
Die delay()-Geschichte passt schon, so leidlich.
Hast du im AVR-Studio auch die richtige Frequenz eingestellt in den Projekt-Einstellungen? Check das mal genau (sind ne Menge Nullen, da ist es leicht, eine zu vergessen)..
Wenn nämlich _die_ nicht passt, dann hauen eine ganze Menge Dinge nicht hin, z.B. alles, was PWM braucht.
Oder ist vielleicht dein Quarz defekt/nicht richtig eingelötet?


Und du kannst den Atmega16 gegen nen anderen tauschen, musst dem neuen aber zuerst die Fusebits korrekt setzen.
Frag aber bitte jemanden von den Profis, wie das geht, damit kann man sich auch aus dem Prozessor komplett aussperren, soweit ich weiss.

Ausserdem denke ich nicht, dass deiner kaputt ist, denn er arbeitet ja.

Ne das mit der Frequenz passt schon. Hab das 3 mal gecheckt. Was meinst du das mit der delay-Funktion passt schon. Der Faktor 10 ist doch dazwischen.

Nö, wenn ich schreibe delay(1000) komme ich ziemlich gut auf eine Sekunde.
Von daher stimmt bei dir irgendetwas nicht.
Wobei: allzu präzise ist die Geschichte nicht, aber die zehnfache Zeit wird die wohl nie brauchen.

Hallo,

zunächst einmal: Hat die Kalibrierung überhaupt funktioniert? Also wenn Du die Biene auf eine schwarze Unterlage stellst dürften keine LEDs leuchten. Wenn Du sie auf eine weiße Unterlage stellst, müssten alle vier LEDs leuchten. Bei Annäherung an eine weiße Unterlage leuchten zuerst die gelben LEDs und später die roten LEDs zusätzlich.

Kannst Du dieses Verhalten beobachten? Die linken und rechten LEDs werden vermutlich zu unterschiedlichen Helligkeitsstufen reagieren, wenn die beiden Seiten sich nicht gleichzeitig ändern, ist das also normal. Aber grundsätzlich sollten die LEDs bei schwarzem Untergrund aus und bei weißem an sein. Was noch sein dürfte, dass die roten LEDs nicht angehen, sondern erst dann, wenn man ein Stück weißes Papier immer näher an den Liniensensor bringt.

Zitat:

---

Zitat von wastel

Also beim ersten Versuch ein Linienverfolgungsprogramm zu schreiben hab ich ein eigenes Programm verfasst in wlchem ich eine until(<Bedingung>) Befehl verwendet habe.

---

until in c??? Kenn ich nicht. Ich vermute, Du meinst do { } while (<Bedingung>); Nur damit wir nicht völlig aneinander vorbei reden...

Kannst Du vielleicht mal den Code veröffentlichen? Deine ganzen Angaben zu den Problemen sind viel zu allgemein, als man da irgendwas beurteilen könnte, sorry.

Zitat:

---

Sonst nur das übliche.

---

Was ist denn "das übliche"? Es gibt weniger Mißverständnisse, wenn Du das genauer ausführst.

Zitat:

---

Nachdem ich merkte das da was nciht sitmt hab ich einfach das Tut-Programm zum auswerten der Liniensensoren verwandt und es ging dennoch nicht.

---

So, was hast Du gemacht? Ein Tut-Programm benutzt? Hupt das? Sorry, aber Du schreibst echt sehr unverständlich und das macht es schwer Dir zu helfen. Was hat dann funktioniert und was hat nicht funktioniert?

Zitat:

---

Hab aber festgestellt, dass die delay-Funktion mit ihren Zeitlichen angaben um den Faktor 10 daneben liegt sprich der Befehl: dealy(100) verzögert nicht 100ms sondern genau 1s sprich 1000ms.

---

Die Routinen sind Makros zu der libc - vielleicht ist Deine Version buggy? Achte genau darauf, welche Versionen vom AVR-Studio kompatibel sind.

Zitat:

---

Ich hab das Gefühl die Biene macht was sie will. So komm ich nicht zu Rande. Dreck da. Wirklich. Ich könnte grüne Strahlen kotzen. Sorry dafür aber ich muss mit ein wenig Luft machen. Wie kan das denn sein dass nur bei mir der Mist passiert.

---

Den Teil wünsche ich hier nicht so gern zu Lesen, auch wenn ich Dich verstehen kann.

So, ich hoffe, Du siehst diesen Post als Motivation und nicht als Motz-Post. Denn ich würde gerne helfen, wenn ich denn das Problem verstehen würde...

Ciao bantyy

Hallo bantyy
Soweit ich mich erinnern kann hat das Kalibrieren funktioniert, sprich die Biene hat wie du schon beschreiben hast mit entsprechender LED Ansteuerung auf den Reflexionsgrad des Untergrundes reagiert (im calibration.hex Programm!!!).
Nun ist es leider so, dass ich die Biene ne Woche hab stehen lassen und mich dann erst wieder daran begeben hab. Mein Code zur Linienverfolgung enthielt dieses "until<Bedingung>"-Befehl. Das war noch ein "logischer" Überrest aus dem Programm was ich für einen NXT (Lego-Roboter) geschrieben hab. Ich denke das war Teil dieser eigenen Lib. Hab aber die Zeile, wie du schon beschreiben hast, mit do{}while() ersetzt. Den Code hab ich leider gelöscht bzw. nicht gespeichert weil er ja nicht funktionierte. Aber Ich hab außer der do-while-Schleife nur Befehle aus dem Tutorial verwendet und diese auch dirkt aus diesem rauskopiert.
Um der Sache nun auf die Spur zu kommen hab ich das Tut-Programm (Tutorial vom NIBObee^^, es hupt also nicht) zum Auswerten der Liniensensoren unverändert übernommen und auf die Biene aufgespielt. Ergebnis war, dass die LED aus (dunkel blieben), sprich keine Erkennung des Untergrundes. Auch eine Veränderung der Standardparameter get_LINE-Befehl von 160 bzw. 250 auf niedrigere Werte schaffte keine Abhilfe. Danach hab ich wieder die calibration.hex aufgespielt und wollte die Sensoren neu Kalibrieren. Also wieder Ablauf streng nach Vorschrift, jedoch quittierte die Biene die einzelnen Referenzierungen nicht und begann nach dem "Schwarzabgelich" mit den beiden roten Front-LEDs 5mal zu leuchten (blinken) danach jedoch funktionierte die Untergrunderkennung im calibration.hex tadellos (aber NUR dort!!!!). Danach wieder das Beispielprogramm aus dem Tutorial und wieder keine Rückmeldung des Untergrunds.
Bei der Lib weiß ich garnicht worauf ich da achten muss. Hab das AVR Studio in aktueller Version und die lib-Version 1.2 vom NIBObee.

Randnotiz: Hab mittlerweile eine RS232 Schnittstelle am Nibobee integriert. Hoffe darüber mal ein wenig Analyse betreiben zu können. Aber auch hier sind noch Probleme. Beschrieben in einem anderen Threat.

PS: Werde mich jetzt wieder benehmen. ^

Mal so zwischengefragt: hast du eventuell einen anderen Unterbau unter deiner Biene?
Die Liniensensoreinheit ist zwar gut, aber auch empfindlich, wenn der Abstand zum Untergrund nicht exakt ist (die Biene muss mit leicht angehobener Nase dastehen) funktioniert es nicht richtig.
Steht sie vorne was höher, klappts nicht ordentlich, steht sie gerade, auch nicht mehr.

Nein das passt schon. Wie gesagt die Liniensensoren funktionieren aber eben nur bei der calibartion.hex. Danach nicht mehr. Ergo: Hardwarefehler ausgeschlossen. Zumindest meiner Meinung nach. Aber ich lasse mich gerne noch belehren. Aber vielen Dank. Bin für jede Anregung dankbar.

Ok, gehen wir das Kalibrieren mal durch, ich hab eben das Programm mal raufgespielt:

Man platziert den Roboter mit allen Bodensensoren auf einer weißen Fläche

-jetzt leuchten ALLE vier LED`s

und drückt den linken Fühler nach hinten.

-da blinken die Gelben ein paarmal, anschliessend gehen wieder alle vier an

Danach stellt man den NIBObee
auf eine schwarze Fläche

-jetzt leuchten drei, eine der Roten nicht, die kommt erst, wenn ich das Bienchen etwas kippe (ich weiss aber, dass meine trotzdem funktioniert)

und drückt den rechten Fühler nach hinten.

-dann blinken die roten Einigemale

werden permanent im EEPROM gespeichert, wenn man danach beide
Fühler nach vorne drückt

-dann blinken alle vier ein paarmal.

Nun compiliere ich eben mal (hab ich irgendwo, aber keine Ahnung ob noch im Originalzustand, deswegen neu) das Beispielprogramm aus dem Tutorial, Seite 38, Liniensensoren.
Unverändert, wohlgemerkt.

Stelle ich die Biene auf den gleichen, weissen Untergrund wie eben, sind alle vier LED an.
Rücke ich sie nach rechts sachte über das schwarze Feld, geht zuerst die rote LED aus, kurz drauf auch die gelbe auf dieser Seite (halt da, wo sie übers schwarze gerät), danach auch die zweite rote und die dann die letzte auch.
Also: je heller es wird, umso mehr Licht macht die Biene.
Dunkel: kein Licht, etwas Licht: gelb, viel Licht, gelb und rot.

Testuntergrund: einfach ein Zeichenblatt mit schwarzem Marker stellenweise mehrmals übermalt.

Ja so sollte es funktionieren. Tut es aber nicht bei mir. Wie es bei mir abläuft hab ich jetzt ja schon ausführlich beschrieben oder fehlt in meinen Ausführungen noch was? Dann ergänze ich das gern.

Hast du mal (Handy oder andere Digicam) nachgesehen, wie oder ob die IR-Dioden richtig arbeiten?

Bild hier  

Hallo,

so, jetzt kann auch ich folgen :-)

Zitat:

---

Zitat von wastel

Hallo bantyy
Soweit ich mich erinnern kann hat das Kalibrieren funktioniert, sprich die Biene hat wie du schon beschreiben hast mit entsprechender LED Ansteuerung auf den Reflexionsgrad des Untergrundes reagiert (im calibration.hex Programm!!!).

---

Das klingt ja gut. Leider habe ich kein AVRStudio sondern arbeite direkt in der Kommandozeile, deshalb muss ich mal blöd nachfragen: Kannst Du irgendwie das EEPROM auslesen? An Adresse 0 stehen - wenn ich mich da richtig erinnere - Werte für die Kalibrierung. Dann könntest Du einfach mal nachsehen, was da für Werte drin gespeichert sind. 0xff deutet auf "nicht geschrieben" hin - entweder hat calibration aus einem Grund nicht funktioniert oder beim neu flashen sind die EEPROM-Werte mit überschrieben worden (wie hier schon jemand anderes anmerkte).

Zitat:

---

Mein Code zur Linienverfolgung enthielt dieses "until<Bedingung>"-Befehl. Das war noch ein "logischer" Überrest aus dem Programm was ich für einen NXT (Lego-Roboter) geschrieben hab.

---

Ah, interessant :-) Ich hab mir zuerst die Biene zugelegt und inzwischen auch einen NXT. Leider habe ich mich mit letzterem nur theoretisch beschäftigen können - Zeitmangel...

Zitat:

---

Danach hab ich wieder die calibration.hex aufgespielt und wollte die Sensoren neu Kalibrieren. Also wieder Ablauf streng nach Vorschrift, jedoch quittierte die Biene die einzelnen Referenzierungen nicht und begann nach dem "Schwarzabgelich" mit den beiden roten Front-LEDs 5mal zu leuchten (blinken)

---

Also dass der Rest nicht funktioniert hat ist natürlich seltsam, aber dass der Schwarzabgleich durch blinken der roten LEDs signalisiert wird, ist doch korrekt? Zumindestens habe ich das so verstanden.

Zitat:

---

Bei der Lib weiß ich garnicht worauf ich da achten muss. Hab das AVR Studio in aktueller Version und die lib-Version 1.2 vom NIBObee.

---

Mh, also mir kommt die Geschichte sehr komisch vor. Auch mit dem Faktor 10 bei der Zeit. Du hast nicht zufällig einen ATmega 164 anstelle eines ATmega 16 bekommen? Der ist moderner und hat unter anderem eine Fuse, so dass der Takt erstmal durch 8 geteilt wird - und genau so ist die Standardeinstellung.

Apropos Fuses: Oder ist da irgend etwas faul? Wie sind denn bei Dir die Fuses eingestellt? Welcher Oszillator ist denn aktiviert? Es sollte gar keiner aktiviert sein, da der ATtiny den Takt generiert und direkt auf den Oszillator-Eingang des ATmega 16 gibt.

Hast Du generell Probleme, dass alles sehr langsam läuft oder ist Dir das nur bei Delay aufgefallen?

Zitat:

---

PS: Werde mich jetzt wieder benehmen. ^

---

Schon in Ordnung :-) Ich meinte das ehrlich nicht böse :-)

Ciao bantyy

Hi Bantyy

um der ganzes sache mal auf die Spur zu kommen hab ich jetzt ne RS232 Schnittstelle in Eigenbau integriert, sprich um den EEPROM auszulesen. Leider gibt es auch hier Probleme. Siehe diesen Threat https://www.roboternetz.de/phpBB2/ze...g.php?p=504981
Ich würde dir also gern mehr Auskunft über die Fuses geben aber leider kann ich das NOCH nicht. Aber der uC sollt stimmen. Steht zumindest ATMEGA16 16PU0911K drauf. Sollte also passen.
Das mit den roten LEDs kommt mir dennoch etwas spanisch vor. In meiner Erinnerung wurde die Referenzierung anders quittiert.
Da ich mir beim besten willen nicht vorstellen kann, dass es ein Hardwarefehler ist hab ich jetzt bei nicai-systems direkt einen neun uC bestellt. Mal sehen ob das Abhilfe schaft. Da ich den NIBObee für eine kleine Studienarbeit brauche ärgert es mich einfach, dass ich ohne voll funktionsfähige Basis einfach nichts machen kann. Und bei der Fehlersuche geht einfach mega viel Zeit drauf. Hoffe mit einem neuen uC ist es getan. Wenn nicht stehe ich ein wenig schlecht da. Und wenn das nicht hinhaut hoffe ich zumindest mit einer später funktionierenden Schnittstelle der Sache auf die Spur zu kommen, aber die geht ja auch noch nicht.
Das mit dem Zeitfehler ist mir jetzt nur bei dem Delay aufgefallen. Aber zwischendurch hat der NIBObee einfache Befehle nicht richtig ausgeführt. Zum Beispiel hab ich zum Test einfach mal eine LED einschalten lassen. Als das Programm dann aufgespielt war hat die nur einmal kurz geblinkt und war dann wieder aus. Aber das ist ne andere Baustelle. Aber das ist nur einmal aufgetaucht. Später hat das gleiche einfache Programm dann alles richtig gemacht und die LED dauerhaft eingeschaltet. Also irgendwas stimmt hier einfach nicht. Aber das wissen wir ja.

Hallo,

Zitat:

---

Zitat von wastel

Aber der uC sollt stimmen. Steht zumindest ATMEGA16 16PU0911K drauf. Sollte also passen.

---

Stimmt, die Bezeichnung ist korrekt.

Zitat:

---

Aber zwischendurch hat der NIBObee einfache Befehle nicht richtig ausgeführt. Zum Beispiel hab ich zum Test einfach mal eine LED einschalten lassen. Als das Programm dann aufgespielt war hat die nur einmal kurz geblinkt und war dann wieder aus. Aber das ist ne andere Baustelle. Aber das ist nur einmal aufgetaucht. Später hat das gleiche einfache Programm dann alles richtig gemacht und die LED dauerhaft eingeschaltet. Also irgendwas stimmt hier einfach nicht. Aber das wissen wir ja.

---

Ehrlich gesagt glaube ich an einen Elektronikfehler. Ich vermute Kontaktprobleme an irgendeiner Stelle. Zum Beispiel an der Spannungsversorgung oder dem Takteingang des ATmegas. Überprüf doch mal all Deine Lötstellen.

Klar, theoretisch kann der ATmega einen Defekt haben, ich vermute allerdings eher nicht. Seit 10 Jahren habe ich mit uC beruflich zu tun und noch nie einen defekten uC gehabt.

Ciao bantyy

Ok. Werd morgen noch mal ganz genau alles durchgehen. Kann auch ein schlechter Akku sprich falsch geladene Akkus den Roboter dauerhaft schädigen?


Aber warum funktioniert es dann bei der calibration.hex und dann nicht mehr?

Zitat:

---

Kann auch ein schlechter Akku sprich falsch geladene Akkus den Roboter dauerhaft schädigen?

---

Eigentlich nicht. Es sei denn, du hast deine Akkus "überredet", eine zu hohe Spannung zu liefern.;)
Ich betreibe meine Biene inzwischen seit Monaten mit nem 2s-LiPo, aber mit Spannungsregler natürlich. Original ist keiner verbaut, also normale Batterien könnten durchaus Schaden anrichten.
Allerdings ist einiges in der Biene schon spannungsabhängig, auch die Liniensensoren.

Also.
Hab heut Morgen mal wieder die Hardware gecheckt. Spannungsversorgung ist an allen ICs ok (4,8-4,9V). Darauf hin hab ich mal die Schaltpläne vom NIBObee rausgekramt und bin die Pfade der IR-LED mal nachgegangen. Beim Verwendung des Tutorialsprogramms wurden ordnungsgemäß die IR LEDs eingeschaltete (Hab das mit meiner Digicam überprüft: Danke an Rabenauge). Danach hab ich die Analogeingänge am uC and denen die Photodioden angebracht sind überprüft. Auch hier ist meiner Mrinung nach alles in Ordnung. Wenn ich den Reflexionsgrad des Untergrund ändere verändert sich die Spannung an den Eingängen deutlich und logisch (von ca. 1,7 - 0,6 Volt). Also it in diesem Pfad mal alles bene.
Leider kann ich die Frequenzen nicht überprüfen, da ich kein Ossi hier hab. Werd das aber am Montag im Labor mal in Angriff nehmen. Aber wenn die auch stimmen kann es ja eigentlich nur noch am uC liegen aber ich weiß beim besten Willen nicht was da schief gegangen ist.

@bantyy: Ich glaub dir wenn du sagst, dass mit dem uC kann nicht sein. Aber was soll ich denn noch machen. Es funzt ja fast garnichts. Auch die serielle Schnittstelle (was mit den Plänen und dem Code im Netz wirklich kein Problem ist) geht nicht. Alles in allem steh ich sehr ratlos da.

Hallo,

Zitat:

---

Zitat von wastel

Aber warum funktioniert es dann bei der calibration.hex und dann nicht mehr?

---

"Funktioniert" ist bei Deiner Beschreibung irgendwie der falsche Ausdruck. Ich habe das Gefühl, Dein Roboter funktioniert manchmal und dann wieder nicht. Und solche "Funktioniert manchmal und manchmal nicht"-Probleme sind meistens kalte oder schlechte Lötstellen, schlechter Kontakt, abgerissener Pin von einem Bauteil oder ähnlich. Bei gekauften Produkten kommt dann noch der Haarriss dazu - den vermute ich hier jetzt mal nicht.

Ciao bantyy

So. Das Problem wurde erkannt und gebannt.
War heute im Labor und bin nochmal alles durchgegangen. Wie zu erwarten keine Fehler in der Hardware. Hab dann den Prozessor eines Freundes in meinem NIBObee verbaut und schon funktionierte alles (serielle Schnittstelle und die Liniensensoren). Wir haben dann mal die Prozessoren verglichen und festgestellt, dass mein Atmega noch (oder wieder) auf den internen Takt von 1 MHz getaktet war. Schnell im Internet nachgehschaut wie meiner gefused sein soll und schon war das Problem Geschichte.

Danke an alle die geholfen haben.

Hallo,

Zitat:

---

Zitat von wastel

Wir haben dann mal die Prozessoren verglichen und festgestellt, dass mein Atmega noch (oder wieder) auf den internen Takt von 1 MHz getaktet war.

---

Ganz ehrlich: Mir macht das Schreiben in diesem Forum im Bezug auf Hilfe keinen besonderen Spaß.

Weisst Du warum? Von den paar Mal, wo ich das hier versucht hatte, haben die Anfrager sich gar nicht mehr gemeldet und die zwei Mal, wo ich durchaus mal zwei oder drei Stunden rein investiert habe, kamen die Leute mit "eigenen" Lösungen an, die sie viel schneller gefunden hätten, wenn sie meine Tipps einfach mal befolgt hätten.

So auch Du - das mit den Fuses hatte ich recht früh als Tipp gegeben.

Kann mir mal irgendjemand erklären, was ich hier falsch mache? Sind meine Texte zu lang? Zu schwer zu verstehen? Zu umständlich beschrieben? Seh ich doof aus? Ach so, ihr seht mich ja gar nicht...

Also woran liegts? Ich kann ja nur etwas ändern, wenn ich weiß was los ist.

Ciao bantyy

Hallo Bantyy,

ich hab deinen Tipp mit den Fuses nicht überlesen nur war es mir zu Hause nicht möglich dies zu Prüfen. Der Prozessor steckt ja in NIBObee und ich konnte nur mit dem USB-Anschluss kommunizieren. Zudem muss ich auch zugeben, das mir das entsprechend tiefe Verständnis, dass du in Thema uC mitbringst, fehlt und mir somit das überprüfen der Fuses, wie schon erwähnt, nicht leicht von der hand ging.
Zudem fehlte mir der Vergleichstyp meines Freundes was nun der Unterschied bei den Fuses ist.
Ich sehe schon und schätze auch sehr, dass du mit sehr ausführlichen Antworten und Hilfestellungen mir dei dem Problem geholfen hast und mich auch schlussendlich auf den richtigen Weg zur Fehlererkennung gebracht hast.
Das war kein Zufall aus meinem Tun heraus sondern eine intensiver Abarbeitung deiner Vorschläge zu den jeweiligen Zeiten wo mir die entsprechenden Mittel zu Verfügung standen.
Dementsprechend hab ich mich auch, nachdem der Fehler erkannt wurde, nochmals hier gemeldet und mich für die ausschlaggebende Hilfe bedankt.

Sollte das nicht in entsprechender Würdigung deines Beitrags geschehen sein, bitte ich das zu entschuldigen und hole das hiermit in aller, wirklich aufrichtig gemeinter, Form nach.

Danke

Und gerade wegen deines Bemühen schätze ich ab sofort das Forum und werde hier auch weiterhin versuchen mir Rat einzuholen und soweit es mir möglich ist anderen Benutzern zu helfen.

Höflichst Wastel

Hallo wastel,

oh Mist, ich werde das Gefühl nicht los, dass es manchmal die "falschen" erwischt :-(

Ich hab wohl etwas überreagiert - sorry dafür. Und ich schreib hier noch so großspurig, dass Du Deine Überreaktionen für Dich behalten kannst *asche über mein Haupt*

Ich denke, hier ist dann doch alles ganz gut gelaufen :-)

Zitat:

---

Zitat von wastel

ich hab deinen Tipp mit den Fuses nicht überlesen nur war es mir zu Hause nicht möglich dies zu Prüfen.

---

Mh, hier könnte ich den fiesen und nutzlosen Kommentar abgeben: "Ich hab Linux, bei mir gehts" ;-) Welches Programm benutzt Du denn zu hause zum brennen? Kommst Du damit nicht an die Fuses? Weil bei meinem Programm klappt das auch direkt in der Biene - zu hause habe ich auch keinen anderen Programmer und den Bienen-Controller hab ich noch nie @work mitgenommen...

Zitat:

---

Zudem muss ich auch zugeben, das mir das entsprechend tiefe Verständnis, dass du in Thema uC mitbringst, fehlt

---

Hab ich da zu sehr fach gesimpelt? Hätte ich das einfacher schreiben können?

Und vielen dank nochmal für das "Honig um den Mund schmieren" - es freu mich, wenn ich helfen konnte :-) Demnächst reicht wieder ein normales Danke - wie Du es ja auch schon vorher geschrieben hattest. Ich war wohl etwas genervt - sorry nochmal.

Schön, dass Du jetzt wieder weiterkommst - das ist ja das wichtigste.

Viel Erfolg weiterhin :-)

Ciao bantyy

Einigen wir uns auf ein "Shake hands". ;-)

In diesem Sinne => Thema beendet !!

Bis zum nächsten mal.