neues fahrgestell, arduino mega, RP6 M256-WIFi und Ardu_IO

Ich denke schon, dass es geht.
Am besten packst du z.B. trpm in nen eigenes Unterprogramm, und rufst das dann bei Bedarf auf:

void drehZahl(float a,b,c,d)
{
stepper[stepper_VL].setRPM(a);
stepper[stepper_HL].setRPM(b);
stepper[stepper_HR].setRPM(c);
stepper[stepper_VR].setRPM(d);
}

An das Unterprogramm schickst du dann einfach die gewünschten Werte:

drehZahl(12.2, 17.45, 12.92, 14);

Vermutlich musst du das dann jedes Mal vor run() aufrufen, bzw. dann, wenn sich da Änderungen ergeben.
Was deine verlorenen Schritte angeht: kann es sein, dass das Programm einfach zu schnell läuft, so dass die Motoren einfach nicht nachkommen?
Das Problem hat man bei Servos ja auch, wenn man zu oft neue Positionen schickt, erreichen sie manche gar nicht.
Das kannst du mit isDone() offenbar überprüfen.

danke für den tipp...

Zitat:

---

Ich denke schon, dass es geht.
Am besten packst du z.B. trpm in nen eigenes Unterprogramm, und rufst das dann bei Bedarf auf:

void drehZahl(float a,b,c,d)
{
stepper[stepper_VL].setRPM(a);
stepper[stepper_HL].setRPM(b);
stepper[stepper_HR].setRPM(c);
stepper[stepper_VR].setRPM(d);
}

An das Unterprogramm schickst du dann einfach die gewünschten Werte:

drehZahl(12.2, 17.45, 12.92, 14);

---

das werde ich ausgiebig testen :-), eigentlich müsste man die restlichen konfigurationsbefehle für die stepper ähnlich manipulieren können, oder?

Zitat:

---

Was deine verlorenen Schritte angeht: kann es sein, dass das Programm einfach zu schnell läuft, so dass die Motoren einfach nicht nachkommen?

---

glaube ich nicht, dass die stepper nicht nachkommen, vor allem ist es ja nur der neuer, ausgewechselter:
das ist die loop:

Code:

---

