Algorithmen zur Bahnplanung

Hallo, ich Arbeite derzeit an einem Seminar unter anderem über Bahnplanung und Navigation. Leider kenne ich mich in diesem Thema noch nicht so wirklich gut aus. Daher bräuchte ich Infos zu folgendem:

- Algorithmen zur Navigation und Bahnplanung
-> Welche gibt es?
-> EINFACHE Bücher oder Webseiten dazu?
(hab bisher was über A*, D Algos. gefunden, aber schlecht erklärt)

- Wie funktioniert Bahnplanung anhand von Kartenmodellen

Mir geht es erstmal darum einen Überblick zu bekommen. Ich hoffe hier kennt sich jemand damit aus.
Ach ja, es geht um einen Roboter mit Rädern und keinen auf Beinen oder so, falls das wichtig sein sollte.

Ich kann nur empfehlen, Du gehst in eine Hochschulbibliothek und leihst Dir dort welche, da Du Dir die vorgeschlagenen Bücher für eine Semesterarbeit wahrscheinlich eh nicht kaufen willst oder sie garnicht bekommst.
Dort bekommst Du auch die eine oder andere Doktorarbeit, da gibt es welche im VDE Verlag.
Später könnte ich Dir Namen nennen.
Gruß

Hallo JackBauer, willkommen im Forum.

Im Buch "Fahrbarer Selbstbauroboter" von U.W.Geitner aus dem elektor-Verlag ist ein Kapitel "Kleine Bewegungsgeometrie".
Mir hatt es sehr gut geholfen zu verstehen, wie ich von Punkt A nach B kommen unter Berücksichtigung meiner Richtung an Punkt A und dem Richtungswunsch für Punkt B.
Leider ist das Buch schon eine 'alte Schwarte' von 1990.
Trotzdem hier noch die ISBN: 3-921608-82-1

JackBauer,

hier ist eine Veröffentlichung, die mit Deinem Thema in Beziehung steht. Zumindest die Zitateliste sollte Dir weiterhelfen. Es gab auch eine interessante Arbeit in "Proc. of Underwater Technologies 2000,. 23-26 May 2000, Tokyo, Japan. " (Autor: Uwe R. Zimmer; Titel: "Embedding local metrical map patches in a globally consistent topological map"), die ich hier aber nicht anfügen kann, weil sie zu gross ist (875kB).

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

@mare_crisium
oh man oh man, dein geposteter Text hat es aber schon faustdick hinter den Ohren. Zumindest ich habe da doch erhebliche Schierigkeiten noch zu folgen. Mal sehen wie weit ich komme. ;-)

@Sternthaler,

tut mir leid, was Einfacheres habe ich nicht gefunden. Ich erinnere mich noch finster an eine andere Methode, die, wenn ich mich nicht täusche, bei den beiden Marsrovers angewendet wird. Die ist aber mathematisch nicht wesentlich weniger anspruchsvoll. Wenn ich sie wiederfinde, werde ich sie auch posten. - Dass Du Dich überhaupt an so ein Ungetüm heranwagst, finde ich schon sehr tapfer!

mare_crisium

@Sternthaler und JackBauer,

hier habe ich die Beschreibung des A*-Algorithmus angehängt, die mir am besten verständlich erscheint. Die Web-Adresse der Quelle steht ganz oben. Dieses Verfahren ist anschaulicher und braucht keine grossen Vorkenntnisse in Mathematik.

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Hallo mare_crisium.
Na das ist doch auch für einen Mathe?-Hab-mal-davon-gehört-User lesbares Zeug. Wenn also der Handesvertreter seinen Weg mit A* plant, kommt er bestimmt leichter am Ziel an, als mit dem ersten Artikel von dir.

Eigendlich hatte ich bei der Frage von JackBauer eher an die geometrischen Grundlagen zum Einstellen von Radlenkung und/oder Geschwindigkeiten bei 2-rädriger Fortbewegung á la Asuro gedacht.
In den von dir geposteten Artikeln (ja, auch im ersten, so weit ich den überhaupt verstanden habe.) ist nichts dazu beschrieben, wie ich z.B. einen vorgegeben Kreis in Teilen abfahren kann, wenn ich die Geometrie meines Fahrzeugs kenne und diese Daten nutzen muss.

Jetzt auch mal ein Anhang von mir.
Im Excel-Blatt berechne ich anhand geometrischer Daten die zu fahrenden "Tik's" vom Asuro. Ein Tik ist ein messbarer Farbwechsel an der Odometrie, und gibt somit die gefahrene Wegstrecke an. (mal besser, mal schlechter) Die gesamte Berechnung beruht mehr oder weniger nur auf Pythagoras und PI, auch wenn die Formeln darin etwas 'verstrubbelt' sind. Ist vor allem auf eine INT-Berechnung getrimmt. Deshalb die oben rechts stehenden 'Zeilen' um 2 Faktoren zu ermitteln, die aus der Rad-Geometrie abgeleitet werden.

In Kombination mit dem A*-Dingsda, sollte nun alles beisammensein um Wege zu planen und auch auszuführen.

Buona notte Sternthaler,

danke für die Tabelle - jetzt verstehe ich besser, worauf JackBauer aus war. Trotzdem würde ich's gern nochmal mit Mathe versuchen. Ich hatte mir vor einiger Zeit 'mal die Formeln für die Koppelnavigation eines Roboters von der Art eines Asuro zusammengestellt. In der angehängten pdf-Datei habe ich die ganze Herleitungsorgie weggelassen und nur das Endergebnis aufgeschrieben. - Ich weiss, meine didaktischen Fähigkeiten sind stark unterentwickelt, aber es würde mich interessieren, ob Du das lesen und verstehen kannst!

Der Witz an der Geschichte ist, dass man mit diesem Algorithmus das Fahren in vorbestimmten Richtungen und das Ansteuern von Zielorten mit einfachen Regelkreisen (ein Fahrgeschwindigkeits- und ein Richtungsregler) verwirklichen kann. Und das ist wesentlich eleganter, als die gesamte Bahnkurve mit Hunderten von Zwischenorten festzunageln. Dabei bleibt nämlich meist unbeantwortet, was der arme Roboter machen soll, wenn er einen der Zwischenpunkte verfehlt! Mit einem geschickt gewählten Regelkonzept erledigt sich diese Frage ganz von alleine.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Hallo mare_crisium, (noch eine Nachteule ;-) )
noch in der Firma, deshalb nur kurz mein 'Überflug'.
Im ganzen (auch für mich) recht gut verständliche.
Hier aber trotzdem ein paar Anmerkungen/Fragen:

- Bei Formel (1) wird angenommen, dass Nr und Nl bzw. Rr und Rl gleich sind? (gehe ich von aus, suche nur Bestätigung)

