HDMM01 und die orientierungslib von Dirk

[Dirk]

Hi inka:
Glückwunsch zum funktionierenden Programm! Hoffentlich wird deinem RP6 nicht schwindelig vom vielen Drehen!

zu 1 und 2)
Wenn die etwas größeren "Sprünge" nicht durch tatsächliche "Ausreißer" einerseits des Kompass-Richtungswerts, andererseits durch ungenaues Drehen auf der Stelle, verursacht werden (das würdest du ja in deiner Werte-Ausgabe merken!), dann kann das Phänomen auch daran liegen, dass du ja "nicht-blockierend" drehst, d.h. dass sich Drehbefehle "überlappen", weil bei einem neuen Drehbefehl noch evtl. der alte aktiv ist.

[inka]

hi Dirk,

schwindelig sicher nicht, er dreht ja hin und her , allerdings beim ändern des blocking-parameters dreht er nur einmal und bleibt stehen. Im handbuch:

An diesem Beispiel sieht man, wie die beiden Funktionen benutzt werden können:

#include "RP6RobotBaseLib.h"
int main(void)
{
initRobotBase();
setLEDs(0b111111);
mSleep(1500);
powerON(); // Encoder und Motorstromsensoren anschalten!
}
while(true)
{
setLEDs(0b100100);
move(60, FWD, DIST_MM(300), true); // 30cm Vorwärts fahren
setLEDs(0b100000);
rotate(50, LEFT, 180, true); // um 180° nach links drehen
setLEDs(0b100100);
move(60, FWD, DIST_MM(300), true); // 30cm Vorwärts fahren
setLEDs(0b000100);
rotate(50, RIGHT, 180, true); // um 180° nach rechts drehen
}
return 0;

Hier fährt der Roboter zunächst 30cm Vorwärts, dreht dann um 180° nach links, fährt die 30cm zurück, 
dreht um 180° nach rechts und das Spiel beginnt von neuem.

Würde man den blocking Parameter von allen Funktionen false anstatt true setzen, 
würde das Programm überhaupt nicht funktionieren, da aus der Main Funktion nicht die task_motionControl Funktion 
aufgerufen wird und alle Funktionsaufrufe direkt hintereinander stehen.

Ändert man auch nur einen der blocking Parameter in false um, wird das Programm ebenfalls nicht mehr
 wie gewünscht funktionieren – es wird dann eine der Bewegungsphasen komplett übersprungen.

Für solche rein sequentiellen Abläufe muss man den blocking Parameter also immer auf true setzen!

das würde den abbruch der drehungen nach der ersten drehung erklären, es wird auch wieder die "task_motionControl Funktion" erwähnt. Wird die automatisch in dem base-slave-programm aufgerufen?

[Dirk]

Hi inka,
nein, die "task_motionControl Funktion" brauchst du nicht, wenn du mit der M32 als I2C-Master die Base ansteuerst.
Der Grund, warum das rotate blockierend nur 1x ausgeführt wird, liegt wohl daran, dass dein rotate-Block innerhalb der if(key) Abfrage liegt.
Du müßtest dein Programm so umschreiben, dass die Richtungsmessung, -korrektur und (blockierendes) rotate in der while(true)-Schleife unabhängig vom Tastendruck immer durchlaufen kann bis zu einer Abbruchbedingung (z.B. +- 5° vom Zielwert).
Die Tastaturabfrage würde dann parallel laufen und nur ausgewertet, wenn die "richtige" Taste gedrückt wird.

[inka]

hi Dirk,

ich kann mir vorstellen das programm so umzuschreiben dass die abfrage der 4 tasten (himmelsrichtungen) bestandteil von der while(true) schleife ist, also umgekehrt zu derm wie es jetzt ist. Ist es das was du meinst?

Den letzten satz mit der paralellel-lauf und abfrage der tasten - wie meinst du das mit dem parallelem lauf?

[Dirk]

Hi inka,
vergiß es einfach. Ich hatte nicht gesehen, dass du innerhalb der Haupt-while(true)-Schleife noch eine 2. while(true)-Schleife hast, in der dann die Drehung stattfindet. So kann man es natürlich auch gut machen.

[inka]

hi Dirk,

aber woran könnte dann die letzte drehung nach dem break bei "0" liegen?

[Dirk]

Keine Ahnung.
Wenn du rotate nicht blockierend einsetzt, können alle möglichen Effekte eintreten, weil die Drehungen "im Hintergrund" und zeitlich parallel zu deinem Master-Programm auf der M32 ablaufen.

[inka]

hi,

habe heute meinen RP6 eingeschaltet und folgenden code geladen:

