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

[Dirk]

Das sieht ja gut aus. Viel Arbeit!

-es gibt keine odometrie, nur die steppermotoren können vom arduino überwacht werden (wie?)

Die Steppermotoren bewegen pro Schritt der Ansteuerung das Rad um einen bestimmten Winkel, z.B. 1° (je nach Motortyp).
Dann wären also 360 Schritte eine Umdrehung und die Entfernung wäre zu berechnen.

[inka]

hi Dirk,

Das sieht ja gut aus. Viel Arbeit!

stimmt, aber wenn ich etwas habe, dann ist es zeit...

Die Steppermotoren bewegen pro Schritt der Ansteuerung das Rad um einen bestimmten Winkel, z.B. 1° (je nach Motortyp).
Dann wären also 360 Schritte eine Umdrehung und die Entfernung wäre zu berechnen.

so war meine frage eigentlich nicht gemeint, diese berechnungen habe ich bereits angewendet, bzw. die entspreche library verwendet...

Mir ging es um folgenden, konkreten fall: Die ersten vier stepper, die ich eingebaut habe, liefen alle schön gleichmäßig, wahrscheinlich alle aus dem gleichen fertigungslos. Nachdem eines ausgefallen war - keine ahnung warum (vielleicht doch zu billig) habe ich es ersetzt, seitdem zieht der robby beständig nach rechts.
Es müsste also eine überwachung her und zwar nicht auf der outputseite, sondern auf der seite wo die stepps entstehen. Das sehen aber die von der lib her vorgesehen funktionen offensichtlich nicht vor...

das hier wäre die funktion für den fall, dass alles gut läuft, wo man nicht eingreifen muss, wo aber auch das eingreifen relativ schwierig wird:

    for (idx = stepper_VL; idx < stepper_MAX; idx++) //alle Stepper vorwärts
    {
      stepper[idx].setRPM(12);
      stepper[idx].setSPR(4075.7728395);
      stepper[idx].setDirection(CW);
      stepper[idx].rotateDegrees(60); //rotate(1)
    }

das ist die weniger elegante variante, vo aber alle Stepper einzeln angepasst werden können:

    stepper[stepper_VL].setRPM(12);
    stepper[stepper_HL].setRPM(12);
    stepper[stepper_HR].setRPM(12);
    stepper[stepper_VR].setRPM(12);


    stepper[stepper_VL].setSPR(4075.7728395);
    stepper[stepper_HL].setSPR(4075.7728395);
    stepper[stepper_HR].setSPR(4075.7728395);
    stepper[stepper_VR].setSPR(4075.7728395);


    stepper[stepper_VL].setDirection(CW);
    stepper[stepper_VL].rotateDegrees(30);
    stepper[stepper_HL].setDirection(CW);
    stepper[stepper_HL].rotateDegrees(30);
    stepper[stepper_HR].setDirection(CW);
    stepper[stepper_HR].rotateDegrees(30);
    stepper[stepper_VR].setDirection(CW);
    stepper[stepper_VR].rotateDegrees(30);

beide varianten lassen sich aber - so wie sie sind - nicht im laufendem betrieb an eine neu entstandene situation "automatisiert" einstellen. Z.b. wenn der gyro meldet - "achtung, abweichung vom nordkurs, gegensteuern!"...
Ginge das so, dass ich die werte in den klammern durch variable ersetze und die je nach situation ändere?

frohe ostern!

[Rabenauge]

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.

[inka]

danke für den tipp...

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?

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:

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":

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);
    }
  }
}

[Rabenauge]

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.

[BirgerT]

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)

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

[inka]

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?

[inka]

hallo allerseits,

mehrer male bin ich bereits von den omni-move rädern und den standard TT rädern und wieder zurück gewechselt, die omni-move räder sind recht schwer, die normalen räder rutschen durch...

Die idee nun: schneeketten



hier ein video, jetzt muss ich noch testen bei welcher geschwindigkeit des motors die räder mit den ketten wirklich nicht durchdrehen...

[Carposept]

hallo allerseits,

mehrer male bin ich bereits von den omni-move rädern und den standard TT rädern und wieder zurück gewechselt, die omni-move räder sind recht schwer, die normalen räder rutschen durch...

Die idee nun: schneeketten



hier ein video, jetzt muss ich noch testen bei welcher geschwindigkeit des motors die räder mit den ketten wirklich nicht durchdrehen...

Sie haben das Problem gelöst?

[inka]

Sie haben das Problem gelöst?

leider nein, es rutscht immer noch, bei jeder geschwindigkeit, fast wie im richtigen leben. Es braucht halt einen fahrer und schleifende kupplung und das mit arduino?

bin wieder bei den omni-moves und hoffe noch auf eine eingebung...