Wer findet den Fehler, Belohnung

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:mad:.

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:confused:. 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

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 ?

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

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

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

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.

Zitat:

---

Abhilfe: Sauberer Code von Anfang an

---

Das ist klar, aber nicht einfach wenn man bei Projektstart erst zu Programmieren anfing.

Jetzt den gleichen Funktionsumfang von Null weg zu starten wäre ein enormer Aufwand

Zitat:

---

enthält meist ziemlich viele Fehler

---

einen davon zu nennen wäre hilfreich!
Der Compiler ist extra scharf gestellt und meldet schon die AVR GCC Erweiterungen, aber keine echten Fehler.

Hier sind ein paar Warnungen und Fehler rein über statische Analyse des Codes.

Anhang 30529

Unintialisierte Variable führen bsp. zu undefiniertem Verhalten. manchmal geht's .. Manchmal nicht ....

Hallo!

Zitat:

---

Zitat von damfino

Jetzt den gleichen Funktionsumfang von Null weg zu starten wäre ein enormer Aufwand.

---

Aus eigener Erfahrung: ich habe bisher sehr umfangreiche ASM Programme (praktisch wie bei Hochsprache) aus bis dahin archievierten geprüften Programteilen (z.B. Unterprogrammen basierten auf Programmablaufdiagrammen) sehr schnel gewünscht in neues Programm zusammen kopiert. Ich mache immernoch alles in kleinen leicht durchschaubaren Schritten und kenne "Spagetti Code" gar nicht. ;)

Bin nach längerer Zeit wieder zum testen gekommen:
1x Vollprogramm Atmelstudio 6.2 und 1x Vollprogramm mit dem letzten WinAVR:
WinAVR benötigt 200 Byte mehr SRam umd 5kB mehr Flash (gleiche Compiler Einstellung -0s) trotzdem in beiden Fällen starten die Fahrmotoren zu früh, und die Fahrtrichtung stimmt nicht mit der Anzeige (zb rückwärts) überein.

Dann das Programm auf das Minumum reduziert, Positionsberechnung weg, GPS weg, Bluetooth, diverse Fahrprogramme, Menüs, Daten im EEPROM etc. Er soll nur mehr Fahren, bei Hindernissen drehen und natürlich die Drehzahl der Fahrmotoren und Mähwerk regeln Mähwerk hat wie immer PI Regler, Fahrmotoren anstatt des Reglers auf feste Umrechung Vorgabe zu PWM umgestellt.

Anstatt 55kB Flash sind es noch 15kB (viele Texte fürs LCD), Ram nur 107Byte anstatt 4606Byte.
Aber immer noch gleich, bei Messerstart beginnen nach ein paar Sekunden auch die Fahrmotoren zu drehen, und die Drehrichtung wird nicht eingehalten. Display zeigt zurückfahren, Motoren drehen aber vorwärts.
Der Motortreiber ist der vom letztem Jahr, der Enable Eingang hat einen Pulldown damit bei zB Kabelbruch die Motoren sind eben nicht drehen.
Also geht diese Leitung auf high obwohl sie lt Code nicht gesetzt wird. Ebenso die beiden Leitungen für die Relais zum Fahrtrichtungswechsel, die werden beim zurückfahren oft nicht geschalten.

Beim Vollprogramm funktioniert GPS und Bluetooth auch bei laufenden Motoren, kann mir die Bluetooth Daten zum PC schicken. Also kann es kein totaler Programmausfall sein wenn diese Punkte funktionieren. Die Messerdrehzahl wird auch perfekt geregelt.
Die Bumper und Schleifensensoren werden im Voll und Minimalprogramm erkannt und am Display angezeigt. zB Bumper vorne erkannt, Anzeige am Display, es die Funktion zurückfahren ausgeführt, am Display der Fahrmodus für zurückfahren angezeigt, lt Anzeige ist die PWM Vorgabe an die Fahrmotoren bei korrekten 52%, nur die Motoren drehen fröhlich vorwärts weiter, gehen nie auf stop wie es bei den Richtungswechsel sein sollte...

Keine Ahnung wo ich noch suchen könnte, schön langsam denke ich eher in Richtung Hardware defekt da es nur die Steuerung der Fahrmotoren betrifft