#include "RP6ControlLib.h"
#include "RP6I2CmasterTWI.h"
#include "RP6Control_OrientationLib.h"
#include "RP6Control_I2CMasterLib.h"
#include "RP6Control_MultiIOLib.h"

#define I2C_RP6_BASE_ADR 10

uint8_t ch;
char item[12];
char dir[3];
uint16_t heading;


void I2C_requestedDataReady(uint8_t dataRequestID) //macht was?
{
    checkRP6Status(dataRequestID);
}


void calculateDir(char* dir, uint16_t heading) //setzt headingwerte grob in himmelsrichtungen um
{
    dir[1] = ' ';
    dir[2] = '\0';
    if ((heading <= 22) || (heading >=338)) dir[0] = 'N';
    if ((heading >= 23) && (heading <= 67)) {dir[0] = 'N'; dir[1] = 'E';}
    if ((heading >= 68) && (heading <= 112)) dir[0] = 'E';
    if ((heading >= 113) && (heading <= 157)) {dir[0] = 'S'; dir[1] = 'E';}
    if ((heading >= 158) && (heading <= 202)) dir[0] = 'S';
    if ((heading >= 203) && (heading <= 247)) {dir[0] = 'S'; dir[1] = 'W';}
    if ((heading >= 248) && (heading <= 292)) dir[0] = 'W';
    if ((heading >= 293) && (heading <= 337)) {dir[0] = 'N'; dir[1] = 'W';}
}



void I2C_transmissionError(uint8_t errorState) //gibt I2C fehlermeldungen über LCD aus
{
    clearLCD();
    writeStringLCD_P("I2C ERROR -->");
    setCursorPosLCD(1, 0);        // line 2
    writeStringLCD_P("TWI STATE: 0x");
    writeIntegerLCD(errorState, HEX);
}




int main(void)
{


initRP6Control();
multiio_init();
initLCD();

    setLEDs(0b1111);
    mSleep(500);
    setLEDs(0b0000);

I2CTWI_initMaster(100);
I2CTWI_setRequestedDataReadyHandler(I2C_requestedDataReady);//macht was?
I2CTWI_setTransmissionErrorHandler(I2C_transmissionError); //aktiviert I2C fehlermeldungen

    showScreenLCD(" RP6Control M32", " gyro_test_2");
    mSleep(2500);
    clearLCD();


orientation_init();
COMPASS_2D_init();
    while(true)



    {
    task_I2CTWI();
    intreg2dm = readHDMM01();            // holt sersorwerte
    if(!intreg2dm)
        {                                    // daten gültig?
        normalizeHDMM01();                // daten werden "normalisiert"
        heading2dm = headingHDMM01();    // berechnung der headingwerte
        setCursorPosLCD(0, 0);
        writeStringLCD_P("Heading   ");
        writeIntegerLCD(heading2dm, DEC);
        setCursorPosLCD(1, 0);
        writeStringLCD_P("direction  ");
        calculateDir(dir, heading2dm); //berechnung der richtung (N,S,W,E)
        writeStringLCD(dir); //ausgabe des richtungswertes
        mSleep(100);
        clearLCD();

        }

/*
    move(150, FWD, DIST_MM(500), true); //fährt 50cm

    mSleep(300);

    rotate(50, 3, 90, 1); //wendet um 90°
    clearLCD();
*/

    }


    return 0;
}

das entpricht bis auf die auskomentierte stelle dem selbstest_05...

auf dem display erscheint Heading 269 und in der zweiten zeile direction W, egal wie ich den roboter harumdrehe...

woran kann das liegen? ist der kompass defekt?


Edit:

ich habe jetzt noch den selbsttest 05 aus dem letzten softwarepaket genommen,

auf dem LCD display erscheint Heading 269 (verändert sich bei drehung des RP6 nicht), in der zweiten zeile die werte X und Y, die verändern sich allerdings...

[Dirk]

Fragen:
1. Zeigen die Demos auch dann EINMALIG 269° an, wenn dein RP6 vor dem Programmstart in eine andere Richtung gedreht wurde?
2. Was passiert, wenn du die globale Definition von "uint16_t heading;" rausnimmst (die doppelt sich mit heading in der Funktion calculateDir)?

[inka]

Fragen:
1. Zeigen die Demos auch dann EINMALIG 269° an, wenn dein RP6 vor dem Programmstart in eine andere Richtung gedreht wurde?

sie zeigen wenn ich den RP6 vor dem programmstart um ca 90° drehe "270", der wert ändert sich beim zurückdrehen (bei laufendem programm) wieder in 269.

2. Was passiert, wenn du die globale Definition von "uint16_t heading;" rausnimmst (die doppelt sich mit heading in der Funktion calculateDir)?

es ändert sich nichts...