Hi inka,
woran kann das denn wieder liegen?
Ich denke nicht an ein Hardware-Problem.
Leider habe ich das Problem, dass ich deinen Such-Code nicht ganz verstehe, und so auch nicht "mitdenken" kann.

Ich habe mal die Haupt-Suchschleife auf das hier:
Code:
    while(true)
    {
        startStopwatch3();
        t=0;

        do
        {
            if(getStopwatch3() > 50)
            {
                temp = read_IR_value();

                if (temp !=0)
                {
                    // Rotiere RECHTS 5°
                    temp = read_IR_value();
                    if (temp == 0) stop(); //break;
                    if(bumper_left && bumper_right) //stop();//break;
                    {
                        stop();
                    }

                }
                temp = read_IR_value();
                if (temp == 0)
                {
                    x = getStopwatch3();

                    if (t<10)
                    {
                        t++;

                        if (t == 10)
                        {
                            y = getStopwatch3();
                            z = y-x;
                            t=0;
                            setStopwatch3(0);
                            if (z< 600)
                            {
                                Fahre VORWÄRTS 10cm
                                setStopwatch3(0);
                                t=0;
                                mSleep(400);
                                task_checkINT0();
                                task_I2CTWI();
                                if(bumper_left && bumper_right)
                                {
                                    stop();

                                }

                            }

                        }

                    }


                }
            }

            task_checkINT0();
            task_I2CTWI();
        }
        while(!bumper_left && !bumper_right);
... reduziert.
Wenn ich das so sehe, stellen sich ein paar Fragen (quasi als Bemühen, das zu verstehen):

1. In der Hauptschleife wird ja alle 50ms (if(getStopwatch3() > 50) ) "etwas" gemacht. Verfolgt man erstmal das, was passiert, wenn die 50ms NICHT um sind:
Dann laufen nur task_checkINT0(); und task_I2CTWI(); durch und die Schleife soll durchlaufen werden, solange KEIN Bumper gedrückt wird.
Das dürfte aber so nicht funktionieren, weil die Variablen bumper_left u. bumper_right sich in der Schleife nicht verändern (es erfolgt ja keine Veränderung dieser Variablen abhängig von den Bumpern!).

2. Wenn man dann in die alle 50ms angesprungene Verzweigung schaut, wird da IR gelesen (temp = read_IR_value ). Abhängig vom Ergebnis (Bake wahrgenommen oder nicht) soll ja eine Reaktion erfolgen. Es soll gedreht werden, wenn die Bake nicht erkannt wurde und geradeaus gefahren werden, wenn die Bake erkannt wird.
Da ich diesen Teil nicht verstehe, lasse ich das mal außen vor. Aber trotzdem stellen sich Fragen:
a) Wenn ich mich richtig an die IR-Empfänger-Abfrage erinnere, dann ist das Ergebnis von read_IR_value() NULL, wenn die Bake empfangen wurde und GRÖSSER NULL, wenn sie aus ist oder nicht in Sicht. Wenn das so ist, verstehe ich deinen Code -wie gesagt- nicht.
b) Im 50ms-Teil wird der IR-Sensor ZWEIMAL abgefragt und nach dem Rechts-Rotieren sogar noch einmal. Was bedeutet das? Eigentlich sollte das IR-Signal nur EINMAL alle 50ms abgefragt werden, weil eine erneute Abfrage direkt nach der ersten durchaus ein anderes Ergebnis bringen kann und dann deine Logik durcheinander bringt. Vorschlag: IR nur EINMAL am Anfang des 50ms-Teils abfragen und in einer Variablen speichern ODER direkt in die beiden Zweige:
Code:
                if (temp !=0) // Bake AUS
                {
                   // Drehe rechts-links bis Bake wieder da
                 }
                else // Bake AN
                {
                   // Fahre geradeaus
                }
... einmünden lassen.
c) Die 50ms sind vermutlich viel zu kurz. Allein die I2C-Kommunikation dauert (Abfrage IR) fast schon länger,- an die Fahrbefehle gar nicht zu denken.
d) Das nicht blockierende Drehen und Fahren erzeugt kaum einschätzbare Phänomene. Wann ist das Fahren zuende? Meine Einschätzung: Der 50ms-Teil wird mind. schon 50 bis 200x wieder angesprungen, während der letzte Fahrbefehl noch aktiv ist. Folgen: ???
e) Pause 400ms nach dem Vorwärts-Fahrbefehl. Das bedeutet letztlich fast schon ein blockierendes Fahren, weil ja fast 1/2 Sekunde gewartet wird. Das bringt aber die schnelle Hauptschleife durcheinander, so dass die weiteren Abläufe nicht mehr transparent sind.

Vielleicht hilfst du mir beim Verständnis: Dann kann ich wieder mitziehen ...