outdoor I

[inka]

ich habe mir den code jetzt garnicht angeschaut, sondern copy/paste und geladen, ich muss 11x am smartphone drücken, bis die 360° erreicht sind...
und nun ist der akku leer, muss also ca. 2h warten...

edit:

das hier

void loop()
{

  if (Serial1.available())
  {
    taste = Serial1.read();
    Serial.println(taste);
    //    taste_neu = taste;
    tasten_abfrage();
  }

  if ( StepsPerDirection > 0)
  {
    StepsPerDirection--;
    richtung_abfrage();
  }
}

was genau wird damit erreicht? hauptsächlich die zweite if-abfrage...

[Moppi]

Zur ersten if-Abfrage:
Du bist in der Funktion/Methode loop() innerhalb einer Schleife. Deshalb habe ich das ursprüngliche while von Dir entfernt und durch if ersetzt.

Die zweite if-Abfrage sorgt dafür, dass die Stepper so lange in die angeforderte Richtung gedreht werden, wie dies in StepsPerDirection vorgegeben ist. Hier habe ich gedacht, dass eine viertel Umdrehung ein guter Wert wäre. Denn wenn Du die Fernbedienung drückst, "feuert" die ja nicht 200mal pro Sekunde (oder wie lange eine Radumdrehung dauert), sondern weniger. Hier muss man dann passende Werte finden, dass die Handhabung angenehm wird. Wenn für Dich 1 Radumdrehung pro Tastendruck angenehm ist, kannst Du natürlich aus der viertel Umdrehung eine Ganze machen (also: StepsPerDirection = StepsPerRevolution).

Wenn Du 11 Mal Drücken musst, um eine Umdrehung zu erhalten, könnte man versuchsweise schreiben: StepsPerDirection = StepsPerRevolution*11;
Allerdings verstehe ich das mit den 11 Malen nicht, ich sehe darin keine Logik.


MfG

[inka]

Zur ersten if-Abfrage:
Du bist in der Funktion/Methode loop() innerhalb einer Schleife. Deshalb habe ich das ursprüngliche while von Dir entfernt und durch if ersetzt.

ok, die loop wird ja immer wieder durchlaufen, ist es aber nicht so, dass "if" nur einmal abgefragt wird und "while" so lange, bis ein bestimmtes ereignis eintrifft? Damit wollte ich erreichen, dass weitere anweisungen in der loop erst nach diesem ereignis ausgeführt werden...

Du die Fernbedienung drückst, "feuert" die ja nicht 200mal pro Sekunde (oder wie lange eine Radumdrehung dauert), sondern weniger. Hier muss man dann passende Werte finden, dass die Handhabung angenehm wird.

Das eigentliche ziel war (und ist) einmal auf "vor" zu drücken und der roboter fährt so lange vorwärts, bis er einen andern befehl bekommt, oder halt ein anderer sensor meldet sich...

Wenn Du 11 Mal Drücken musst, um eine Umdrehung zu erhalten, könnte man versuchsweise schreiben:

StepsPerDirection = StepsPerRevolution*11; Allerdings verstehe ich das mit den 11 Malen nicht, ich sehe darin keine Logik.

ich auch nicht...

[Moppi]

ist es aber nicht so, dass "if" nur einmal abgefragt wird und "while" so lange, bis ein bestimmtes ereignis eintrifft

Ja, wenn die Abfrage so formuliert ist.
"if" wird auch immer wieder geprüft (weil ja in "loop()"). Wenn dann ein Ereignis eingetreten ist, weil auf "Serial1" etwas "available" ist, wird das Ereignis abgearbeitet.

Damit wollte ich erreichen, dass weitere anweisungen in der loop erst nach diesem ereignis ausgeführt werden...

Passiert hier mit dem "if" genau so. Wenn keine Taste gedrückt wurde und also kein Ereignis vorhanden ist, bewegt sich auch kein Motor, es sei denn, die viertel oder ganze Umdrehung ist noch nicht fertig. Und wenn sich die Motoren in eine Richtung drehen, kannst Du eine andere Taste drücken und die Motoren bewegen sich praktisch sofort in die andere Richtung.