- Mir helfen bei Formeln allgemein die Einheiten. (1) also m/s und dann bei (2) bestimmt 1/s. (Nicht lebenswichtig, aber für Dummy's wie mich hilfreich)

- In Formel (7) verstehe ich absolut nicht, warum die px- und py-Anteile zur Berechnung von px' und py' gekreuzt werden und mal mit minus bzw. plus berechnet werden. (Grübel heute Nacht)
--- Ich sehe gerade, dass es doppelte Formelnummern gibt. Ich meine hier Formel (7) für die neue Fahrtrichtung ep'

- Bei der Berechnung der Abweichungen zur Ziel-Bestimmung ist mir klar wie es mit der Fahrt-Richtungs-Abweichung vor sich geht.
Bei der Ziel-Positions-Abweichung kann ich nicht folgen:
-- Start-Pos und Ziel-Pos berechnen eine Abweichung zum Startzeitpunkt. OK
-- Aktuelle Position wird laufend berechnet. OK
-- Ziel-Positions-Abweichung nun in Bezug zum ursprünglichen Start-Punkt? (Komme ich mit den Indices durcheinander?)

-- Und noch bei Formel (11): Als Fazit bedeutet dies doch, dass der Roboter dann je nach Entfernung zum Ziel die Geschwindigkeit anpasst? Somit müsste das letzte Stück Weg im 'Schneckentempo' zurückgelegt werden? Sollte hier eine Reglung mit Schwellwert sinnvoll sein?

Sonst ist das Ganze sehr lesbar. Kopie schon angefertigt ;-)

Gruß Sternthaler

[Edit 23:30]Was ich noch vermisse, sind Angaben über die X-, Y-Koordinaten bzw. die Einheiten von Start- und gewünschter Ziel-Position. Ist die ganze Mathematik da Einheitentolerant? Mein Startpunkt liegt bei 0/0, mein Ziel bei X/Y. Aber wie weit ist das weg? Meter / Dezimeter /Kilometer?
Wenn ich die Geschwindigkeit in m/s berechne, müsste dann wahrscheinlich meine Zielkoordinate auch in Metern als Abstand/X/Y angegeben werden. Richtig?

@Sternthaler,

freut mich sehr, dass Dir meine Rechnerei verständlich ist! Deine Fragen bestätigen das. Hier sind die Antworten:

Formel (1): Nee, Rr und Rl müssen nicht gleich gross sein. Das ist einer der Vorteile dieses Algorithmus, das man damit auch Asuros lenken kann, die unterschiedlich grosse Räder und unterschiedlich starke Motoren haben. Man kann den Algorithmus praktisch an jeden Dreirad-Roboter anpassen.

Einheiten: Können ganz nach Belieben gewählt werden, müssen dann aber durchgängig eingehalten werden. Wegen der üblichen Dimensionen heutiger Wohnzimmer oder Küchentische würde ich für die Längen Zentimeter und für die Zeiten Sekunden verwenden. Aber wie gesagt, Meter und Minuten geht auch.

Formel 7: Vektoren in der x-y-Ebene kann man um 90° drehen, indem man x- und y-Komponente vertauscht und dann das Vorzeichen der neuen x-Komponente umkehrt. Diesen Trick verwende ich hier, um aus der Längs- (sprich: der Fahrtrichtung ep) die Querrichtung eq auszurechnen. Die Drehung der Fahrtrichtung durch die unterschiedlich schnell laufenden Räder stelle ich dar, indem ich zum Einheitsvektor in Längsrichtung ein bisschen vom Einheitsvekor in Querrichtung dazuzähle. Das dreht den Längsvektor, macht ihn aber auch ein bisschen zu lang. Deshalb muss er anschliessend wieder neu normiert werden.

Doppelte Formelnummern: Ächz! Es war schon spät. Hab sie in Version V02 korrigiert.

Zielpositions-Abweichung: Ja, in der Formel (jetzt Nr. 12) wird der Zielort immer mit denselben Koordinaten xs und ys eingesetzt. Was sich verändert , sind die Koordinaten xi und yi des Roboters und seine Fahrtrichtung, ausgedrückt durch px und py. Formel (12) verwendet das Kreuzprodukt zwischen der Fahrtrichtung und dem Differenzvektor vom Ort des Roboters zum Zielort.

Schneckentempo: Ja, Du hast recht. Es ist so wie mit Achilles und der Schildkröte: Je näher der Roboter dem Ziel kommt, desto langsamer wird er und er wird wegen der Reibung auch vor Erreichen des Zielorts zum Stehen kommen. Man kann diese Restdistanz in Grenzen mit dem P-Parameter des Fahrtgeschwindigkeits-Reglers einstellen. Oder aber man lässt den Regler die Fahrtgeschwindigkeit nur bis zu einem Minimalwert absenken und schaltet dann bei Erreichen des Ziels die Motoren ganz ab. Hängt ganz davon ab, ob man danach noch weitere Ziele anfahren will oder sonst noch was vor hat.

Ich habe die korrigierte Version 02 wieder angehängt. Darin präzisiere ich auch die Impulszählung (nr und nl) besser: Es dürfen ja immer nur die Impulse in die Berechnung eingehen, die seit der letzten Ablesung dazugekommen sind.

Jetzt ist nur noch die Frage, wie sich sowas mit dem Reglungskonzept eines Asuro verträgt.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Hallo mare_crisium,
oh kopfschüttel,
klar einen senkrechten Vektor kann man ja genau so ausrechnen. (Ist ganz einfach, wenn man einen gut erkläten Tritt in den Hintern bekommt.)

Mit den Einheiten bin ich einverstanden. Auch bei uns läßt sich der Küchentisch noch locker in cm ausdrücken, ohne den "unsigned char"-Bereich zu verlassen.

Mit den Rr und Rl bzw. N(rl) und n(rl) komme ich zu dieser Uhrzeit noch nicht klar. Im Moment sehe ich in (1) nur, dass du (PI * Rr / Nr) ausklammerst aus den beiden Geschwindigkeiten vr und vl. Weiters Grübeln ist da bei mir angesagt.

Zielpositions-Abweichung: Gut gebrüllt Löve. Ähh, gut erklärt. Ist mir nun auch klar geworden. Danke.

Zum Reglungskonzept im Asuro kann ich nur auf den Beitrag von waste hier hinweisen. Den von waste erstellten Code kann man sehr schön als allround-Code nutzen. Das Geheimnis bleibt natürlich in den PID-Parametern für die entsprechende Aufgabe.

Hier ist mal meine aktuelle Version vom Regelcode:

Code:

---