void loop()
{
  lcd.setBacklight(LOW);
  hindernis_vorh();
  {
    alle_stepper_vorwaerts();
    bewegung = bewegung + 1;
    fahrt_ausfuehren();
  }
  if (bewegung >= 20)
  {
    lcd.setBacklight(HIGH);
    //previous_millis = current_millis;
    bewegung = 0;
    for (pos_1 = 0; pos_1 < 180; pos_1 += 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
    for (pos_1 = 180; pos_1 >= 1; pos_1 -= 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
    myservo_1.write(90);
    delay(15);
    myservo_2.write(90);
    delay(15);
    lcd.setBacklight(LOW);
  }
}

---

und "fahrt_ausfuehren()" und "fahrt fertig()" verwenden ja schon "isDone":

Code:

---

boolean fahrt_fertig()
{
  return        stepper[stepper_VL].isDone() && stepper[stepper_HL].isDone()
                && stepper[stepper_VR].isDone() && stepper[stepper_HR].isDone();
}


void fahrt_ausfuehren()
{
  while ( ! fahrt_fertig() )
  {
    for (idx = stepper_VL; idx < stepper_MAX; idx++)
    {
      stepper[idx].run();
      // delay(1);
    }
  }
}

---

Zitat:

---

Zitat von inka

das werde ich ausgiebig testen :-), eigentlich müsste man die restlichen konfigurationsbefehle für die stepper ähnlich manipulieren können, oder?

---

Denk ich schon.
Das funktioniert bei den meisten Bibliotheken so oder ähnlich- es wird ja nur ne Art "Voreinstellung" übergeben, wieso sollte man die nicht auch ändern können.

Hi Inka,

ist es sinnvoll die beiden Steper einer Seite unterschiedlich anzusteuern?!
Das was der STEPPER_VL bekommt muss ja auch an STEPPER_HL gehen

Warum nutzt Du für Verzögerungen noch ein delay()? ein delay() wäre in der in der setup() ja noch oK, aber in der loop()!?
Befasse ich Dich doch mal mit den Watches der RP6 Library (bzw. der niborobolib clock.c)

Code:

---

void loop()
{
  uint8_t loop_millis = (uint8_t) (current_millis - previous_millis);
  // das sind UINT32 Variablen, Überlauf erst nach ca. 46 Tagen
  previous_millis = current_millis;
 
  lcd.setBacklight(LOW);
  hindernis_vorh();
  {
    alle_stepper_vorwaerts();
    bewegung = bewegung + 1;
    fahrt_ausfuehren();
  }
  if (bewegung >= 20)
  {
    lcd.setBacklight(HIGH);
    //previous_millis = current_millis;
    bewegung = 0;

#define SERVO_WRITE_DELAY 15
static uint8_t servo_write_timer = 0;

  if (servo_write_timer > loop_millis) {
    servo_write_timer -= loop_millis;
  } // if (servo_write_timer > loop_millis)

  else {
    // Der else Zweig wir alle SERVO_WRITE_DELAY ms ausgeführt,
    // wenn in der loop() keine weiteren delay() vorkommen

    // Timer neu setzen
    servo_write_timer = SERVO_WRITE_DELAY;

    static int8_t dir = 1; // vorwärts = +1, rückwärts = -1, Stopp = 0
// pos_1 = 0; // Initialisierung evtl. in der setup()


  // Alle SERVO_WRITE_DELAY ms Servos aktualisieren
  myservo_1.write(pos_1);
  myservo_2.write(pos_1);

  pos_1 += dir;
  // Wenn 180° erreicht, sollen Servos wieder gegen 0° fahren
  if (pos_1 > 180 ) dir = -1;
  if (pos_1 == 0) {
      // Zielposition erreicht
      dir = 0;
      pos_1 = 90;
      lcd.setBacklight(LOW);
  } //  if (pos_1 == 0)


/*
    for (pos_1 = 0; pos_1 < 180; pos_1 += 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
 
  for (pos_1 = 180; pos_1 >= 1; pos_1 -= 1)
    {
      myservo_1.write(pos_1);
      delay(15);
      myservo_2.write(pos_1);
      delay(15);
    }
    myservo_1.write(90);
    delay(15);
    myservo_2.write(90);
    delay(15);
    lcd.setBacklight(LOW);
  }
*/
} // else if (servo_write_timer > loop_millis)

// und hier könnte noch mehr Code stehen, der quasi parallel ausgeführt würde

} // loop()

---

Also dann, noch viel Spaß und Erfolg

Hi BirgerT,

das mit der unterschiedlichen ansteuerung der stepper hat sich aus der situation ergeben, dass einer plötzlich (nach umbau des fahrgestells) nicht mehr so lief wie vorher und auch nicht so wie die anderen drei...
Zu guter letzt hat sich rausgestellt, dass der elektrische anschluss dieses verd... steppers nicht richtig war. Nun läuft er wieder genauso wie die anderen drei :-) naja, fast genau so, also das thema kontrolle der durchgeführten stepps bleibt evtl. ein problem.

Und nun zu delay() :

das equivalent hierzu ist bei RP6 das sleep() oder msleep()

beide sind "systemblockierend", vielleicht nicht der richtige ausdruck, aber während des wartens steht alles andere auch still. Das mag man als nachteil empfinden und im manch einer situation ist es das evtl. auch...

Hier zeigt sich wieder einmal, dass ich trotz alldem, was ich schon verstehe, immer noch ein anfänger bin. Ich komm ja von der (elektro)mechanischen seite, für mich ist alles, was vom microcontroler kommt unvorstellbar schnell. Ist es ja auch, wenn man es mit einem servo vergleicht, der gemütlich von links nach rechts schwenkt und dabei volle 3 sekunden "verschwendet"...(Bei der überprüfung ob ein hindernis vor dem fahrzeug ist, ist es ja keine volle drehung, sondern nur ein kurzes hin und her und drei pings)

ich finde es halt verständlicher und nachvollziehbarer, wenn der mc darauf wartet, bis der servo mit seinem "dreh" fertig ist und dann wieder loslegt. Der servo dankt es mit dem vollständigen ausführen seiner bewegung und ich merke es nicht, dass der mc 3 sekunden lang stillstand...

Frage:
Ist es jetzt so, dass durch die delays oder sleeps irgendwas schieflaufen kann, oder nutze ich durch ihre nutzung "nur" nicht alle mir zur verfügung stehenden mittel um einen vorgang "quasi parallel" kontrolliert ablaufen zu lassen?

Hallo inka,

grundsätzlich sollte das mit den delays() kein Problem sein, da du alles in Reihenfolge machst. Das hattest Du ja für Dich so entschieden, dass das am Sinvollsten ist.

Nur macht Dein Programm nicht wirklich das, was es machten sollte?!
Ich gehe mal davon aus das Du den Servo einen Schritt weiter setzten möchtest und dann messen möchtest ob etwas vor Dir liegt?

Im Moment misst Du einmal am Anfang und machst einen Fahrschritt. Wenn Du davon genug hast, läßt Du die Servos hin- und herlaufen machst aber keine Messungen. So wie Dein Prog z.Zt. aufgebaut ist, wird nur an der äußersten, rechten Position gemessen und nicht in all den anderen Schritten!
Ausserdem macht es wenig Sinn, die Servos immer nur ein Grad voranschreiten zu lassen. Wenn ich's richtig in Erinnerung habe, dann aben die Sensoren einen Abstrahwinkel von ca. 15°, da könntest Du größere Winkel z.B. 1/4 oder gar 1/3 des Abstrahlwinkels nehmen und so weniger Schritte beim hin- und herschwenken Deines Radars haben. Was dann in der Summe schneller gehen würde.

Grüße

Chris

hallo botty,

ich muss in zukunft wohl mehr drauf achten welchen code ich hier poste, nicht jeder kann ja gedanken lesen :-)...

