Wer findet den Fehler, Belohnung

[damfino]

Ich komme einfach nicht weiter und finde den Fehler nicht, also wer den Fehler findet und den Roboter einwandfrei zum laufen bringt kriegt 50€.

Im Anhang der aktuelle Code, und der Referenzcode vom letzten Jahr mit alter Hardware. Aus dem Referenzcode von 2 mit I2C verbundenen Atmega1284 ist der aktuelle Code für einen Atmega2560 entstanden.

Nur letztes Jahr ist der Roboter einwandfrei gefahren (>200 Betriebsstunden), dieses Jahr nicht.

Fehlerbild:
Reagiert selten auf Bumper oder Schleifensensoren
Bei Vorwärtsfahrt wird auf einmal für 1/2s auf Rückwärts geschalten, dann wieder vorwärts weiter (normalerweise werden immer Pausen bei Richtungswechsel gesetzt damit die Fahrmotoren auslaufen können)
Während Messerstart fährt der Roboter auf einmal los
Im Fahren zeigt er auf einmal am LCD den Modus Zurücksetzen an, auch Speed für rückwärts wird gesetzt, fährt aber ohne Halt ruhig vorwärts weiter.

Was funktioniert: im Einzeltest eigentlich alles, Menüs funktionieren, Kompass geht, GPS kommt an, Daten gehen über Bluetooth raus, Messerdrehzahl wird eingeregelt, wird gestoppt wenn Messerdrehzahl zu niedrig ist, Sensoren und Bumper werden auch immer super erkannt. Auffällig nur bei Einzeltest Messerstart drehen sich dann auch die Fahrmotoren mit, was nie vorkommen sollte.
Für Einzeltests gibt es die Funktion testsbeieinschalten, die bei Tastendruck gleich nach dem Hauptschalter an ausgeführt wird.

Fuses:
Ext Crytall OSc 8- 65ms (16Mhz Quarz)
EESave on
Brownout 4.3V

Bootloader vorbereitet und getestet, derzeit nicht verwendet.
Akkuauswertung nicht verwendet da der LiIon ja defekt ist, verwende zum Testen einen anderen alten Akku.

Code ist noch großteils ins Spaghettiform, fange gerade an in einzelne Module aufzusplitten, aber das geht auch nur wenn es mal funktioniert, sonst baue ich vielleicht noch zusätzliche Fehler ein.
Vieles vom Code ist praktisch identisch zum Referenzcode, nur angepasst an zB neue Anzahl Impulse/Radumdrehung oder Umstellung von Winkel Radiant auf Grad und der Integration GPS/Bluetooth. Dafür ist der Datentransfer zum Slave entfallen.

Programmiert wird mit Atmel Studio 6.2

LG Werner

[Unregistriert]

Es scheint mir das die ansteurung von die H-brucke fehl schlagt. Irgendwo has das Signal von Messer motor einfluss auf die Antriebsmotoren. Ich sollte erstmal in diese Richtung suchen. Hast du ein Schaltplan von das System ?

[damfino]

Motorsteuerung ist 3x diese: http://www.mikrocontroller.net/artic..._Mosfettreiber
Fahrmotoren haben Relais für die Fahrtrichtung nachgeschaltet.


Die Platine mit den Treibern war schon letztes Jahr im Einsatz und blieb unverändert. SD Pins haben Pulldown.


LG Werner

[mare_crisium]

Ich hatte sowas ähnliches in meinen AVR-Programmen: Alle Module funktionierten im Einzeltest fehlerfrei, nach dem Flashen des Gesamtprogramms (in Assembler aus AVR-Studio 4.18 mit MKII) stürzte es aber aus unerfindlichen Gründen ab. Per Zufall habe ich dann gemerkt, dass die Stabilität des Programms von der Reihenfolge der .includes abhing, mit denen ich die Module einband. Das Gesamtprogramm funktionierte fehlerfrei, wenn ich das TWI-Modul als letztes einband.
Spiel' doch mal mit der Reihenfolge der includes. Fände es schade, wenn Dein soweit fortgeschrittenes Projekt noch scheitern sollte.
Ciao, mare_crisium

[damfino]

Na super, das wäre ein Compiler Fehler. Hatte schon mal so einen Verdacht als ich ein paar Zeilen Code 1:1 kopierte und nichts mehr ging. Habe deswegen extra auf das neue Studio 6.2 gewechselt.
Werde mit den includes herumspielen auch wenn es da 100erte mögliche Reihenfolgen gibt.

LG Werner

[schorsch_76]

Spagetti Code ... nachträglich aufräumen ..... unwahrscheinlich....

Spagetti Code enthält meist ziemlich viele Fehler. Ich denke dass sich deine Module über Variablen die in mehreren Funktionen/Modulen verwendet werden stören.

Abhilfe: Sauberer Code von Anfang an.