/*****************************************************************************
  FUNKTION:  MotorPID
  Aufgabe:    Funktion zur Reglung der Motoren.
              Diese Funktion bzw. die eigendliche Berechnung fuer die
              Reglung wurde im Forum unter www.roboternetz.de von waste
              entwickelt.
              Von Sternthaler ist die Moeglichkeit hinzugefuegt, die
              Reglerberechnung fuer unterschiedliche Regelaufgaben zu
              nutzen.
              Die Parameter steuern, welche Sensoren zur Reglung benutzt
              werden sollen. Zum einen koennen es die Liniensensoren sein
              um eine Linienverfolgung zu realisieren, zum anderen kann
              der Regler zur Ueberwachung der Raddecoder genutzt werden.
  Parameter: 
*****************************************************************************/
        unsigned char  MotorPID (
        unsigned char  regler,
                  char  speed,
                  int  links,
                  int  rechts)
{
                  int  LWert = 0, RWert = 0;
                  int  absLinks = 0, absRechts = 0;
                  float faktor;
static            int  x, x1, x2, x3, x4;
static            int  xalt, drest, isum;
                  int  kp = 0, kd = 0, ki = 0;
                  int  yp, yd, yi, y, y2;
                  int  LSpeed,        RSpeed;
        unsigned char  LDir,  RDir;
        unsigned char  use_regler = TRUE;

  switch (regler)
  {
  case PID_LINIE:
      links = rechts = 1;                // erzwingt vorwaertsfahrt
      LineData ();                        // Liniensensoren
      LWert = sens.linie [LINKS_DUNKEL] - sens.linie [RECHTS_DUNKEL];
      RWert = sens.linie [LINKS_HELL]  - sens.linie [RECHTS_HELL];
      /* DIESE PARAMETER WURDEN VON waste IM FORUM UNTER
        https://www.roboternetz.de
        ENTWICKELT.
      */
      kp = 5;              // Parameter kd enthält bereits Division durch dt
      ki = 5;
      kd = 70;
      break;
  case PID_ODOMETRIE:
      if (links == 0 || rechts == 0)
        use_regler = FALSE;
      else
      {
        absLinks  = abs (links);
        absRechts = abs (rechts);
        /* Odometrie-Zaehler so justieren, dass fuer eine Kurvenfahrt
            die Tic-Anzahl auf beiden Seiten identisch aussehen.
            Die Seite auf der weniger Tic's zu fahren sind wird auf die
            hoehere Anzahl 'hochgerechnet'.
        */
        if (absLinks < absRechts)
        {
            faktor = (float)absRechts / (float)absLinks;
            LWert = sens.rad_tik [LINKS] * faktor;
            RWert = sens.rad_tik [RECHTS];
        }
        else
        {
            faktor = (float)absLinks / (float)absRechts;
            LWert = sens.rad_tik [LINKS];
            RWert = sens.rad_tik [RECHTS] * faktor;
        }
        /* Diese Parameter wurden von Sternthaler durch probieren ermittelt.
        */
        kp = 65;
        ki = 6;
        kd = 90;
      }
      break;
  }

  LSpeed = (int)(speed - hw.motor_diff / 2);  //Wunschgeschwindigkeit vorgeben
  RSpeed = (int)(speed + hw.motor_diff / 2);  //Hardware beruecksichtigen

  if (use_regler == TRUE)
  {
      /* AB HIER IST DIE BERECHNUNG VON waste IM FORUM UNTER
        https://www.roboternetz.de
        ENTWICKELT WORDEN.
      */
      x1 = RWert - LWert;                // Regelabweichung

      x = (x1 + x2 + x3 + x4) / 4;        // Filtert die 4 letzten Werte
      x4 = x3; x3 = x2; x2 = x1;          // Pipe ueber die letzten 4 Werte

      isum += x;                          // I-Anteil berechnen
      if (isum >  16000) isum =  16000;  // Begrenzung: Überlauf vermeiden
      if (isum < -16000) isum = -16000;
      yi = isum / 625 * ki;

      yd = (x - xalt) * kd;              // D-Anteil berechnen und mit nicht
      yd += drest;                        // berücksichtigtem Rest addieren
      if (yd > 255) drest = yd - 255;    // Eventuellen D-Rest merken
      else if (yd < -255) drest = yd + 255;
      else drest = 0;

      yp = x * kp;                        // P-Anteil berechnen

      y = yp + yi + yd;                  // Gesamtkorrektur
      y2 = y / 2;                        // Aufteilung auf beide Motoren
      xalt = x;                          // x merken

      if (y > 0)                          // Abweichung nach rechts
      {
        LSpeed += y2;                    // links beschleunigen
        if (LSpeed > 255)                // wenn Wertebereich ueberschritten
        {
            y2 += (LSpeed - 255);        // dann Rest rechts berücksichtigen
            LSpeed = 255;                // und Begrenzen
        }
        RSpeed -= y2;                    // rechts abbremsen
        if (RSpeed < 0)                  // Auch hier Wertebereich
        {
            RSpeed = 0;                  // beruecksichtigen
        }
      }
      if (y < 0)                          // Abweichung nach links
      {
        RSpeed -= y2;                    // rechts beschleunigen
        if (RSpeed > 255)                // wenn Wertebereich ueberschritten
        {
            y2 -= (RSpeed - 255);        // dann Rest links berücksichtigen
            RSpeed = 255;                // und Begrenzen
        }
        LSpeed += y2;                    // links abbremsen
        if (LSpeed < 0)                  // Auch hier Wertebereich
        {
            LSpeed = 0;                  // beruecksichtigen
        }
      }
  }

  /* Und wieder (fast) waste
  */
  if (links >0) LDir = FWD; else if (links <0) LDir = RWD; else LDir = BREAK;
  if (rechts>0) RDir = FWD; else if (rechts<0) RDir = RWD; else RDir = BREAK;

  if (LSpeed < 20) LDir = BREAK;        // richtig bremsen
  if (RSpeed < 20) RDir = BREAK;
  MotorDir  (    LDir,        RDir);
  MotorSpeed (abs (LSpeed), abs (RSpeed));

  return 0;
}

---

Ist so angepasst, dass sowohl der ehemalige von waste programmierte Zweck zur Linienverfolgung, als auch eine Reglung für ein Geradeausfahren, nun möglich sind. Klar, der Aufrufer muss ein abgestimmtes Timing haben, sonst stimmen die zeitabhängigen PID-Parameter nicht zur Regelungsaufgabe. Da waste im 2ms-Raster rechnete, sollte das Ding halt alle 2ms aufgerufen werden.
Aktuell geht es in dieser Version nicht, dass beide Regler gleichzeitig nutzbar sind, da innerhalb der Funktion die genuzten static-Variablen nur einmal vorhanden sind. Erzeugt man ein Array für die Variablen mit Variable/Parameter regler als Index, sollte das auch erledigt sein.
Ich sehe gerade, dass noch ein bisschen 'Beiwerk' fehlt.
- Variable hw.motor_diff kann mit 0 ersetzt werden.
- Variablen sens.linie[0-3] sind die automatisch im Interrupt ermittelten Messwerte der Liniensensoren für links/Rechts Hell-/Dunkelmessung
- Variablen sens.rad_tik[0-1] sind die, auch im Interrupt, ermittelten Hell-/Dunkelwechsel an den Odometriescheiben.
(Bei Bedarf poste ich den kompletten Code)


Mal sehen, wann wir google mit einem Asuro auf dem Mond überraschen ;-)

Eine Gute Nacht wünscht Sternthaler

Guten Abend (diesmal nicht Nacht!!), Sternthaler,

danke für Deine Anmerkungen zu meinem Algorithmus! Oh, Mann, hätte ich Deine erste Mail gleich richtig gelesen, dann hätte mir der Fehler schon gestern auffallen müssen! Natürlich kann man die Radien nur vor die Klammer ziehen, wenn sie gleich sind. -

Ich habe den Fehler in der angehängten Version 03 verbessert und auch die Erklärung für das Vertauschen der Komponenten eingefügt. Als Goodie habe ich noch eine Erweiterung angefügt, mit der man den Roboter dazu kriegt, einen Zielort anzusteuern und ihn in einer vorbestimmten Richtung zu durchfahren.