Also eigentlich sollte das Programm dann das tun, was Du beabsichtigt hast. Und wie gesagt, das "while" erübrigt sich, weil Du in "loop()" bist und dieser Code darin immer wieder abgearbeitet wird.

Daher macht

while(Serial1.available()){
...
}

im Grunde dasselbe, wie

loop(){
    if(Serial1.available()){
    ...
    }
}

Beides wird immer wieder abgearbeitet, wenn die Bedingungsprüfung für "Serial1.available()" positiv ausfällt.
Wenn diese Prüfung negativ ausfällt, stoppt "while" nicht den Programmablauf in "loop()", bis ein Ereignis eintritt, sondern nur, solange eines da ist.
Mit "if" passiert dasselbe. Nur dass es den Programmablauf nicht aufhält, solang Ereignisse vorhanden sind, sondern nur so lange, wie ein Ereignis abgearbeitet wird. Wenn beim nächsten Durchlauf in "loop()" festgestellt wird, dass immer noch oder wieder ein Ereignis vorhanden ist, wird das wieder abgearbeitet. Das geht dann so lange, bis kein Ereignis (also Zeichen auf Serial1) mehr vorhanden ist.


MfG

[inka]

Passiert hier mit dem "if" genau so. Wenn keine Taste gedrückt wurde und also kein Ereignis vorhanden ist, bewegt sich auch kein Motor, es sei denn, die viertel oder ganze Umdrehung ist noch nicht fertig. Und wenn sich die Motoren in eine Richtung drehen, kannst Du eine andere Taste drücken und die Motoren bewegen sich praktisch sofort in die andere Richtung.
Also eigentlich sollte das Programm dann das tun, was Du beabsichtigt hast. Und wie gesagt, das "while" erübrigt sich, weil Du in "loop()" bist und dieser Code darin immer wieder abgearbeitet wird.

das ist es ja - eben nicht. ich habe deine version von vorwärtes etwas geändert, von:

void vorwaerts(void)
{
  if(s_vor == 0)
  {
      // enable pins aktivieren:
      digitalWrite(enbl_VL, HIGH);
      digitalWrite(enbl_HL, HIGH);
      digitalWrite(enbl_VR, HIGH);
      digitalWrite(enbl_HR, HIGH);


      //richtung bestimmen
      digitalWrite(dirPin_VL, LOW);
      digitalWrite(dirPin_HL, LOW);
      digitalWrite(dirPin_VR, HIGH);
      digitalWrite(dirPin_HR, HIGH);


      s_vor = 1;
      s_rueck = 0;
      s_links = 0;
      s_rechts = 0;
  }
  else{
      digitalWrite(stepPin_VL, HIGH);
      digitalWrite(stepPin_HL, HIGH);
      digitalWrite(stepPin_VR, HIGH);
      digitalWrite(stepPin_HR, HIGH);
      delayMicroseconds(500);
      digitalWrite(stepPin_VL, LOW);
      digitalWrite(stepPin_HL, LOW);
      digitalWrite(stepPin_VR, LOW);
      digitalWrite(stepPin_HR, LOW);
      delayMicroseconds(500);
  }
}

in:

void vorwaerts(void)
{
  if (s_vor == 0)
  {
    // enable pins aktivieren:
    digitalWrite(enbl_VL, HIGH);
    digitalWrite(enbl_HL, HIGH);
    digitalWrite(enbl_VR, HIGH);
    digitalWrite(enbl_HR, HIGH);

    //richtung bestimmen
    digitalWrite(dirPin_VL, LOW);
    digitalWrite(dirPin_HL, LOW);
    digitalWrite(dirPin_VR, HIGH);
    digitalWrite(dirPin_HR, HIGH);

    s_vor = 1;
    s_rueck = 0;
    s_links = 0;
    s_rechts = 0;

    for (int i = 0; i < stepsPerRevolution; i++)
    {
      digitalWrite(stepPin_VL, HIGH);
      digitalWrite(stepPin_HL, HIGH);
      digitalWrite(stepPin_VR, HIGH);
      digitalWrite(stepPin_HR, HIGH);
      delayMicroseconds(500);
      digitalWrite(stepPin_VL, LOW);
      digitalWrite(stepPin_HL, LOW);
      digitalWrite(stepPin_VR, LOW);
      digitalWrite(stepPin_HR, LOW);
      delayMicroseconds(500);
    }
  }
  else

    for (int i = 0; i < stepsPerRevolution; i++)
    {
      digitalWrite(stepPin_VL, HIGH);
      digitalWrite(stepPin_HL, HIGH);
      digitalWrite(stepPin_VR, HIGH);
      digitalWrite(stepPin_HR, HIGH);
      delayMicroseconds(500);
      digitalWrite(stepPin_VL, LOW);
      digitalWrite(stepPin_HL, LOW);
      digitalWrite(stepPin_VR, LOW);
      digitalWrite(stepPin_HR, LOW);
      delayMicroseconds(500);
    }
}

so macht sie eine umdrehung pro signal vom smartphone, wie meine ursprüngliche auch  
allerdings muss ich am ende der umdrehung für die nächste wieder drücken...

[Moppi]

Du kannst es natürlich machen, wie Du es für richtig hältst. Ich verstehe Deine Intention, das sequentiell abarbeiten zu wollen. Das ist tendenziell für Beginner einfacher. Allerdings wirst Du später eventuell auf eine parallele Abarbeitung hinaus wollen oder müssen. Sequentielle Abarbeitung blockiert immer ein Programm und wird unübersichtlich, wenn man dies zu ändern versucht (indem man immer wieder kreuz und quer Funktionsaufrufe einstreut). Parallele Abarbeitung verfolgt dagegen den Ansatz, mehrere Aufgaben nebeneinander abzuarbeiten, übersichtlich und kontrolliert.

Ich schlage (leider hier nicht zum ersten Mal) vor, einen Programmablaufplan zu erstellen. Gerade, wenn man nicht so den Überblick hat, ist das eine tolle Sache! Den dafür sind die sogenannten PAPs da: optisch einen Überblick über den Programmablauf zu verschaffen. Da erkennt man auch Probleme in der Programmabarbeitung.

Ein Problem will ich noch bildhaft beschreiben, wenn Du die Programmierung in diesen Schleifen (for (int i = 0; i < stepsPerRevolution; i++)...) so aufrecht erhalten willst:

Sollte der Roboter eine dreiviertel Umdrehung am Abgrund stehen und er fährt vorwärts, kannst Du ihn mit keiner Taste stoppen. Weil er erst den Abgrund hinunterstürzt, bevor er auf eine weitere Taste reagiert.



MfG

[inka]

Lieber Moppi,
wir schreiben aneinander vorbei  , es geht nicht um parallel oder seriell, auch das mit der einer Umdrehung pro Smartphonesignal ist doch nur eine Hausnummer, die jederzeit geändert werden kann...
Es geht um die Dauerbewegung nach nur einem Klick am Smartphone, das weiss ich nicht wie ich da hinkomme...
morgen geht's weiter...

[inka]

ich habe jetzt mal eine frage betreffend microstepping und wollte wissen, was ihr so drüber denkt...

Die extenderplatine für den steppertreiber hat ja einen 3poligen schiebeschalter on board, mit dem man - ohne strippen ziehen zu müssen - zwischen den verschiedenen microstep-modi umschalten kann. Allerdings ist sowas eher für den stationären betrieb gedacht, beim fahrenden roboter eher nicht gut machbar.
Die frage:
wäre es sinnvoll die schaltung von der extenderplatine zum arduino zu führen um dann vom smartphone auch "unterwegs" mal umschalten zu können? Alle motoren auf einmal, oder einzeln?