das ganze mit dem drehen des servos, (z.b. um ein grad) waren nur "interne" tests, wie es überhaupt aussieht...


mein plan ist folgender:

- der roboter fährt eine bestimmte anzahl - momenten 60° - sequenzen, der servo (und der US-sensor) ist nach vorne in fahrtrichtung gestellt, US-messung nach vorne läuft permanent, die messkeule beträgt ca. +- 15°

- der robby bleibt kurz stehen, auch wenn in fahrtrichtung kein hindernis gemessen wurde

- der sensor schwenkt ca. 20° nach links, prüft ob auch weiter links alles frei ist

- der sensor schwenkt ca. 40° nach rechts, prüft ob auch rechts alles frei ist

- robby fährt weiter

so, oder oder so ähnlich...

natürlich ist es eleganter, wenn auch der schwenk (und ping) nach links und rechts während der fahrt passiert, es ist aber in meinen augen kein muss...

hallo in die runde,

nach langer zeit wieder eine kurze meldung - ich bin - nachdem ich mit dem dreirädrigen roboter "fertig" bin (zumindest so weit, dass ich ihn mit meinem enkel zusammen nach und nach weiter entwickeln kann) wieder am fahrgestell dran, es gab kleine fortschritte:

- sainsmart motorshield V2 eingebaut, ist viel einfacher und effektiver, wird über I2C angesteuert, es bleiben viele pins zu freien verfügung...

- so gut wie keine delays im code, vieles kann ich jetzt mit millis() erledigen...:-)

ein paar fotos:

Anhang 32400Anhang 32401

hier zwei kurze videos:
2017 02 03 cruise avoid collision: https://youtu.be/VYyODaNvFTM
2017 02 03 fernbedienung: https://youtu.be/WKTGpe4jd7k

hallo,

die eingebauten getriebemotoren sind alle vier mit ir-encodern versehen. Das habe ich damals gemacht weil ich mir nicht sicher war ob ich sie brauchen werde oder nicht. Den einen habe ich versuchsweise in einem tesprogramm verwendet, der code ist so:

Code:

---

void encoder_1_auslesen(void)
{
  wert_[1] = digitalRead(encoder_1);


  if (vorwaerts_[1] == 1)
  {


    if (wert_[1] == 0 && zaehler_[1] == 0)
    {
      zaehler_[1] = 1;
    }


    else if (wert_[1] == 1 && zaehler_[1] == 1)
    {
      zaehler_[1] = 0;
      summe_[1] = (summe_[1] + wert_[1]);
      Serial.print(wert_[1]);
      Serial.print("    ");
      Serial.println(summe_[1]);
      Serial1.print(wert_[1]);
      Serial1.print("    ");
      Serial1.println(summe_[1]);
    }
  }
  else
  {
    if (wert_[1] == 0 && zaehler_[1] == 0)
    {
      zaehler_[1] = 1;
    }


    else if (wert_[1] == 1 && zaehler_[1] == 1)
    {
      zaehler_[1] = 0;
      summe_[1] = (summe_[1] - wert_[1]); //+
      Serial.print(wert_[1]);
      Serial.print("    ");
      Serial.println(summe_[1]);
      Serial1.print(wert_[1]);
      Serial1.print("    ");
      Serial1.println(summe_[1]);
    }
  }
}

---

es funktioniert soweit, wäre auch möglich das einfach mal auf vier zu erweitern. Würde wahrscheinlich dahingehend probleme bringen, dass die ausgelesenen werte praktisch nie identisch wären. Glaube ich zumindest...

Jetzt die frage: Kann sich hier jemand vorstellen, dass es wirklich situationen geben kann, wo alle vier notwendig sind? Oder würde z. b. ein zweiter "übers eck" also vorne-rechts, wenn der im code hinten-links ist, abzufragen?

würde mich über meinungen sehr freuen...

Hallo Inka,

sehr schönes Projekt !

Leider habe ich keine Antwort auf Deine Frage.

Mich würde aber interessieren, welche Getriebemotoren (mit ir-encodern) du genau verwendest (wenn möglich mit Bezugsquelle).
Auch die Übersetzung wäre interessant. Dein Robbi ist ja auf den Videos recht flott unterwegs.

Viele Grüße,

Gerhard