- Dein Programm kann ich nicht so gut lesen, weil ich mich bisher immer geweigert habe, C auch nur mit spitzen Fingern anzufassen. Ich mache auf dem AVR alles in Assembler und auf dem PC mit Delphi oder Lazaraus. Aber ich versuch's mal.

Ciao und schönen Abende,

mare_crisium

Edit: Anhang gelöscht, wg. Upload-Quota

Hallo mare_crisium, irgendwie schwächeln wir so mitten in der Arbeitswoche. Auch bei mir wird es immer früher.

Deine Erklärung mit dem Jadhund ist für mich total einleuchtend. So stelle ich mir angewande Mathematik vor \:D/

Bei der Ermittlung der Regelabweichung, bzw. welche benutzt werden soll, in Formel (14) könnte es eventuell ein Problem geben, wenn beide Abweichungen genau den gleichen Betrag haben, aber die Vorzeichen unterschiedlich sind. Dann liefert die Funktion doch eine Abweichung von 0.
Mach dies Sinn, oder ist dieser Zustand nur kurzfristig zu erwarten, da die Maschine ja noch fährt und alles im Fluß ist?

Sonst kann ich nur sagen: Das ist endlich mal etwas handfestes.

Ich glaube, ich muss demnächst ein paar Regler mit Parametern füttern.
Bei mir dauert so was aber immer etwas. ;-)

Noch einen schönen Abend wünscht Sternthaler

P.S.: Heißt das wirklich Lazaraus und nicht Lazarus? Unter Lazarus kenne ich eine IDE für Pascal, glaube ich.

Nur um die Nachteulen-Ehre zu retten: Buona notte, Sternthaler,

es freut mich richtig, dass Du was damit anfangen kannst! - Der Zustand, in dem sich in Formel (14) beide Stellsignale kompensieren, ist nur vorübergehend. Es wäre ein grosser Zufall, wenn bei der nächsten Berechnungsrunde, nachdem sich der Roboter weiterbewegt hat, wieder eine Null herauskommt.

Ja, natürlich hätte es Lazarus heissen müssen und es ist eine IDE für Free Pascal. Ich habe mal in der Schweiz gearbeitet und seither habe ich eine Schwäche für die Sprachen von Herrn Wirth ;-).

Mit dem Einstellen von Reglerparametern habe ich ziemlich viel Erfahrung. Wenn Du so weit bist, meld' Dich nochmal!

Ciao,

mare_crisium

So, erstmal danke für die vielen Antworten. War ein paar Tage weg und hab sie erst jetzt gesehen. Der A* Pathfinding for Beginners Artikel und die Webseite davon sehen vielversprechend aus, der Rest etwas kompliziert. Aber ich werde mir jetzt erstmal alles genauer anschauen.

Nochmal zu meiner Frage. Der Roboter soll:
1. einzelne Punkte im Raum anfahren können
2. den ganzen Raum möglichst vollständig abfahren

So wie ich das bis jetzt sehe ist der A* ist für Punkt 1 gut. Was gibt es für Punkt 2?

@JackBauer,

schön, dass Du noch dabei bist! Einen Vorschlag für Deinen Punkt 2 habe ich noch nicht, weil ich dazu mehr Details über Deine Aufgabenstellung wissen müsste. Meld' Dich mal, wenn Du Dir alles genauer angesehen hast. -

Übrigens: Der A*-Algorithmus allein wird Dir nicht helfen, denn um den zur Navigation anzuwenden zu können, muss Dein Roboter wissen, in welchem Planquadrat er sich gerade aufhält und was seine augenblickliche Fahrtrichtung ist. Das kann er nur, wenn Du in Dein Projekt auch etwas "Kompliziertes", mindestens eine Koppelnavigation, einbaust.

Ciao,

mare_crisium

@Sternthaler,

bin heute morgen aus dem Bett gefallen :-( und hatte dann Zeit genug, mir was zu Deiner Programmstruktur auszudenken :-). Ich hänge das kommentierte Programm als pdf-Datei an.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

@mare_crisium,
ach du Ärmster. Am Wochenende um 6:33 schon am PC hocken? Mir würde man dann eher nachsagen, dass ich durchgemacht hätte. Hatte ich eigendlich auch von dir angenommen ;-)
Jedenfalls hast du die Zeit gut genutzt und dich in C perfekt eingearbeitet um dann so viel Mathe und Vorschläge in das Programm zu bringen, dass mir die Ohren flattern.

Ja, das mit dem Datenrecorder wäre schon genau das Richtige. Nur würde ich diese Möglichkeit keinesfalls auslagern, sondern bewußt in der MotorPID()-Funktion integrieren. Dann kann auch auch nicht vergessen werden diese Datenrecorder-Funktion aufzurufen.
Etwa folgendermaßen:

Code:

---

      unsigned char  MotorPID (
        unsigned char  regler,
                  char  speed,
                  int  links,
                  int  rechts)
{
/* Speicher für den Datenrecorder */
static            int  x  [ANZ_REGLER], xalt [ANZ_REGLER];
static            int  x1 [ANZ_REGLER], x2 [ANZ_REGLER];
static            int  x3 [ANZ_REGLER], x4 [ANZ_REGLER];
static            int  drest [ANZ_REGLER];
static            int  isum [ANZ_REGLER];

/* Die lokalen Arbeitsvariablen */
                  int  x,                xalt;
                  int  x1,                x2;
                  int  x3,                x4;
                  int  drest;
                  int  isum;
  .
  .

  /* Die lokalen Arbeitsvariablen mit den 'Recorderdaten' füttern. */
  x    = x [regler];
  xalt  = xalt [regler];
  x1    = x1 [regler];
  x2    = x2 [regler];
  x3    = x3 [regler];
  x4    = x4 [regler];
  drest = drest [regler];
  isum  = isum [regler];

  switch (regler)
  {
  case PID_LINIE:
      .
      .
      break;
  case PID_xxxx:
      .
      .
      break;
  case PID_yyyy:
      .
      .
      break;
  }
  .
  .

  /* Die lokalen Arbeitsvariablen in den 'Recorderdaten' sichern. */
  x [regler]    = x;
  xalt [regler]  = xalt;
  x1 [regler]    = x1;
  x2 [regler]    = x2;
  x3 [regler]    = x3;
  x4 [regler]    = x4;
  drest [regler] = drest;
  isum [regler]  = isum;
}

---

Das ist aber nur technischer Schnickschnack.

Zu den anderen Anmerkungen kann ich leider nichts sagen. Da ist mir die Mathematik zu weit weg, von meinem Hausgebrauch-Rechnen.
Ein Hinweis evl. zu der Halbierung des berechneten y-Korrekturwertes. Waste teilt hier, so wie ich es Verstanden hatte, ja den Gesamt-Korrekturwert doch nur auf beide Motoren auf. Da mir dies bei der 'Verfolgung der Zusammenhänge' in seinem Thread eigendlich recht einleuchtend vorkam, ist das doch dann die logische Konsequenz daraus. Warum also den Weg zur Ermittlung der Parameter schon so gestalten, dass man hinterher nicht mehr 'nur' durch 2 teilen muss?

