IR-bake

[Dirk]

Hi inka,
dem Glückwunsch zum "Etappensieg" schließe ich mich gern an.

ich habe das beispiel "RP6Control_10_Move2.c" in der mainschleife mit dieser funktion ergänzt (spannungsabfrage über die multiIO)

Man kann so was machen, allerdings muss ...
a) die Hauptschleife ohne Verzögerungen (d.h. ohne mSleep) ablaufen und
b) man kann nicht auch noch eine längere Suche nach der Bake dort durchführen (bake_suche).
Grund: Die weiteren Programmfunktionen reagieren dann kaum noch.

Ich muss jetzt noch prüfen nach welcher funktion jetzt die reaktion auf die bumper erfolgt,...

Der "Bumpers Event handler" (bumpersStateChanged) wird angesprungen, wenn sich der Bumper-Zustand ändert.
Wie du schon gesagt hast, passiert die Reaktion auf Bumper-Änderungen in der behaviour_escape Funktion.

Grundsätzlich zeigt die Demo "RP6Control_10_Move2.c", wie man "Verhalten" (behaviour) programmieren kann.
Die Demo:
1. Warte bis ein Geräusch gehört wird (behaviour_waitForStart).
2. Fahre dann herum (behaviour_cruise).
3. Weiche Hindernissen aus (behaviour_escape).
4. Vermeide Hindernisse (behaviour_avoid).
5. Achte auf leere Batterie (behaviour_checkLowBattery)
6. Gehe zu 2.

Die Demo ist eigentlich ideal für dein Vorhaben, das du ja auch in verschiedenes "Verhalten" aufteilen könntest:
1. Mache was (Herumfahren).
2. Achte auf leere Batterie.
3. Falls leer: Suche Bake
4. Fahre auf schwarzer Linie zur Ladestation
5. Lade Akku
6. Gehe zu 1.

Das bedeutet in der Demo:
Du müßtest eigene "Verhalten" (behaviours) nach dem Vorbild in der Demo schreiben. Dazu müßtest du z.B. auch die Rangfolge der Verhaltensweisen (siehe behaviourController) festlegen.

Das ist zwar nicht ganz einfach, aber es ist leider nicht damit getan, deine Funktionen (Akku überwachen, Bake suchen, auf der Linie zur Ladestation fahren ...) in die Hauptschleife dieser Demo zu packen.

[TrainMen]

Du müßtest eigene "Verhalten" (behaviours) nach dem Vorbild in der Demo schreiben. Dazu müßtest du z.B. auch die Rangfolge der Verhaltensweisen (siehe behaviourController) festlegen.

Ja genau so habe ich das gemacht. In der Funktion Akku überprüfen habe ich eine Variable auf Aktiv gesetzt wenn der Akku zur Neige ging. In einer anderen Funktion habe ich dann diese Variable überprüft. Wenn dies dann Aktiv war habe ich nach der hellsten Stelle im Raum (Solar-Projekt) suchen lassen. Am Ende der Funktion habe ich die Variable wieder auf inAktiv gesetzt. So konnte mein BOT auch auf dem Weg zu hellsten Stelle auch wieder die anderen Verhalten beachten. Das müsste doch mit der Bake auch funktionieren ?. Jedenfalls zum auffinden der Bake.

[inka]

hallo,

ich musste die links und rechts IR-sensoren des linienfolgemoduls (einbaubedingt) in der lib tauschen:

RP6Control_MultiIO.h:

// Other ADC channel definitions: 
// (Depending on jumper settings on the MultiIO Project Board!) 
// (The ADC-Mxxx plug is connected to the M32 ADC plug!) 
#define ADC_MULTIIO_LFS_L                ADC_5    // ADC-Mxxx: ADC geändert von 3 in 5, (L=links in fahrtrichtung) 
#define ADC_MULTIIO_LFS_M                ADC_4    // ADC-Mxxx: ADC 
#define ADC_MULTIIO_LFS_R                ADC_3    // ADC-Mxxx: ADC geändert von 5 in 3 (R=rechts in fahrtrichtung)

das hat soweit gut funktioniert, verunsichert bin ich durch diese defines, was ist das?

RP6Control_LFSBumperLib.h:

// Define the use of the LFS Board here! 
#define LFS                                // LFS Board is used 
// --------------------------------------------------------------------------- 
 
#define CH_LFS_L                        1 
#define CH_LFS_M                        2 
#define CH_LFS_R                        3

[Dirk]

... verunsichert bin ich durch diese defines, was ist das?

Das sind die Nummern der ADC-Kanäle (CHannel). Die müssen so bleiben.

[inka]

hallo,

wieder einmal eine anfängerfrage...

folgende funktion funktioniert, beim empfang eines signals der IR-bake wird 000 angezeigt, wenn kein signal 004:

void read_Register_30(void)
{
    I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 0); // Start with register 0...
    I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 31); // and read all 30 registers

    uint8_t i = 0;
    for(i = 0; i < 31; i++)
    {
//        mSleep(8);
        if (i == 30) IR_wert[0] = RP6data[30];
    }
}

diese aber nicht. Da kommt immer nur 000, egal ob IR-bake sendet oder nicht:

void read_Register_30(void)
{
    I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30...
    I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
    IR_wert[0] = RP6data[30];
}

ich verstehe einfach nicht warum, hab doch nur die schleife rausgenommen?

[RolfD]

Nur die Schleife rausgenommen? Ich vermute mal (Glaskugel) das ist ein Stück Code aus dem i2c-Slave der Base.
Du nimmst aber nicht nur die Schleife raus .. du nimmst dem System auch die benötigte Zeit um die Daten aufzuarbeiten.
Die I2C Datenverarbeitung ist zeitkritisch. Wie so vieles andere an den RP6 Libs auch.
Mach doch einfach mal:

void read_Register_30(void) {
I2CTWI_transmitByte(I2C_RP6_BASE_ADR, 30); // Start with register 30...
I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
mSleep(x);
IR_wert[0] = RP6data[30];
}

und probiere mit Werten für x von 0 bis ... keine Ahnung.. 100 .. was die Funktion macht wenn du x bei sendender Bake erhöhst.
Eigentlich sollte sich experimentell ein Wert ermitteln lassen, ab wieviel x die bake gefunden bzw diese 004 übertragen wird.

Es würde mich auch nicht wundern, wenn Du bald die Erkenntnis hast, das sich die Motorsteuerung und die I2C slave lib jeweils als Zeitkritische Module sich im Prinzip gegenseitig in den Füßen stehen - weshalb es nicht ganz ist, das Base Slave Programm softwaremässig noch zu erweitern.
Gruß

[Dirk]

    I2CTWI_readBytes(I2C_RP6_BASE_ADR,RP6data, 1); // and read one register
    IR_wert[0] = RP6data[30];

Bei dem Code wird das über I2C gelesene Byte in "RP6data" gespeichert.
Du must also mit: IR_wert[0] = RP6data; ... auslesen.

Vorsicht mit den Namen von Variablen (Var) und Arrays (Var[n])!