- fchao-Sinus-Wechselrichter AliExpress         
Seite 11 von 15 ErsteErste ... 910111213 ... LetzteLetzte
Ergebnis 101 bis 110 von 144

Thema: Algorithmen zur Bahnplanung

  1. #101
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    02.11.2005
    Beiträge
    1.614
    Anzeige

    Powerstation Test
    Sersn

    ich muss mal ganz doof fragen ob es doch tatsächlich so super schwer ist einer Linie zu folgen? Hab mir ein paar Sourcecodes durchgelesen und das scheint ja in der Tat doch schwerer zu sein als ich erwartet hatte (und ja ich hab immer noch keinen µC daheim liegen und dümpel in der theorie rum) ^^

  2. #102
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.12.2005
    Beiträge
    535
    BlackDevil,

    doof ist Deine Frage auf gar keinen Fall . Mit Linienfolgern habe ich mich noch nicht beschäftigt und hier kümmern wir uns darum, ein Fahrzeug ganz ohne Linie zu vorbestimmten Wegepunkten fahren zu lassen. Wenn Du das Thema Linienfolger von der mathematischen Seite her aufziehen willst, solltest Du einen separaten Thread in diesem KI-Forum aufmachen. Ich würde mich beteiligen und Du kriegtest bestimmt auch Unterstützung von Leuten, die das Problem schonmal durchdacht und gelöst haben.

    Meiner Meinung nach hängt der Schwierigkeitsgrad stark von der Art der Sensoren ab, mit der man die relative Lage von Fahrzeug-Längsachse und Linie misst: Oft sieht man nur drei Reflektions-Lichtschranken - das ist schwierig. Wenn man einen kompletten Liniensensor verwendet, etwa aus einem Scanner - das macht es viel einfacher. -

    Ciao,

    mare_crisium

  3. #103
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.693
    Zitat Zitat von BlackDevil
    ... fragen ob es ... schwer ist einer Linie zu folgen?
    Also es ist wirklich garnicht einfach. Beispiele: Das Allereinfachste - versuche mal GENAU auf der Mittellinie der Strasse zu fahren (bitte NUR wenn weit und breit kein anderes Fahrzeug da ist und Du noch VIEL Strasse einsehen kannst). Ich hab schon immer Schwierigkeiten in der Autowaschanlage, einigermassen die Mitte zu finden. Oder, nimm Dir nen Flieger (es reicht ein Flugsimulator) und fliege NUR nach dem CDI (Kursablaganzeiger, CDI = Course Deviation Indicator). Das ist eine Nadel, die anzeigt, ob Du links oder rechts vom Leitstrahl bist. Und da braucht man schon sehr viel Gefühl für die Trägheit des Dings, um wieder auf den Strahl zu kommen. Das Gleiche gilt für die Höhe über oder unterm Leitstrahl. Ähnliche Probleme, fast noch gravierender, hat man im U-Boot, wenn man eine bestimmte Höhe (ist ja auch ne Linie) halten will.

    Jetzt haben wir aber einen roboter mit SEHR eingeschränkter Sensorik. Ich glaube das ist Dir dann ganz ohne Mathe klar, dass da ein Problem auftaucht. Als Mensch ist das einfach zu lösen: Du hast komplexe optische Sensoren, taktile (Deine Füsse wissen schon recht gut, ob DU linkslastig oder rechtslastig gehst), Gleichgewichtssinn (schwanke ich ...), eine komplexe "Datenverarbeitung" . . . Ich will das jetzt nicht zu sehr ausbreiten. Du verstehst es sicher.

    Wie sehen jetzt Lösungen aus? Eine besonders pfiffige Lösung kenn ich vom U-Boot. Es ist von der Physik her praktisch eine Art Wurfparabel, die vorhersagt, in welcher Höhe ich in - sagen wir mal - in 20 Sekunden bin. Diese einfache Vorhersage erlaubt eine dramatisch verbesserte Steuerbarkeit. Und solche Vorhersagestrategien sind für die genaue Einhaltung einer Route das Thema des Threads: Algorithmen zur Bahnplanung. Natürlich gehört die Erfassung der Situation dazu:

    Zitat Zitat von mare_crisium
    ... hängt der Schwierigkeitsgrad stark von der Art der Sensoren ab, mit der man die relative Lage von Fahrzeug-Längsachse und Linie misst: ...
    Daher auch einige Diskussionen über Weg- und Geschwindigkeitsmessung hier. Aber diese Fragen sind lösbar - mehr oder weniger gut.
    Ciao sagt der JoeamBerg

  4. #104
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.12.2005
    Beiträge
    535
    @Alle,

    so, jetzt ist die neue Version V06 fertig, allerdings noch ohne die Ergänzungen für die SternThaler-Methode zur Drehwinkelmessung an den Rädern. Dafür berücksichtigt sie die Korrektur von jeffrey und gibt auch eine modifizierte Rechenvorschrift für erhöhte Schätzgenauigkeit an.

    Ciao,

    mare_crisium

    Edit1: Habe den Anhang "Koppelnavigation_Algorithmus_V06.pdf" gelöscht. Die korrigierte Version V07 ist im Post vom 28.11.2007 zu finden.

  5. #105
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    02.11.2005
    Beiträge
    1.614
    Okay vielen dank. Wusste gar nich das das insgesamt so aufwendig wird, also Mathematisch...
    Ich denke ich mach im laufe des Tages mal nen Mathethread auf hehe

  6. #106
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo alle zusammen,
    ja, es wird so langsam Weihnachten.

    Genau aus diesem Grund, und weil der erste Ansatz nun im Asuro steckt, hier mal auf die schnelle das ganze Zeug.

    Die rechnende Funktion als Ausschnitt aus asuro_st.c:
    Code:
    /*****************************************************************************
       FUNKTION:   NaviCalc
       Aufgabe:    Funktion zur Berechnung der Navigationswerte.
                   Diese Funktion wird im ADC-Interrupt aufgerufen um die aktuellen
                   Positions-Koordinaten und Richtung vom Asuro anhand der Daten
                   der Odometrie zu berechnen.
                   Ausgewertet werden die globalen Variablen count36kHz_l .._r
                   Die Ergenisse werden in einer globalen Datenstruktur fuer die
                   Anwendung zur Verfuegung gestellt.
       Parameter:  seite    Angabe, an welcher Rad-Seite der Tik gerade
                            aufgetreten war.
       Global:     count36kHz_l
                   count36kHz_r
       V011     26.11.2007  Sternthaler
                            Funktion in erster Version
    *****************************************************************************/
             unsigned char  NaviCalc (
             unsigned char  seite)
    {
    static            double speed_last_l = 0;
    static            double speed_last_r = 0;
                      double speed_l;
                      double speed_r;
                      double speed, omega, zeit;
                      double omega_zeit = 0, speed_zeit = 0;
    static            double phase_x = 0;
    static            double phase_y = 1;
    static            double pos_x = 0;
    static            double pos_y = 0;
    
       if (seite == RECHTS)
       {
          speed_l      = speed_last_l;
          speed_r      = 10789.0 / count36kHz_r;
          speed_last_r = speed_r;
          zeit         = count36kHz_r / 36000.0;
          count36kHz_r = 0;
       }
       else
       {
          speed_l      = 10789.0 / count36kHz_l;
          speed_r      = speed_last_r;
          speed_last_l = speed_l;
          zeit         = count36kHz_l / 36000.0;
          count36kHz_l = 0;
       }
    
       /*
          Mittelere Geschwindigkeit
       */
       speed = (speed_r + speed_l) / 2;
    
       /*
          Drehwinkel. Die 10.36 sind der Radabstand.
       */
       omega = (speed_r - speed_l) / 10.36;
    
       /*
          Neue Phasenwerte berechnen
       */
       omega_zeit = omega * zeit;
       phase_x = phase_x - phase_y * omega_zeit;
       phase_y = phase_y + phase_x * omega_zeit;
    
       /*
          Und endlich auch die neuen X- und Y-Positonen
       */
       speed_zeit = speed * zeit;
       pos_x = pos_x + phase_x * speed_zeit;
       pos_y = pos_y + phase_y * speed_zeit;
    
       MD_RAD_POS_HIST ((int)(pos_x * 100), (int)(pos_y * 100));
       
       return 0;
    }
    Ich weiß. Noch wird mit Fließkomma gerechnet. Noch sind nicht alle notwendigen Rechenschritte vorhanden. Und auch bei der Berücksichtigung der beiden Tik-Zeiten-Zähler ist bestimmt noch ein dicker Fehler vorhanden.
    Aber, das Ergebnis ist schon nicht allzu schlecht.

    Die besten Zahlen stecken zur Anschauung im Excel-Diagramm.

    @mare_crisium
    Deine neueste Version V06 ist noch nicht gelesen. Ich schätze, dass ich somit um das Schätzen dann demnächst auch nicht herrumkommen werde. Ich schätze aber, dass dies auch wieder etwas dauern wird .

    Zitat Zitat von oberallgeier
    ... für die Trägheit des Dings, ...
    Ich fühle mich geradezu angesprochen.
    P.S.: Ich glaube, der Asuro mit Taucheranzug ist noch nicht gebaut worden . Du erklärst die Probleme immer sehr schön bildlich. Klasse.

    So, viel Spaß mit dem Codehaufen.
    Gruß Sternthaler
    Angehängte Dateien Angehängte Dateien
    Lieber Asuro programieren als arbeiten gehen.

  7. #107
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    02.11.2005
    Beiträge
    1.614
    Wie gut das mein Visual C++ auch C lesen kann
    Dann les ich mal.

    Generell in der Theorie würde mich das mal Interessieren. Ich bin nich doof oder sowas aber für das obige Scriptbeispiel muss man Maschbau oder Physik Studieren ums zu verstehen oder Ich weis Grob was da abgeht, Vektoren und so, das Verlässt aber mein Bisschen Hochschulwissen das dafür Ausreicht irgendwelche lustigen Elektronen in irgendwelchen Feldern zu Berechnen, Theoretisch... Felder kommen erst nächstes Semester ^^

  8. #108
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    Hallo BlackDevil,
    toll, dass C++ lesen kann

    Wenn du alle Beiträge in diesem Thread auswendig kennst, dann kannst du das auch nachvollziehen.
    Schlieslich habe ich es auch (teilweise) geschafft aus den guten, hier gegeben, Bedienungsanleitungen diesen Code zusammenzustricken.
    Als kleiner Hinweis, woher die da angegeben Zahlen herkommen:

    - 10789.0 [cm/s^2 (glaube ich)] ist ein Faktor, der die Geometrie vom Asuro an der ODO-Scheibe darstellt. In dem hinterlegtem EXCEL-Blatt, im Reiter 'v und Zählerberechnung', wird der Wert in Anhängigkeit zwischen Raddurchmesser, und Tik-Anzahl pro Radumdrehung, berechnet.

    - 36000.0 [1/s] sind die 36 kHz, mit der ein Timer im Asuro rennt. Dieser liefert die Zählwerte zwischen 2 Tik's.

    - 13.36 [cm] ist einfach der Radabstand. In mare_crisium's Ausführungen sind das 2*a.

    Der Rest ist meine künstlerische Variante der Umsetzung aus dem Koppelnavigation_Algorithmus von mare_crisium.

    Ich hoffe, das dies etwas hilft. Und lass die Elektronen schön an ihren Plätzen, nicht dass die Welt auseinander bröselt .

    Gruß Sternthaler
    Lieber Asuro programieren als arbeiten gehen.

  9. #109
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.693
    Zitat Zitat von Sternthaler
    ... Und lass die Elektronen schön an ihren Plätzen, nicht dass die Welt auseinander bröselt ...
    Ja, wenn das nur ginge. Die Elektronen sind doch die, die alles durcheinanderbringen. Rennen von einem Pol zum anderen, kaum setzt man ihnen ein bisschen Widerstand entgegen, sind sie auf 180 und mehr aber wenn sie mal direkt aufeinandertreffen - also leider ist das Netzteile meines "Hauptrechners" gerade den Hitzetod gestorben (wo der vor 10 Tagen schon die SystemHDD unbrauchbar gemacht hatte).

    Die Neutronen sinds, die´s bringen. DIE halten das Universum zusammen. Und dabei sind sie kaum zu erkennen . . . beneidenswert!

    Sternthaler, eigentlich wollte ich mit "Danke für das Lob" anfangen. Aber ich neige eben zu solchen OT-Abschweifungen.

    Ach ja - wieviel Tics pro Radumdrehung sind beim Asuro üblich? Ich frage nur, weil ich für mein Miniprojektchen die erforderliche Auflösung abschätzen möchte.
    Ciao sagt der JoeamBerg

  10. #110
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    02.11.2005
    Beiträge
    1.614
    Mir gings ja nich um die Direkte Umsetzung sondern die Überlegung

    Problem --> Mathematik <--> Physik ==> Gleichungen

    Nehmen wir mal das Beispiel das ich einen Motor mit dem Drehmoment M=2Nm, zwei Angetriebene Räder mit dem Durchmesser d=10cm, eine Strecke von s=1m habe wobei ich 56° um die Kurve fahren will welche eine länge von 20cm hat. Jetz hab ich ja eigentlich alles was ich wissen muss um mir Gleichungen aufzustellen.

    v lässt sich aus der Frequenz der Räder errechnen. Ferner nehmen wir mal an das die räder Zylinder sind. Das machts einfacher das Trägheitsmoment auszurechnen.

    Wenn wir v und s haben als Gleichung können wir wunderhübsch ausrechnen wielange wir zur Kurve brauchen.

    Ab dann Verlässt mich die Überlegung.

    So meinte ich das (= Wie man das denn am besten umsetzt. Klar hab ich meine "Algorithmen" wie ich bei sowas vorgehe, die Versagen nur bei Manchen Aufgaben in Physik.

    JOa^^


    edit: Ich glaube das Universum fände es schon nich so schön wenn ein C Atom oder ein O Atom aufeinma 2 ELektronen weniger und ein anderes dafür 2 Elektronen mehr hat

Seite 11 von 15 ErsteErste ... 910111213 ... LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

LiFePO4 Speicher Test