Auch hätte ich Probleme beim Auslagern der endgültigen 'Einstellerei' der Motor-Leistung und den Motor-Richtungen. Wobei die Berechnung der linken/rechten Motorwerte wieder über 'Summen', 'Quotienten' und 'sonstig kompliziertem' ausserhalb erfolgen muss.
Das halte ich für kritisch, da ich es eher sehen würde, dass sich eine Funktion (von mir aus auch mit Hilfsfunktionen, die ich aber nie in meinem Hauptprogramm aufrufe) um ihren Kram komplett alleine kümmern soll.
Ich selbst würde die Parameter so halten, dass meine Wünsche da rein gehen. Hier also etwa: 'Mittlere Geschwindigkeit'; 'Absolute Anzahl Tiks links+Absolute Anzahl Tiks rechts'; oder 'Zielkoordinate X+Zielkoordinate Y'. Das Ganze sollte dann die Funktion 'von alleine' auflösen und sich dann die benötigten Messwerte holen, berechnen und irgendwie sinnvolle 'Summen' und 'Quotienten' bilden.

Natürlich kann man deinen Vorschlag ja auch in einer Funktion 'verpacken' und hätte dann meine Vorstellung erhalten. (Wie viel Wege führten nochmal nach Rom?)


Ob die Mittelwertbildung durch eine Anpassung an dem P-Regelwert überflüßig ist kann ich nicht beurteilen. Allerdings würde ich nicht so pauschal sagen, dass nur die Liniensensoren streuen. Auch die Odometriedaten sind nicht so richtig sauber.
Aber wenn ein neuer P-Wert das alles ausbügeln kann, dann nichts wie weg mit dem Mittelwert.

Tja, und bei dem Rest kann ich nur sagen: Der "Alzheimer"-Faktor ist bei mir auf alle Fälle > 1, wenn es um die ehemals im Studium gelernte Mathematik geht. ;-)

Einen schönen Rest-Sonntag wünsche ich noch.
Gruß Sternthaler

Sternthaler,

oh, je! So heftig wollte ich am heiligen Sonntag Morgen Deine Ohren nicht misshandeln ;-)! - Mir kamen die paar Kommentare, die ich Dir ins Programm geschrieben habe, viel einfacher vor, als das Vektor-Jonglieren bei dem Du voher so tapfer mitgehalten hattest.

Es gibt nichts Schlimmeres, als ein gut laufendes Programm zu "verbessern". Deshalb habe ich vollstes Verständnis für Deinen Entschluss, es so zu lassen wie's jetzt ist. Hauptsache ist, die Beschäftigung mit dem Thema macht Spass!

Ciao,

mare_crisium

Volles Programm: JA, MACHT SPASS (bewußtest Uppercase !)

Geistiger Input ist doch dann nur klasse, wenn man nicht sofort alles Versteht, aber man noch das Licht am Ende des Tunnels erahnen kann, bzw. man auch seine Grenzen kennt.
Meine Anmerkungen aber bitte nicht missverstehen. Ist kein "ich will das aber so", sondern nur meine persönliche Denke. Die (manchmal ;-) ) auch was neues, anders als besser akzeptiert.

Ich bin aber immer noch nicht so weit eine Zeile Code zu schreiben. Dieser Eintrag entsteht just gerade noch in der Firma. Und ob ich dann Zuhause noch Bock habe bezweifel ich jetzt schon.

Gruß Sternthaler

> http://href.to/fQ3 <-- Hinführung zum Wegfindungs.Thema aus einem Uni-Vorkurs; Ameisen-Algorithmus & Dijkstra
> http://href.to/ki1 <-- Dijkstra mathematisch
> http://href.to/Yh3 <-- AStar Sehr einfach erklärt

grtz

Hallo plusminus,
gute Lektüre (der letzte Link ist von mare_crisium schon am 13.09.2007 angegeben worden. Ähnliche Version)
Die Vorlesung aus dem ersten Link habe ich mal überflogen und kann dem ganzen sogar folgen. Was ich beim 2-ten Link zu dieser Stunde nicht mehr sagen kann.
Kleine Frage: Wie lange brauchen Ameisen eigendlich von Imstadt nach Oppenheim? ;-)

Jetzt gehe ich aber doch erst mal in's Bett.
Morgen berichte ich dann mal von meinen ersten Codezeilen zur Umsetzungen der mare_crisium-Version zum Zielanfahren. (Werden aber erst einmal mehr Fragen als Antworten.)

Gute Nacht, und/oder guten Morgen.

gedopte Ameisen bitte ;)

Hhhmmm, dann tippe ich darauf, das die Fahräder haben.

Hier nun mal im Telegrammstil meine bisherigen Überlegungen: (beim Asuro, bei einer vorgegeben Odometriehardware)

- Bestimmung der Geschwindigkeit v= m/s

Wird m als Messwert genutzt, und s ist bekannt, dann liegt m beim Asuro bei ca. 0,15 cm pro Einheit.
Da nur ganzzahlige Einheiten bekannt sind, ergeben sich somit von Einheit zu Einheit relativ große Fahrstrecken, die prozentual einen großen Fehler darstellen, wenn in kleinen Zeitintervallen gemessen wird.
Werden die m-Einheiten erst nach einer relativ großen Fahrstrecke ausgewertet, dann ist das Fahrzeig aber auch schon sehr weit 'steuerlos' gefahren.

Deshalb der Ansatz m konstant zu halten und s als Messwert zu nutzen.
Wenn m mit einer Einheit ca. 0,15 cm darstellt, und der schon laufende Timer2-Zähler mit 36 kHz benutzt wird, kann pro Fahreinheit m je nach Geschwindigkeit ein Zählerwert von 100 (ca. 50cm/s) bis 550 (ca 10 cm/s) erwartet werden. Somit ist der Verlust des Nachkommanteils immer kleiner als 1%.
(Der EXCEL-Anhang stellt dies dar.) 2 Berechnungen daraus hier als Bildanhang.


Aber folgendes Problem tritt auf:
Der erkannte Wechsel der SW-Teilung auf der ODO-Scheibe erfolgt auch bei gleichmäßiger Fahrt nicht in gleichen Zeiteinheiten.
Soll heißen, dass der erwartete Wert von beispielsweise 256 bei einer Geschwindigkeit von 20cm/s beim Asuro nicht kontinuirlich zu messen ist.
Dieser Wert schwankt in 2 Zyklen.
1. Die zeitliche Breite von weis und schwarz auf den ODO-Scheiben ist unterschiedlich.
2. Durch wahrscheinlich nicht zentriertes Anbringen der ODO-Scheibe 'eiert' die Zeit pro Umdrehung derselbigen.
Beides hatte waste auch schon mal ermittelt. (Bin relativ sicher, das es waste war)

Hier stellt sich nun die Frage, wie man am besten diese beiden 'Eier'-Werte mitteln könnte, ohne möglichst viel Genauigkeit zu verlieren.
Ich hoffe auf reichliche Integrale und Ableitungen ;-)

