Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Hi,


    ...
    sammel ich Zeichen für Zeichen geht mir am PI manchmal eines durch die Lappen weil der PI nicht
    ...


    warum machst Du das dann nicht über Interrupt?

    Spoiler anzeigen


    ...

    typedef struct serial_param_t {
    unsigned char device[256];
    int dev_fd;
    struct termios oldtio;
    struct termios rawtio;
    unsigned int baud;
    unsigned char databit;
    unsigned char parity;
    unsigned char stoppbits;
    unsigned char handshake;
    } serial_param;

    int inp_present;

    #define COMPORT "/dev/ttyAMA0"
    #define E_PARAM_BAUDRATE -10
    #define E_PARAM_DATABIT -11
    #define E_PARAM_PARITY -12
    #define E_PARAM_STOPPBITS -13
    #define E_PARAM_HANDSHAKE -14
    #define E_PARAM_DEVICE -15
    #define E_PARAM_NULL -16
    #define E_PARAM_NOFD -17

    /* ---------------------------------------------------------------------------------
    | void set_defaults( struct serial_param_t *ctl_param )
    |
    | clear structure and set defaults
    -----------------------------------------------------------------------------------
    */

    void set_defaults( struct serial_param_t *ctl_param )
    {
    if( ctl_param != NULL )
    {
    memset( ctl_param->device, '\0', sizeof(ctl_param->device) );
    strcpy( ctl_param->device, COMPORT );
    ctl_param->baud = 9600;
    ctl_param->databit = 8;
    ctl_param->parity = 'N';
    ctl_param->stoppbits = 1;
    ctl_param->handshake = 'N';
    }

    ...

    /* ---------------------------------------------------------------------------------
    | typedef void (*sighandler_t)(int);
    |
    | Declaration for a signal handler
    -----------------------------------------------------------------------------------
    */

    typedef void (*sighandler_t)(int);

    /* ---------------------------------------------------------------------------------
    | static sighandler_t handle_signal (int sig_nr, sighandler_t signalhandler)
    |
    | setup a new signal handling for a specific signal
    -----------------------------------------------------------------------------------
    */

    static sighandler_t handle_signal (int sig_nr, sighandler_t signalhandler)
    {
    struct sigaction neu_sig, alt_sig;
    neu_sig.sa_handler = signalhandler;
    sigemptyset (&neu_sig.sa_mask);
    neu_sig.sa_flags = SA_RESTART;
    if (sigaction (sig_nr, &neu_sig, &alt_sig) < 0)
    return SIG_ERR;
    return alt_sig.sa_handler;
    }

    /* ---------------------------------------------------------------------------------
    | static void catch_SIGIO(int val)
    |
    | A simple handler that can be installed using handle_signal
    -----------------------------------------------------------------------------------
    */

    static void catch_SIGIO(int val)
    {
    inp_present = 1;
    return;
    }

    ...

    /* ---------------------------------------------------------------------------------
    | int open_device( struct serial_param_t *ctl_param )
    |
    | open serial device
    -----------------------------------------------------------------------------------
    */

    int open_device( struct serial_param_t *ctl_param )
    {
    // open non-blocking

    if( ctl_param != NULL )
    {
    ctl_param->dev_fd = open( ctl_param->device, O_RDWR|O_NOCTTY|O_NONBLOCK);
    return( ctl_param->dev_fd );
    }

    return( E_PARAM_NULL );
    }

    /* ---------------------------------------------------------------------------------
    | void close_device( struct serial_param_t *ctl_param )
    |
    | close the serial device
    -----------------------------------------------------------------------------------
    */

    void close_device( struct serial_param_t *ctl_param )
    {
    if( ctl_param != NULL )
    {
    if( ctl_param->dev_fd > 0 )
    {
    close( ctl_param->dev_fd );
    ctl_param->dev_fd = 0;
    }
    }
    }

    /* ---------------------------------------------------------------------------------
    | int reset_device( struct serial_param_t *ctl_param )
    |
    | reset old parameter of serial port
    -----------------------------------------------------------------------------------
    */

    int reset_device( struct serial_param_t *ctl_param )
    {
    int fail;

    if( ctl_param != NULL )
    {
    fail = tcsetattr( ctl_param->dev_fd, TCSANOW, &ctl_param->oldtio );
    }
    else
    {
    fail = E_PARAM_NULL;
    }

    return(fail);
    }

    /* ---------------------------------------------------------------------------------
    | int setup_device( struct serial_param_t *ctl_param )
    |
    | set parameter for serial communication, save current settings
    -----------------------------------------------------------------------------------
    */

    int setup_device( struct serial_param_t *ctl_param )
    {
    int fail = 0;

    if( ctl_param != NULL )
    {
    if( ctl_param->dev_fd > 0 )
    {
    fail = tcgetattr( ctl_param->dev_fd, &ctl_param->oldtio );
    fail = tcgetattr( ctl_param->dev_fd, &ctl_param->rawtio );
    cfmakeraw( &ctl_param->rawtio );

    switch( ctl_param->baud )
    {
    case 50:
    cfsetspeed ( &ctl_param->rawtio, B50 );
    break;
    ...
    }

    switch( ctl_param->databit )
    {
    ...
    case 8:
    ctl_param->rawtio.c_cflag |= CS8;
    break;
    default:
    fail = E_PARAM_DATABIT;
    }

    switch( ctl_param->parity )
    {
    ...
    case 'n':
    case 'N':
    ctl_param->rawtio.c_cflag |= IGNPAR;
    ctl_param->rawtio.c_cflag &= ~PARENB;
    break;
    default:
    fail = E_PARAM_PARITY;
    }

    switch( ctl_param->stoppbits )
    {
    case 1:
    break;
    case 2:
    ctl_param->rawtio.c_cflag |= CSTOPB;
    break;
    default:
    fail = E_PARAM_STOPPBITS;
    }

    switch( ctl_param->handshake )
    {
    case 'n':
    case 'N':
    ctl_param->rawtio.c_cflag |= CLOCAL;
    break;
    case 'x':
    case 'X':
    ctl_param->rawtio.c_iflag |= IXON;
    break;
    default:
    fail = E_PARAM_HANDSHAKE;
    }
    ...
    if( !fail )
    {
    tcflush( ctl_param->dev_fd, TCIFLUSH);
    fail = tcsetattr( ctl_param->dev_fd, TCSANOW, &ctl_param->rawtio );
    }
    ...

    ...
    if( (failed = open_device( &ctl_param )) > 0 )
    {
    if( (failed = setup_device( &ctl_param )) == 0 )
    {
    loop = 1;
    inp_present = 0;
    handle_signal( SIGIO, catch_SIGIO );
    fcntl(ctl_param.dev_fd, F_SETOWN, getpid());
    fcntl(ctl_param.dev_fd, F_SETFL, FASYNC);

    ...

    salü,
    -ds-

  • Entwicklung: RoPi - Autonomer Roboter mit RaspberryPI? Schau mal ob du hier fündig wirst!


  • warum machst Du das dann nicht über Interrupt?
    salü,
    -ds-

    muss ich probieren

    danke

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • ..grad is die erste Welle an Krimskrams von EXP-Tech für mein RoPi eingetroffen... Voll die Miniatur Teile... auf was hab ich mich da nur eingelassen *Lupe such* :rolleyes:

    1x Sparkfun Motor Driver 1A Dual TB6612FNG (leider keine Stift/Buchsen-Leiste dabei)
    1x CMPS10 - Tilt Compensated Magnetic Compass (Stiftleiste fertig verlötet und an Rückseite bündig mit PCB abschließend)
    1x Dagu Sensor Pan/Tilt Kit mit Servomotoren (ziemlich kleine Servos, bin gespannt ob die auch so leise wie klein sind..)
    1x Pololu einstellbarer Step-Up/Step-Down Spannungsregler S7V8A (2 verschiedene Stiftleisten liegen bei: gewinkelt und gerade)

    Ach bevor ich's vergesse: Beim Kompass (egal welcher) muss darauf geachtet werden das dieser möglichst weit von Motoren oder Stromquellen entfernt platziert werden, da ansonsten das Magnetfeld den Kompass-Sensor stört. Da muss ich also auch noch gucken wo genau ich den später hinbauen werde...

    Bevor ich die Teile aber genauer in Augenschein nehme, kümmer ich mich aber erst noch weiter um die Software für den PI... Das wichtige Teil, nämlich der Ultraschall Sensor (bestellt: 19. Jul 2014 17:08:09 MESZ) um die Software richtig testen zu können, ist leider noch nicht da..


    //EDIT:

    Ich hab grad noch was interessantes entdeckt: https://github.com/nanpy/nanpy

    Spoiler anzeigen

    Install:

  • Hallo alter Bastler ...


    ...
    ... Voll die Miniatur Teile... auf was hab ich mich da nur eingelassen ...
    ...


    tja ne ... is nix mit Vorschlaghammer und Schneidbrenner ;) ...
    Aber evtl. geht's Dir auch so wie mir: irgendwie sehen die Teile beim Dealer immer grösser aus, als sie in Wirklichkeit sind.


    ...
    ... (ziemlich kleine Servos, bin gespannt ob die auch so leise wie klein sind..)
    ...


    naja ... das sind halt so Standard Tower Pro SG90 Dinger.
    Brauchen relativ wenig Strom, haben aber ein verhältnismäßige hohes Drehmoment.
    Da würde mich wieder interessieren, inwieweit bei Dir da auch der jitter-Effekt auftaucht.
    Ich hab' mir aus Plexiglas eine Halterung für diese Standard-Stepper ( diese 28BYJ-48 Teile) gebastelt (ich hoffe, man kann das auf den Bildern im Anhang erkennen).
    Ich bilde mir ein, die laufen ruhiger und stabiler als die Servos. Wenn in Ruhestellung keine grossen Kräfte in Drehrichtung anliegen, geht das auch ganz gut (im Gegensatz zu den Servos ist halt Ruhestellung = Strom aus).
    Apropo Stepper: ich hab' da einen bipolaren mit 4 Phasen für 5V und 500 mA pro Phase (Vierdraht) ... da ist noch ein Tut zur Ansteuerung mit einer L298N Dual H-Brücke in Arbeit.


    ...
    Ich hab grad noch was interessantes entdeckt: https://github.com/nanpy/nanpy
    ...


    wie sagt man bei uns: für den, der wohs mog is des hägsde ...
    Nix für mich ;) ...


    cheers,
    bis denne,
    -ds-

  • Entsteht der jitter-Effekt nicht jenachdem wie man die Servo's anspricht bzw um wieviel grad man die Servo's schrittweise drehen lässt?

    Ich nutze dafür:

    Spoiler anzeigen
  • Moin moin,

    also wenn ich mich da recht erinnere, dann hängt das wohl eher mit Spannungs-Schwankungen oder einer falschen Frequenz zusammen.
    Genau mit einem dieser SG90 Servos hatte ich mich ja -> hier <- schon mal rumgeschlagen.
    Allerdings bin ich mittlerweile sicher, dass der Servo, den ich damals ausprobiert hatte, im Eimer war. Das war ein Test-Servo und den habe ich mittlerweile wohl zu oft über den Anschlag gefahren.
    Jedenfalls hat bei mir dann ein Abblock-Kondensator (allerdings ein Elko ... ich kann Dir nicht sagen warum) mit 470 µF und der Austausch des Servo Abhilfe geschaffen.

    Salü und frohes Schaffen,
    -ds-

  • meint ihr mit Jitter verlorenene Steps ?

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Ich dachte auch schon daran die Servos via PWM anzusprechen allerdings kann ich dann nicht bemessen wie lange er bis zum Anschlag drehen darf, der hat ja leider kein "stop" Schalter. Also hab ich das mit dieser schrittweisen "while(j < ScannerServoMax)" eher umgesetzt da ich dort festlegen kann wieviel Schritte er gehen darf bevor er die Richtung ändern - wobei die Anweisung leider auch noch fehlerhaft ist wie mir erst gestern Abend beim Posten aufgefallen ist.. Er soll ja nicht nur zur Seite sondern auch nach oben/unten und auch wieder zurück ;)

    Jedenfalls hat bei mir dann ein Abblock-Kondensator (allerdings ein Elko ... ich kann Dir nicht sagen warum) mit 470 µF und der Austausch des Servo Abhilfe geschaffen.

    Hm also wärs generell besser wenn ich vor die beiden Servos jeweils einen Elko setzen würde?


    Mit jitter-Effekt ist glaub ich das Zittern gemein oder nicht?

  • Ja genau, dieses zittern ist damit gemeint.
    jar: "verlorene Steps" :s
    Möglich ... der servo macht halt dann Hoppser und fährt, wenn es ganz krass wird, wild und unkontrolliert nach rechts und links ...
    @all: Der Elko kann imho nicht schaden, wobei er beim SG90 nicht unbedingt notwendig ist.
    Normalerweise dient der als "Puffer" wenn der Servo anläuft und dann schlagartig Strom zieht. Da der SG90 kaum Strom verbraucht ( so ein "richtiger" Servo verballert afaik auch schon mal 18A und mehr ) ist ein Abblock-Kondensator m.E. nicht Pflicht.
    Bei mir hat's halt ein bisschen was gebracht ...


    cheers,
    -ds-


  • Mit jitter-Effekt ist glaub ich das Zittern gemein oder nicht?


    Ja genau, dieses zittern ist damit gemeint.
    jar: "verlorene Steps" :s
    Möglich ... der servo macht halt dann Hoppser und fährt, wenn es ganz krass wird, wild und unkontrolliert nach rechts und links ...

    ich glaube da war mal was bei meiner Stepperschaltung wenn der Strom (oder die Spannung) nicht ausreichend war, das Netzteil ging in die Knie und nicht jeder Schritt wurde vollzogen, was sich im "zittern" auswirkte, der will ja immer unter Power stehen der Steppermotor für das Halte- oder Drehmoment !


    wobei ich bei eurer Version ohne Controller L297 unsicher bin ob es nicht doch ein Timing oder SW Problem ist, auch deswegen bin ich ein Fan der Kombi mit L297 !
    Dicke Kondis können direkt an der Stromversogung helfen oder nur dickeres Netzteil !

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (24. Juli 2014 um 11:07)

  • Bah... Die Schrauben vom Pan/Tilt taugen überhaupt nix... Von 2 Blechschrauben ist der Kopf abgerissen, obwohl ich die nicht wirklich fest angezogen hab :( Bei den anderen traut man sich dann gar nicht mehr diese einigermaßen fest zu ziehen. Und wie man das Konstrukt nun vernünftig irgendwo drauf befestigen soll ist auch noch fraglich aber nunja...
    Leider sieht dieser U-Winkel wo der Sensor oder die Kamera drauf befestigt werden soll auch leicht schief aus weil das Teil zu lang ist und man wegen der Befestigung die eine Seite etwas rein biegen muss und dann halt Unterlegscheiben dazwischen setzen damit die Blechschrauben-Köpfe nicht schleifen... Siehe dazu manual
    Also etwas unausgereift der billige Krams d0h

    Diese mini Servos scheinen auch kein guten Kopf zu haben, also nicht so stabil wie es für solch eine doch recht schwere Pan/Tilt Konstruktion aber besser wäre - neigt sich leicht zur Seite das ganze :(
    Leider sind die Kabel die aus dem Servo kommen auch nicht eindeutig: Braun, Rot, Orange.. Auf dem Foto im Shop sind die Kabel aber: Schwarz, Rot, Weiß. Hab jetzt herausgefunden das Braun GND, Rot VCC und Orange die Steuerleitung is (war zwar fast klar aber trotzdem :D)

    Zum Testen muss das aber erstmal reichen - was besseres kann man sich dann immer noch gönn...


    Naja egal. Hab meinen Sketch soweit am laufen das der Ultraschall Sensor wie gewünscht funktioniert, allerdings ohne Interrupt da die NewPing lib irgendwie nicht funktionieren will. Da scheint es Problem mit Timer2 zu geben - anscheint wieder son spezielles Arduino-IDE Problemchen :-/ Naja egal, geht ja auch so ;)


    Die Servos vom Pan/Tilt schließe ich so an dass sich jeweils ein 470µF Elko zwischen Steuersignal und GND befindet.
    Da ich sowohl zur Seite/Schwenken (Pan) als auch nach Oben/Unten/Kippen (Tilt) möchte, muss ich jetzt auch den letzten freien Digital-Pin des Arduino-UNO's belegen.

    Die Digitalen Pins 0 bis 7 sind für den MotorShield, wobei pin7 für eine LED ist um anzuzeigen ob der MotorShield was macht..
    Die Digitalen Pins 8 und 9 sind für den ScannerServo (Pan/Tilt).
    Die Digitalen Pins 10 und 11 sind für den Ultrasonic Schallsensor, plus Digital-Pin 13 (Arduino Onboard LED) für pingLED um anzuzeigen ob Objekt ausser Reichweite.
    Der Digitale Pin 12 ist für eine ErrorLED, die bei allgemeinen Fehlern aufleuchten soll.
    Später brauch ich auch noch 2 Analoge Pins für den CMPS10 Kompass (für I2C, mit jeweils 1.8k Pullup Widerständen zwischen dem jeweiligen Pin und GND)

    Aber noch mal zum Pan/Tilt:
    Hab jetzt ein Sketch geschrieben wo er bei Initialisierung in eine eingestellte Nullstellung fährt. Die Schritte für Bewegungen sind auf 10 eingestellt.
    Dann geht er in 10er Schritten erst nach Rechts, beim erreichen eines eingestellten Maximums (damit man den Servo nicht überdreht und beschädigt, sollte nicht über 179 liegen) geht er nach Links und beim erreichen des eingestellten Minimums (sollte über 0 liegen) macht er eine sog. NewLine dh der Tilt geht um 10 Schritte nach oben und dann beginnt das Spiel wieder von Vorne: Erst nach rechts bis ans Max, dann nach Links bis zum Min. Ist die Line fertig geht der Tilt wieder hoch - dafür kann man ebenfalls ein Maximum einstellten. Ist das Tilt_Maximum erreicht geht er wieder um 10 runter usw und auch für Tilt gibts ein Minimum... :)

    Funktioniert soweit schon mal sehr gut - muss ich nur noch die Ultraschall Pings drauf abstimmen und dann mach ich mich ans Map erstellen :)

    Anbei der Servo Pan&Tilt Sketch:

    Spoiler anzeigen

    //EDIT: mmh irgendwie funktioniert Tilt doch nicht wie gewollt, habs wohl wieder kaputt gespielt =(

    //EDIT2:

    Wie in > diesem Thread < beschrieben habe ich das Problem gelöst :)
    Funktionierender Sketch:

    Spoiler anzeigen
  • Hm ich glaub ich muss mein Konzept noch mal überdenken... Denn wenn ich PathFinding umsetzen möchte aber nur den US-Sensor auf dem Pan/Tilt an bringe, erhalte ich nicht die richtigen Koordinaten vom Kompass - geht der US-Sensor zur Seite zeigt der Kompass aber weiterhin die selbe Peilung an... In dem Fall kann ich also die Daten des US-Sensors nicht verwenden wenn dieser zur Seite schwenkt um den Raum zu erfassen :(

    Ich müsste also auf dem Pan&Tilt eine Platte anbringen auf der ich US-Sensor, Kompass und später auch noch die PiCam anbringen kann.
    Der Kompass scheint aber leider träger zu sein als der US-Sensor, oder die Genauigkeit ist nicht so als dass er bei jedem 10er Schritt des Pan/Tilt's auch einen anderen Wert anzeigt.. Ggf muss ich also die Pan-Schritte ebenfalls erhöhen sodass er nur Vorne(Mitte) und dann gleich ganz nach rechts und Links schwenkt.

    Leider brauch ich für den CMPS10 Kompass auch noch 2 Widerstände (1k8 oder 4k7) für den I2C Bus zwischen SCL (Arduino A4) und 5V sowie SDA (Arduino A5) und 5V, die sollen aber möglichst nah am Arduino angebracht werden..

    Oder ich muss verschiedene Modes einbauen. Einmal der PathFinding bzw Raumvermessung's Modus, in dem ich die Kompass Werte mit den des US-Sensors sowie Odemetrie auswerte. Und einen normalen, Objekt bzw herumfahr Modus in dem ich die Kombination der Sensor Werte nicht weiter verwerte... Das erscheint mir zZt am Sinnvollsten.


    Das nächste Problem besteht auch darin die gesammelten Daten beim PI zu empfangen bzw nicht das empfangen an sich (das mach ich zZt provisorisch hiermit) sondern der Zeitpunkt und die Art der Übermittlung. Derzeit übermittel ich direkt die Daten sobald sie erfasst wurden und erzeuge somit jedesmal eine neue Zeile.
    Nun weiß ich leider noch nicht wie ich in C/C++ die empfangene Zeile zerlege, auf ein Wort prüfe und dann die entsprechende Aktion durchführe (zB eine Map erstellen oder prüfen ob Objekt zu nah usw). ZZt lese ich nur die Daten ein aber wie ich diese Daten nun verarbeite komm ich irgendwie nicht drauf :(


  • Nun weiß ich leider noch nicht wie ich in C/C++ die empfangene Zeile zerlege, auf ein Wort prüfe und dann die entsprechende Aktion durchführe


    die Zeile ist in einem "String" ?

    Der String hat eine Variablen Adresse ?

    z.B. zeile und ist vom Typ (char *)zeile [80] ?

    dann musst du doch nur

    vom ersten zeichen der Zeile solange Buchstaben sammeln bis kein Buchstabe mehr kommt um Worte rauszukriegen.

    nenne mal den Variablen Name und die maximale Länge und die gesuchten Wörter dann baue ich dir das

    läuft in C eigentlich nicht viel anders als Basic oder andere,

    man kopiert solange vom Anfang der Zeile Buchstaben soweit vorhanden in eine Hilfsvariable (oder mehrere) bis ein Trenner SPACE oder anderes KOMMA kommt bis zum Zeilenende \n CR 13 0xD

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (28. Juli 2014 um 09:12)

  • Naja, das kannste ja in der derzeitigen motor_driver.ino's anhand der Serial.print Zeilen erkennen was er ausgibt:

    Spoiler anzeigen

    Wären also zum Beispiel:

    Code
    distance: 162
    distance: -1
    MOTOR: forward 255
    MOTOR: backward 125
    MOTOR: left 100
    [...]

    Was da noch fehlt ist die Ausgabe vom Kompass:

    Spoiler anzeigen


    Als dich da bei war kam mir halt die Überlegung wie ich das empfangsseitig überhaupt verarbeite..

    Ist halt die Frage wie es am sinnvollsten wäre - alles in eine Zeile oder Hauptsache so schnell wie möglich ausgeben

  • Hi meigrafd,


    ...
    Das nächste Problem besteht auch darin die gesammelten Daten beim PI zu empfangen ...
    ...


    ich mache solche Geschichten über Telegramme.
    Also, ich definiere das Datenformat z.B. folgendermassen

    3 Byte ASCII = Länge des Telegramms (000 bis 999)
    ein Byte Delimiter z.B. ':'
    Kommando als string
    Parameter als Strings getrennt durch z.B. ' '.

    Ablauf wäre dann: mindestens drei Byte lesen - Länge = atoi(buffer) - der atoi nimmt alles bis zum Doppelpunkt.
    Restliche Bytes lesen - also z.B. 035 = 35 - 3 - 1 = 31 Byte


    ...
    Nun weiß ich leider noch nicht wie ich in C/C++ die empfangene Zeile zerlege, auf ein Wort prüfe und ...
    ...

    Nun steht ab Position buffer[4] das Kommando.

    Jetzt gibt imho da mehrere Varianten.

    Die superschnelle Variante:

    ...
    cmd=buffer[4];
    do_action(cmd);
    ...

    Die schnelle Variante:
    Jedes Kommando ist genau ein Byte - macht A-Z, a-z, 0-9 ... also eine ganze Menge

    switch(buffer[4])
    {
    case 'A':
    cmd= ABORT;
    do_abort(cmd);
    ...
    case 'B':
    ...

    Die Menschliche Variante:
    Die Kommand sind als String-Konstanten definiert.
    #define CMD_ABORT "ABORT"
    #define CMD_RETRY "RETRY"
    ...

    jetzt halt suchen:
    if( strncmp(&buffer[4], CMD_RETRY, strlen(CMD_RETRY) == 0 )
    {
    do_retry();

    Achtung: die Kommandos dürfen zwar in den ersten Zeichen gleich sein, dann müssen aber die längeren Kommandos zuerst verglichen werden.


    Ja, und dann gibt es eine dritte Variante:
    sscanf(&buffer[4], "%s %s %s", cmd, par1, par2);

    Da musst Du halt definieren, dass immer eine gewissen Anzahl Parameter angegeben werden müssen.

    Da Du die Daten auf der anderen Seite ja in den Buffer schreiben musst, kannst Du diesen Formatstring gleich zum lesen verwenden.

    //EDIT:
    Einen hab' ich noch:
    Ein Array mit Funktionspointern - das Kommando ist der Index innerhalb des Arrays. Da fällt überhaupt jeder Vergleich flach ...

    cheers,
    -ds-


  • ....Ja, und dann gibt es eine dritte Variante:

    und die 4te ;)

    if(strstr(empfangszeile, "KOMMANDO"))
    das_soll_ich_tun();

    if(strstr(empfangszeile, "KOMMANDO2"))
    was_anderes_tun();

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (28. Juli 2014 um 12:41)

  • Vielen Dank für die Vorschläge - werde aber erstmal versuchen ein vernünftiges C Programm hin zu kriegen wo ich auch den Code verstehe und mit einem Socket-Server zu versehen, um dann auch Befehle an den Arduino schicken zu können... Denn es erscheint mir zu viel Aufwand erst etwas zu schreiben was ich letztlich gar nicht brauchen werde... (Ja ich weiß Horror, ich will zu viel :D)


    Heute sind auch 3 weitere Teile eingetrudelt:
    RaspberryPI Camera rev1.3 (ca. 14€ aus China)
    Flex Cable for Raspberry Pi Camera 30cm (ca. 7€)
    2x Fill light White 1W for Raspberry Pi Camera (ca. 6€ aus HongKong)

    Die PiCam ist wirklich Tiny, kleiner als auf anderen Bildern zu sehen. Aber diese Infrared-Light's sind irgendwie komisch... Sieht aber zusammengebaut irgendwie lustig aus, vergleichbar mit 2 Augen, wie es auch beim US-Sensor rüber kommt
    Bei der PiCam ist auch ein Standard Flexkabel dabei, wird für mich aber vermutlich zu kurz sein weswegen ich halt noch ein längeres bestellt hab.
    Angeschlossen hab ichs aber noch nicht, bin ich heute nicht zu gekomm

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!