- 3D-Druck Einstieg und Tipps         
Seite 3 von 3 ErsteErste 123
Ergebnis 21 bis 27 von 27

Thema: Geradeaus fahren: einfachste Lösung = beste Lösung ?

  1. #21
    Moderator Robotik Visionär Avatar von radbruch
    Registriert seit
    27.12.2006
    Ort
    Stuttgart
    Alter
    62
    Beiträge
    5.799
    Blog-Einträge
    8
    Anzeige

    Praxistest und DIY Projekte
    Muss wohl wirklich eine Bremse her..

    Du kannst ja ganz kurz in die Gegenrichtung fahren. Ersatzteile fürs Getriebe gibts beim C für ein paar €, aber ich denke, ein paar Tests sollten nichts zerstören.
    Bild hier  
    Atmel’s products are not intended, authorized, or warranted for use
    as components in applications intended to support or sustain life!

  2. #22
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.210
    Ich denke, ich versuchs etwas sanfter. Mit Vollgas Rückwärts klappt es auch nicht, das Problem scheint einfach zu sein, dass die Motoren nachlaufen. Auf diese Weise dürfte es genauso schwer sein, auf dem Punkt zu stoppen.
    Ich meine: mein Regler in meinem RC-Monstertruck bringt das Ding auch aus jeder Geschwindigkeit auf weniger als nem halben Meter (und das dosiert) zum stehen, _ohne_ dass der Rückwärtsgang eingelegt wird.
    Also Vollbremsung, aber mit ABS, muss doch gehen.
    Aber ich glaube, dazu dann mal nen neuen Thread, sonst wird das hier zu durcheinander.

  3. #23
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.03.2010
    Beiträge
    161
    Der P (und PD) Regler hat das Ziel, die Motordrehzal möglichst schnell zu regeln. Genau dies halte ich aber für ungeeignet, denn es führt zu durchdrehenden Rädern beim Anfahren und bremsen.

    Wenn ich den Regler mal einfach creativ anders einsetze uum damit die fahrstrecke zu steuern (anstatt die Geschwindigkeit), würde der Roboter nicht mit der gewünschten Geschiwndigkeit fahren 8die ich nämlich selbst bestimmen will) und er würde im Fall eines sehr warscheinlichen Überschwingers zuerst über das Ziel hinaus fahren, um dann wieder rückwärts zurück zurück an die richtige Stelle zu fahren. Das sähe ziemlich böde aus.

    Sehe ich das richtig?

  4. #24
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.210
    Genau das Problem habe ich ja derzeit.
    Grob läuft mein Programm so ab:
    Am Anfang gebe ich per Fühler die gewünschte Fahrstrecke ein (in cm, wird schön auf dem Display ausgegeben, rückwärts geht auch), wenn ich meine es ist genug, bestätige ich die Eingabe.
    Nun rechnet der ATMega die Fahrstrecke in Bieneneinheiten (Odoimpulse) um.
    Inzwischen (das Programm wartet an der Stelle bis ich wiederum eine Taste betätige, so kann ich den Roboter bequem hinstellen) hab ich den Roboter an die Startlinie gestellt, die Starttaste betätigt und er fährt los.
    Dabei werden mir derzeit ausgegeben: tatsächlich gefahrene Odoimpulse links, tatsächlich gefahrene Odoimpulse rechts und die noch zurückzulegenden Impulse.
    Mit dieser Methode stoppt die Biene _immer_ zu spät!
    Dank der Displayausgaben kann ich das leicht überprüfen.
    Je länger ich drüber nachdenke, umso weniger wundert mich das, denn der Motor dreht sich für vier Odoimpulse (eine Umdrehung des mittleren Rades) gerade fünf mal, das Ding rotiert also schon mit einigen hundert U/min.
    Inzwischen ist mir klar, dass es ohne Regelung (mindestens: gezieltes bremsen) nicht funktioniert.
    Nun wird bei mir der Trick drin bestehen, eine sichere Bremsstrategie zu finden, die das Teil auf dem Punkt wirklich stoppt.
    Wie du sagst: den Überbetrag zurückfahren klappt nur dann, wenn er gross genug ist (genau einen Impuls hab ich nie geschafft), und dann düst die Biene wieder zu weit.
    Am Ende landet man bei immer weniger Impulsen, die dann nicht mehr fahrbar sind. Dort fehlt der Biene einfach das Drehmoment, um sehr langsam auch fahren zu können.

    Wenn du es nur "leidlich" genau haben möchtest, genügt es, bei den letzten paar fehlenden Streckenzentimetern deutlich vom Gas zu gehen, dann kannst du eine Genauigkeit von nem Zentimeter erreichen, aber für längere Fahrstrecken (mit mehreren Stops oder Rangiermanövern) ist das nicht zu gebrauchen.

  5. #25
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    19.03.2010
    Beiträge
    161
    Ich habe dazu beobachtet, da man mit 20% PWM anfahren muss, sonst bleibt der Motor manchmal hängen, selbst wenn man danach mehr "Gas" gibt. Wenn die der Roboter dem Zielpunkt nähert, kann man aber locker auf 10% runter gehen, ohne dass er stehen bleibt.

    Um eine exakte Strecke zu fahren, muss man wohl vor dem Ziel die Geschwindigkeit langsam bis zum Stillstand drosseln.

    Man könnte natürlich auch bessere Reifen verwenden, aber das wäre ja zu einfach

    Worüber ich mir noch nicht so im klaren bin, ist, wie ich eine exakte Strecke fahre, die nicht geradeaus verläuft. Also einen Boden mit einem bestimmten Radius und einer bestimmten Länge. Die dazu nötige Geschwindigkeit und Odometer Impulse kann ich ausrechnen, das ist kein Problem. Aber wie sorge ich dafür, dass der Roboter seinen Kurs korrigiert, wenn ein Motor mal nicht genau so schnell dreht, wie er soll (was ja praktisch ständig der Fall ist).

    Beim geradeaus fahren war das noch einfach: Immer wenn eine Seite weniger Strecke gefahren ist, als die andere, dann nehme ich vom schnelleren Motor die Spannung weg, bis die Zähler wieder gleich sind.

    Nun soll das auch bei einem Bogen funktionieren, möglichst ohne Fließkomma-Zahlen.

    Dieser Roboter ist viel spannender, als ich gehofft hatte. Ich habe schon seit mehr als einer Woche Spaß mit vor- und und zurück-fahren. Meine Frau findet das völlig banal, aber die sitzt ja auch nicht vor der Tastatur.

  6. #26
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.210
    Das mit der Frau kenne ich, wenn ich meiner Freundin von meinen Fortschritten erzähle, sieht sie mich genauso an wie ihr Hund, wenn ichs _dem_ erzähle. [-(

    Und du hast recht, es macht wahnsinnig Spass, richtig spannend.
    Ich habe inzwischen etwas probiert:

    Gezieltes Bremsen (ein, zwei Odoklicks vor dem Ziel rückwärts) _kann_ funktionieren, aber zu ungenau, damit kriege ich das Ergebnis runter auf ca. einen Odoklick (ich weiss, blödes Wort aber die Variable in meinem Programm heisst nunmal so und ich glaube, irgendwann denkt man einfach in Variablen ), aber das reicht mir nicht.

    Im Moment bin ich dabei, ein Stück vor dem Ziel (derzeit zehn Odoklicks, also rund 6cm) das Tempo zu drosseln, so dass bei Zählerstand Null auch die Motoren stehen: funktioniert nicht wirklich.
    Obwohl ich in 50er Schritten runterregle (immer einen pro Klick, weil ich mit Halbgas "repräsentativ" arbeite, ergeben sich weiterhin die üblichen Ungenauigkeiten.
    Ausserdem gefällt mir diese Lösung nicht: 6cm Bremsweg??
    Es _muss_ deutlich kürzer gehen, sonst ist die Variante viel zu unflexibel.
    Leider haben beide Varianten einen grossen Nachteil: sie sind im Grunde unkontrollierbar, man kann in Situationen kommen, in denen der Roboter zu früh oder zu spät steht. Es funktioniert mit voreingestellten Parametern so untergrundabhängig, dass ich bei letzter Methode z.B. auf Teppich das Ziel gar nicht erreichen kann, während der Roboter im Freien ( Räder in der Luft) noch immer zu weit "fährt".

    Ich denke, da muss ein eigenes Bremsprogramm hinein, was obendrein die Drehzahl überwacht.
    Nur habe ich ab und an jetzt schon den Verdacht, dass mitunter Odoklicks "übersehen" werden, weil einfach irgendwas nicht mehr nachkommt- ist das technisch denkbar?
    Soweit ich es richtig verstanden habe, erzeugen doch die Odosensoren einen Interrupt, richtig?
    Wenn das aber stimmt, dann _müssen_ die ja auch, falls zurzeit eine andere Interruptroutine läuft (nebenbei strapaziere ich in meinem Programm Timer0 ein bisschen), gespeichert und anschliessend richtig aufgerufen werden? Auch richtig?
    Leider hab ich nicht genug Ahnung von der Sache, um beurteilen zu können, _Was_ man besser unterlassen sollte, um den Prozessor nicht nennenswert auszubremsen, ich weiss nur, dass Fliesskommaberechnungen richtig dauern können, darum würdest du wohl gerne ohne auskommen?
    Es geht, wenn sie nicht in zeitkritischen Momenten erfolgen, und _das_ kann man umgehen, denke ich (bei hindernisfreier Fahrt kann der Prozessor das nebenbei mit erledigen).
    Das Problem bei den gespeicherten (und zeitlich später ausgewerteten Odo-Interrupts ist klar: ehe der Prozessor reagieren kann, stimmt der Odowert im Extremfalle nicht mehr, muss also alles fix gehen.

    Die Räder sind übrigens absolut nicht das Problem (wobei klar ist, dass dauerhaft bessere rauf müssen), es ist wie ich sagte:

    Die Motoren rotieren nach dem Abschalten noch etwas weiter (normal, Masseträgheit) und dadurch wird übers Ziel hinaus gefahren.
    Kannst du auch ohne Display testen:
    schreib dir eine kleine Routine, die ein Lämpchen anschaltet, _wenn_ der Roboter zu weit "gefahren" ist und lass ihn einfach, wie ichs tu, leer laufen (anheben), dann kannst du Radschlupf ausschliessen.
    Immerhin braucht der Motor durch die Getriebeuntersetzung, nur ein und ne viertle Umdrehung, und schon hast du einen Odoklick zu viel auf dem Tacho.

  7. #27
    Erfahrener Benutzer Robotik Visionär Avatar von oberallgeier
    Registriert seit
    01.09.2007
    Ort
    Oberallgäu
    Beiträge
    8.693
    Zitat Zitat von s.frings
    ... Worüber ich mir noch nicht so im klaren bin, ist, wie ich eine exakte Strecke fahre ... wenn ein Motor mal nicht genau so schnell dreht ...
    GENAU diesen Ausgleich erledigt die Regelungstechnik, siehe mein Posting von gestern bzw. dort die Links zum Thread, in dem ich diese Arbeiten für meinen Zweiräder beschreibe. Beweis: das dort verlinkte Video mit dem Testlauf auf YouTube.
    Ciao sagt der JoeamBerg

Seite 3 von 3 ErsteErste 123

Berechtigungen

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

12V Akku bauen