SternTahler,

nein, heute wird nicht integriert! :-)

Ich bin mit Deiner Tabelle nicht ganz klar gekommen; deshalb erzähle ich mal, wie ich Dich verstanden habe:

Du versuchst bei der Odometrie eine bessere Messgenauigkeit zu erreichen, indem Du anstelle der Anzahl Sektoren pro Zeiteinheit, die Zeiteinheiten zwischen zwei Sektorenflanken misst. Diese Zeitspanne ist genau definiert, während man bei der anderen Methode nie so recht weiss, an welcher Stelle zwischen zwei Sektoren man sich zum Zeitpunkt der Messung gerade befindet. - Richtig? Mit der Zeitmessung kann man auch sehr gut die aktuelle Umdrehungszahl des Rades abschätzen und im Prinzip daraus zu jedem beliebigen Zeitpunkt den aktuellen Drehwinkel des Rades, d.h. den zurückgelegten Weg, angeben.

Beim Messen der Zeitdifferenzen hast Du eine Streuung festgestellt, die Du auf einen Zentrierfehler zwischen den Mittelpunkten der Sektorenscheibe und des Zahnrades zurückführst. - So, wie die Konstruktion des ASURO auf den den Fotos aussieht, hast Du wahrscheinlich recht.

Die angehängte Tabelle zeigt, wie sich der Zentrierfehler (Zentrum der Sektorenscheibe ist um einen einstellbare Entfernung und einer einstellbaren Richtung vom Zentrum des Zahnrades verschoben) auf den Zeitpunkt der Sektorflanke auswirkt. Alle Zahlen in den grün unterlegten Zellen können verändert werden. Die letzte Spalte zeigt für jeden Sektor die vom Zentrierfehler verursachte Zeitdifferenz.

Im ASURO-Wiki

http://www.asurowiki.de/pmwiki/pmwik...Main/Odometrie

ist auch ein Link auf den Thread im Roboternetz, in dem waste sich zu dem Problem äussert und eine Lösung für das Geradeausfahrt-Problem angibt.

Ehrlich gesagt, der Zentrierfehler sollte nicht so stark durchschlagen. Er mittelt sich ja bei Geradeausfahrt auch über jdede volle Umdrehung wieder aus. Das wird erst anders, wenn der ASURO seine Fahrtrichtung sehr schnell ändert. Ich tippe eher auf die mechanischen Einflüsse, die in dem Thread erwähnt werden (Zahnradspiel, Motoraufhängung usw.).

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Hallo mare_crisium.

Zitat:

---

Zitat von Ja, du

nein, heute wird nicht integriert! :-)

---

Uff, noch mal Glück gehabt.

Zitat:

---

Zitat von mare_crisium

... Du versuchst bei der Odometrie eine bessere Messgenauigkeit zu erreichen, ....

---

Hast du ja doch alles verstanden, was ich mit den Tabellen ausdrücken wollte. (Habe ich genau so bei dir erhofft.)

Zitat:

---

Zitat von mare_crisium

... eine Streuung festgestellt ...
hast Du wahrscheinlich recht.

---

Ist mir durch den Beitrag von waste erst bewust geworden. (Den Beitrag werde ich bestimmt noch mal wiederfinden. Es war definitiv nicht der aus dem von dir angegeben Wiki-Beitrag.)
Scheint aber tatsächlich so zu sein, da ich seine Messungen auch nachvollziehen kann.
Genau hier setzte ja nun meine Frage nach Intergralen und Ableitungen an.
Wenn ich es mir so überlege, müsste aber dieser ganze Fehlerkram über eine Anpassung beim I-Wert für einem Regler der Geschwindigkeit ausgebügelt werden können. (Ich glaube, dass I für 'ungleichmäßige' Veränderungen zuständig ist. Namentlich 'integriert', müsste es doch Flächen unter Kurven 'zusammenmitteln' und somit 'flatternde' Änderungen irgendwie glätten.)

Bei deiner Tabelle kann ich bis auf Eingaben <> 0 in E4 "Winkel <x-Achse|Mitte_Odo_Scheibe>" gut folgen. (Auch Spalte E macht mir Kummer, wenn bei negativem Bogenmaß noch 180 Grad addiert werden.)
Aber, ja, genau die in Spalte H ermittelte Zeitdifferenz ist das Problem, welche durch einen Regler 'gefiltert' werden muss.
Gerade die Zeitdifferenzen in der von dir ausgerechneten Spalte H sind meine 'Bauchschmerzen'. (Nix Mathe; Bauch ist bei mir der Maßstab. Pizza mit vielen Pilzen [fest und flüßig] kann ich immer vertragen. ;-) )

Zitat:

---

Zitat von mare_crisium

Im ASURO-Wiki ...

---

Schade, das in dem von dir angegeben Wiki-Beitrag 2 Links auf die gleiche Seite zeigen. Hat aber nichts mit meiner Haarspalterei zu tun.

Zitat:

---

Zitat von mare_crisium

Ehrlich gesagt, der Zentrierfehler sollte nicht so stark durchschlagen.

---

Ja, ja, ja, das genau wollte ich hören.

Ich werde also die weiteren Programmstückchen erst einmal mit diesen 'Bauchschmerzen' fortführen und weiter berichten/fragen.

Noch eine ruhige Nacht wünscht
Sternthaler

Sternthaler,

so, jetzt kann ich die korrigierte Tabelle schicken. Mit der Eingabe "Winkel <x-Achse|Mitte_Odo_Scheibe>" wollte ich berücksichtigen, in welche Richtung die Sektorscheibe, relativ zur x-Achse, verschoben ist. Das habe ich jetzt einfach weggelassen, weil dieser Winkel das "Eiern" nur in der Phase verschiebt; die Grösse der maximalen Wegdifferenz bleibt davon unbeeinflusst. Die Addiererei mit 2*pi() usw. kommt von der Mehrdeutigkeit des arctan und sollte Dich nicht weiter beschäftigen. Oben habe ich jetzt die Summe der Wegdifferenzen über eine volle Radumdrehung eingestellt: Sie ist immer Null, wie Du schon vermutetest.

Das bedeutet: Bei Geradeausfahrt kann der ASURO wohl ein bisschen schlängeln, aber es geht nix schief. Aber wenn's um die Kurve geht und ein Rad schneller dreht als das andere, dann mitteln sich die Fehler nicht mehr aus. Am Ende der Kurve bleibt ein Restfehler, dessen Betrag ungefähr zur Differenz der Umdrehungsgeschwindigkeiten, also zum Kurvenradius, proportional ist.

Wenn Du das ausgleichen willst, musst Du nicht am Regler basteln, sondern an der Wegmessung (Odometrie): Der Fehler ist abhängig davon, welche Stellung die Räder beim Einleiten und am Ende der Kurvenfahrt hatten. Du müsstest also nicht nur die Umdrehungsgeschwindigkeit erfassen, sondern den echten Drehwinkel jeweils für jedes Rad. Das lässt sich bewerkstelligen, indem Du den ASURO immer mitzählen lässt, welche Nummer der Sektor hat, den seine Lichtschanken gerade erfassen. Dann müsstest Du ihm für jedes Rad eine Tabelle mitgeben, die für jeden Sektor die zurückgelegte Wegdifferenz angibt. Der ASURO muss dann bei einem Sektorwechsel anhand der Nummer des aktuellen und des vorhergehenden Sektors in der Tabelle nachgucken, welche Wegstrecke diesem Wechsel entspricht und die dann zum bereits zurückgelegten Weg dazuzählen. Im Grunde ist das einfach eine kalibrierte Wegstreckenmessung.

Das zu Programmieren ist eigentlich kein Kunststück. Aber zu diesem Zeitpunkt in Deinem Projekt geht's ja mehr um das Prinzip, als um den letzten Millimeter an Genauigkeit. Deshalb rate ich, diesen Schritt erst am Ende einzubauen, wenn sicher ist, dass alles andere richtig funktioniert.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Hallo mare_crisium,
damit es nicht langweilig wird, hier jetzt auch mal ein paar Messdaten.

Daten in den einzelnen Blättern:
daten-01:
Die Spannungsmesswerte der ODO-Sensoren bei ASURO-Speed 180

daten-02 bis daten-04:
Zeitwerte zwischen 2 Tik-Wechseln bei ASURO-Speed 180

daten-05 bis daten-07:
Zeitwerte zwischen 2 Tik-Wechseln bei ASURO-Speed 255 (Maximum)

Wie man sehen kann, ist die linke Sensorik (immer in blau dargestellt) nicht so gut wie die rechte Seite. Da habe ich schon zu viel an der Messscheibe 'herrumgemacht' für andere Test's.

Bei den daten-02 bis daten-07 habe ich die X-Achse mal in 16er-Schritte geteilt, da dies ja bei mir die Anzahl Tik's pro Umdrehung ist.
Hier kann man nun, vor allem auf der rechten/roten Seite, sehr schön sehen, dass die Scheibe 'eiert'.
Und natürlich sieht man bei dem kontinuierlichen hoch und runter der Messwerte, dass die Zeiten zwischen der weissen und schwarzen 'Messfläche' lustig vor sich hin hüpfen.

Um heute auch noch etwas kurz auf deinen Beitrag einzugehen:
Dieses 'hin und her hüpfen' der Messdaten wollte ich eventuell von dem Regler ausgleichen lassen. Das der Asuro keine Präzisionswege fahren kann, hatte ich schon beim Nikolausfahren festgestellt.
Im übrigen ist dein zuletzt geposteter Anhang sehr aufschlußreich was die zu erwartenden Fehler angeht. Ist ja nicht die Welt, so dass man hier auf alle Fälle weitermachen kann ohne nicht ein bisschen Erfolg (in Zukunft) zu erhaschen.

Zum staunen hier ein, von Manf an anderer Stelle geposteter Link, über fahrende CPU's: http://www.spiegel.de/videoplayer/0,6298,22553,00.html

Nächtliche/Morgendliche Grüße von
Sternthaler

Hei, JackBauer,

hmm, ich trau´s mich fast nicht zu sagen. Vor 25 Jahren habe ich eine Arbeit geschrieben über Bahnberechnung (für den ToolCenterPoint eines Knickarmroboters). Dabei geht es um frei im Raum wählbare Bahnen, die durch Stützpunkte definiert sind. Die theoretische Bahn besteht also aus Geradenstücken - denk mal an ein windschiefes Gerüst (so ähnlich). Daraus wird die physikalisch mögliche Bahn berechnet durch Interpolation. Das ist in den (bei der Interpolation natürlich abgerundeten) Eckpunkten von Wichtigkeit, weil ich nur endliche Beschleunigungen vorgeben kann. Es betrifft also die Bahnplanung für das Gerät. Ich könnt die ersten zehn Seiten mit den Grundlagen posten - wenn das von Interesse ist.

Hallo oberallgeier,
schön, wenn noch weitere Anmerkungen kommen. Da fühlt man sich nicht so alleine bzw. zu zweit ;-)
Ja, das Thema muss schon längst beschrieben, und gelöst, worden sein, denn sonst würde bestimmt kein einziger Industrieroboter die Tür am Türholm festschrauben können.

Du sprichst von 'endlicher Beschleunigung', die in den Eckpunkten von Bedeutung ist. Hat dies damit zu tun, dass z.B. bei der Verzögerung kurz vorm 'Abbiegen' die Kraft nicht ausreicht, um am vorgegeben Punkt zu stoppen. Also ein Überschwingen?
Wenn ich so halbwegs mitgekommen bin, dann würde mich auf alle Fälle deine Arbeit interessieren, da ich aus den Beschreibungen von mare_crisium's Ansatz eher das Gegenteil erwartet hatte. -> Vor dem Ziel stehen bleiben, da die Geschwindigkeit zum Zielpunkt ja mit der Distanz dorthin auch reduziert wird, was irgendwann zum 'stecken bleiben' wegen Reibung und so führen wird. (Wenn man nicht was dagegen macht.)

Gruß Sternthaler

Hei Sternthaler,

hihihi - genau! Das ist ja der Trick beim Ganzen. Mal etwas beispielhaft:
Wenn Du mit dem Auto durch Mannheim fährst (oder sonst ein Dorf mit rechtwinkligem Strassennetz) - bretterst Du dann auch immer mitten in die Kreuzung um dort mit Notbremsung zu bleiben und die neue Richtung zu peilen? Neeeee! Eben. Ein bisschen Vorausschau tut schon gut.

Also wird VOR der Ecke (die ist ja bei diesen Raumbahnen - es sind keine als Funktion darstellbaren Kurven - ein singulärer Punkt) überlegt, wann ich mit welcher Beschleunigung abbremsen muss, um in die von mir geplante neue Richtung zu kommen - - die dann für sich selbst neue Beschleunigungen erfordert. Das geht im Raum ebenso wie auf der ebenen Strasse. Und man will ja eben nicht zum Stillstand kommen - müssen.

Es geht bei dieser Vorplanung weniger darum, dass nicht genug Kraft da ist, als vielmehr die Struktur nur soweit zu beschleunigen und zu belasten, dass Überschwingen, Schwingungen insgesamt, vermieden wird/werden. Daher hatte ich (in einer späteren Realisierung) statt einer Beschleunigungsrampe eine Rampe für die Beschleunigung zweiten Grades genommen (also für die Zunahme der Beschleunigung :) )

Ok, ich will mal meinen Scanner anwärmen - und dann kommt bald was.

PS: meine Bahnberechnung läuft in einigen IR´s - fahr mal nach Rastatt z.B.....

Zitat:

---

Zitat von Sternthaler

... schön, wenn noch weitere Anmerkungen kommen

---

Ok, dann also hier der Auszug. Es ist darin nicht so viel Gewicht auf die dahinterliegende Theorie gelegt, als vielmehr auf die Technik, wie das realisiert wird. Also weniger die Mathematik des Raumes, sondern mehr numerische Mathematik und Lösungssystematik. Aber ein bisschen (viel) theoretischer Hintergrund war schon dabei ...

Die Quellen sind in Fortran. War damals so.

Ich hoffe, dass das ein bisschen weiterhilft.

Bahhhh, der pdf-Text ging nicht mit. Lag´s an den vier MB???

Transpirier, transpirier, ohwehhh, oh OCR.

Aber jetzt hab ich den Text eingescannt, OCR-risiert, korrigiert (und gestöhnt, gestöhnt, gestöhnt).

Hallo oberallgeier,
oh je, jetzt hast du dir aber eine Menge Arbeit gemacht.
Ich habe das Ganze erst einmal gespeichert (leider noch nicht im Kopf) und werde erst später zum lesen kommen. Im Badezimmer fehlen immer noch die Tapeten an den Wänden. :frown:

Einen kurzen Überflug habe ich schon versucht, aber um einen "masseloser tool center point" zu verstehen, muss man sich doch etwas mehr Zeit nehmen.

Bis später, und schon mal vielen Dank für deine Mühe.
Gruß Sternthaler

P.S.: Wieso muss man beim abbiegen bremsen? Ach stimmt ja, auch die Handbremse für rechtwinkliges 'Kurven' bremst ja ;-) .

Hallo Sternthaler,

Zitat:

---

Zitat von Sternthaler

P.S.: Wieso muss man beim abbiegen bremsen? Ach stimmt ja, auch die Handbremse für rechtwinkliges 'Kurven' bremst ja ;-) .

---

Ist doch einfach: Du fährst, sagen wir mal genau, nach Norden und biegst nach genau Osten ab (90 ° Rechtskurve). Dabei bremst Du in Richtung N total ab, und beschleunigst in Richtung O von 0 auf Dein Fahrtempo. Du hast es doch in der Schule gehört (und wie wir alle fast vergessen): Geschwindigkeit ist ein Vektor. Also Grösse UND Richtung ist wichtig. Und beim Abbiegen ändert sich die Richtung. Also wird die vektorielle Projektion (die Geschwindigkeit entlang einer Koordinate) geändert. Aber solche Dinge sind eh blos was für Polemiker wie mich ;-)

PS: Der Textteil sieht ja total nach einem altgriechischen Epos aus - ohne Absatz und so. Ist ja total unleserlich. Ich poste das nochmal als pdf. Sonst kriegt man ja Augenkrebs :(

@ Sternthaler,

Du, die Schwierigkeiten mit dem richtigen Auslesen der Sektoren (mit dem CNY 70) hatte ich auch. Hier

Forum » Elektronik » Noobfrage zu CNY70 Optoreflexkoppler schaltung

habe ich eine Schaltung gebastelt, die mir geholfen hat. Vllt kannst Du ja diesen Teil Deines ASURO noch modifizieren. Übrigens mache ich mir meine Sektorscheiben selber (siehe Anhang). Wie Du schon sagst : Die Eierei kannst Du getrost zunächst mal vergessen.

- Gestern war ich hier im Museum für Kommunikation in der Ausstellung "Die Roboter kommen". War eine ziemlich interessante Sammlung aller möglichen Robotertypen ausgestellt. Auch wimmelte es von wissbegierigen Kindern, die ihren Eltern Löcher in den Bauch fragten. Nur war es peinlich zu hören, welche Antworten sie da bekamen! Sowas von ahnungslos! #-o

@Oberallgeier,

Sternthaler hat recht: Ich dachte schon, er und ich verrennen uns hier in ein Thema, das niemanden sonst interessiert. Dabei kann ich mir nicht vorstellen, wie jemand einen selbstlenkenden Fahrroboter bauen will, ohne den Algorithmus für die Navigation zu kennen. Oder gibt's da was ganz Einfaches, das ich übersehen habe?

Dein Roboterarm hat viele Parallelen zum Fahrroboter. Zentral ist der ähnliche, schichtweise Aufbau des Programms: Ganz oben ist die "Bahnplanung", die festlegt, welche Punkte nacheinander angefahren werden sollen. Sie gibt die Vorgaben an die nächst tiefere Ebene, auf der während der Fahrt überwacht wird, ob der aktuelle Zielpunkt schon erreicht ist und dann auf den nächsten Zielpunkt der Bahn umgeschaltet wird. Bei mir heisst das "Bahnsteuerung". Ganz unten ist die eigentliche "Lenkung". Die "Bahnsteuerung" gibt ihr den aktuellen Zielort vor. Die "Lenkung" vergleicht laufend die aktuelle Position mit den Koordinaten des Zielortes und regelt die Motorgeschwindigkeiten entsprechend. Über diese Ebene haben Sternthaler und ich uns bisher unterhalten.

Das mit dem Abbremsen in den Kurven habe ich mir so vorgestellt: Es braucht eigentlich gar nicht gebremst zu werden. Die Kurvenradien stellen sich frei über den Regler ein, der die Drehgeschwindigkeitsdifferenz der beiden Motoren regelt. Der minimale Kurvenradius wird von der maximalen zugelassenen Drehgeschwindigkeitsdifferenz bestimmt. - Ich habe sehr, sehr ausgiebig mit Reglern in der Industriepraxis arbeiten dürfen; deshalb schwöre ich auf die Dinger ;-).

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

Hei, mare_crisium,

Zitat:

---

Zitat von mare_crisium

Das mit dem Abbremsen in den Kurven habe ich mir so vorgestellt: Es braucht eigentlich gar nicht gebremst zu werden. Die Kurvenradien stellen sich frei über den Regler ein, der die Drehgeschwindigkeitsdifferenz der beiden Motoren regelt.

---

Natürlich hast Du recht, soweit es sich um ein Gefährt handelt.

Bei meiner Arbeit hatte ich als Ziel Routinen für Gelenkroboter. Da kriegt man auch Kurven hin, wenn man den einen oder anderen Motor abbremst oder beschleunigt :-b . Aber das sind dann total chaotische Dinge #-o - weil der Gelenkroboter je nach aktueller Armstellung (Stellung der Teilarme, bzw. eben der Gelenke) eine völlig andere Übersetzung (einen anderen Einfluss) des einzelnen Gelenks auf die Gesamtkonfiguration hat ](*,) .

Also rechnet man dem Gelenkroboter erstmal eine Bahn vor, mit einer sinnvoll vermuteten Beschleunigung um die "Ecken". Dann guckt man, ob nach der Koordinatentransformation - also nach dem Berechnen der Gelenkstellungen, die zur vorgerechneten Teilstrecke gehören - die einzelnen Gelenke keine unsinnig hohe Beschleunigung erfahren. Ist das ok, dann kann die Bahn gefahren werden, sonst geht man mit einer korrigierten Beschleunigungsvorgabe für die Bahn in eine neue Iteration. Und im Hintergrund - damit es wirklich gut funzt, wird das zeitlich präzise interruptgesteuert - lässt man dann eine Regelung laufen, die die vorgerechneten Gelenkkoordinaten von den Motoren einstellen lässt.

Es ist genauso wie Du sagst: eine Arbeit von oben nach unten. Der Käptn gibt das Ziel grob vor, der Navi rechnet den Kurs aus, der Steuermann sieht zu, dass er den vorgegebenen Kurs einhält und Maschinist oder Heizer sehen zu, dass der Kahn überhaupt in Bewegung kommen kann.