- 3D-Druck Einstieg und Tipps         
Ergebnis 1 bis 10 von 20

Thema: Anfangsplanung: autonomer Packesel

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    67
    Beiträge
    2.435
    Hallo Amrosik,
    Zitat Zitat von amrosik Beitrag anzeigen
    Panzerlenkung erscheint auf den ersten Blick einfacher als die Achsschenkellenkung, da es bei 4 unabhängigen Motoren nur eine softwarelastige Aufgabe gibt: Und zwar die koordinierte Drehzahlregelung der Motoren (Drehzahlencoder wären also in diesem Fall sogar Pflicht). Die Frage ist: Wie erfolgt die Regelung? Unter dem zweiten Link stand was von "Fuzzy-Logic Drehmoment-Management". Hört sich interessant an. Was ist das? Bringt's was?
    Fuzzy-Logic war mal ein Hype vor so 25 Jahren.

    Digitale Logik kann Fragen nur mit Ja und Nein beantworten:
    Ist das Schwarz: Nein
    Ist das Weiss: Nein


    Tja was denn nu ????

    Fuzzylogik meint da z.B.
    Ist das Schwarz: 60%
    Ist das Weiss: 40%


    Daraus kann man schliessen, dass es ein leicht dunkleres Grau sein muss.


    Mit Fuzzy-Logik lassen sich viele Aufgaben lösen, welche eben nicht auf genauen Werten basieren.

    Etwas vereinfacht muss man mit Fuzzy-Logik nur die Punkte für 100% Zustimmung und 0% Zustimmung im Parameterfeld festlegen. Alles dazwischen berechnet die Fuzzy-Logik dann selbständig.

    Man kann dann auch noch die Übertragungsfunktion zwischen 0% und 100% festlegen, diese kann linear, progressiv oder degressiv sein.

    MfG Peter(TOO)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  2. #2
    Benutzer Stammmitglied
    Registriert seit
    16.07.2008
    Beiträge
    54
    Generell ist ne Panzerlenkung und Outdoor eher keine saubere Lösung (funktionieren kann vieles, nur wie...), denn grade im Freien braucht man Grip-und der kämpft bei jeder Lenkbewegung dann gegen...
    Ja. Allerdings ist die Strecke nicht allzu kurvig. Es ist wirklich überschaubar. Panzerlenkung ist sicher nicht das beste. Aber es ist wiegesagt nur ein Mittel zum Zweck. Die Frage nach dem "Wie" ist nicht entscheidend.

    Dieses "wegdriften" hab ich _nur_ im Stand, in der Bewegung hab ich das nie feststellen können.
    Dann wäre es also gut, die Datenerfassung stumm zu schalten und die letzte Position zu speichern, solange keine weiteren Bewegungsbefehle erteilt werden?

    Bei Wegpunkten bin ich immer der Meinung, weniger ist mehr. Klar kann man den Weg Zentimeter für Zentimeter beschreiben- aber bekommst du es hin, dass da irgendein Rechner die wirklich wichtigen Punkte erkennt und nicht stur jeden einzelnen zu erreichen versucht?
    Ich hatte meinem Monster mal den Auftrag gegeben, nen vorher aufgenommenen Punkt wieder anzufahren.
    Also: Fahrzeug hinstellen, Knopf drücken, warten bis das GPS gemessen hat, dann die Stelle markiert, mit dem Auto 50m weg gegangen, hingestellt und "fahr wieder heim"- und dann hab ich amüsiert ne knappe Stunde zugesehen, wie es immer wieder zwei Meter am Ziel vorbeigefahren ist.
    Also wenn ich die Koordinaten nicht selbst messe, sondern aus einer Datenbank hole, dann ist dieses Ablaufen auch nicht nötig.
    Was das ständige Vorbeifahren angeht: Schritttempo ist schon heftig. Die Rück-Strecke (nur die ist wichtig) ist 650 meter lang (Quelle:Google Maps). Die soll der Roboter im 15 Minuten beenden. Das macht 2.6 kmh im Schnitt. Aber was ich nicht verstehe: Wieso genau ist er/es ständig dran vorbeigefahren? Hast Du kein IMU verwendet?


    Ich empfehl dir das, woran ich jetzt schon seit...hm, anderthalbem Jahr oder so sitze (allerdings in loser Folge, ich lass mich da nich stressen), einfach erst mal _irgendein_ Fahrzeug draussen alleine vorgegebene Wege abfahren.
    Meins ist nen 1:10er Tamiya Monstertruck. Trägt deine gewünschten 10 Kilo zwar nicht (ziehen könnt er die allerdings vermutlich), aber die Technik, die zum fahren und navigieren nötig ist, schon.
    Wenn das mal läuft, braucht man es im Grunde nur wo anders einbauen...
    Hmm... ich hab mir jetzt schon einpaar Teile aus China bestellt (billiges Zeug, aber gut zum Rumprobieren, Lieferung dauert etwas...).
    Ein Raspberry Pi, Gyro, 3Achsen-Beschleunigungssensor. GPS muss ich noch bestellen (Raspberry Shield?), und Kompass auch. Bevor ich etwas fahren lasse, muss ich erstmal den Kalmanfilter implementieren (hab das noch nie gemacht).

    Zum GPS: nun, nen gutes schafft durchaus ne Genauigkeit von nem Meter. Mein billiges (kann leider die PPP-Technik nicht) zwei. Damit kann man schon einiges anfangen, oder?
    Zusammen mit nen paar weiteren Sensoren geht da was.
    Wenn ich das Prinzip richtig verstanden habe, sorgen die Sensoren nur dafür, dass über kurze Zeitabschnitte die Position genauer getrackt wird.
    Letztendlich sei aber die Genauigkeit durch die des GPS begrenzt. Selbst wenn die Sensoren sehr präzise arbeiten, liefern sie nur relative Korrekturen. Selbst wenn ich es schaffe, die Koordinaten des Startpunkts centimetergenau zu bestimmen (oder aus irgendeiner Datenbank zu beziehen), wird sich diese Centimetergenauigkeit nicht über die gesamte Strecke aufrechterhalten, sondern frühzeitig abbauen, und gegen die Ungenauigkeit des GPS-Sensors (im Meterbereich) konvergieren. Am Ende hängt alles am GPS, Kalman hin oder her. Sehe ich das richtig?


    Hier hätte ich eine Idee, wie man die absolute Ortung verbessern könnte. Neben platzierten Tags könnte man vielleicht die Streckeneigenschaften mit einbeziehen. Hat die Strecke z.B. die Abfolge {5%-Steigung, Flach, 5%-Steigung, 10%-Gefälle, Flach}, und wenn der Roboter jetzt z.B. jetzt den Übergang Flach-->10%Gefälle wahrnimmt, dann gibts in dem Beispiel nur einen Ort, wo das sein kann. Wenn ich die absolute Position dieser Orte vorher aufgezeichnet habe, dann habe ich jetzt eine absolute Position. Vielleicht könnte man auch andere Streckencharakteristiken einbeziehen. Z.B. Wegübergange (Pflasterstein-->Waldweg), die zu charakteristischen Signalen des IMU führen.


    Etwas vereinfacht muss man mit Fuzzy-Logik nur die Punkte für 100% Zustimmung und 0% Zustimmung im Parameterfeld festlegen. Alles dazwischen berechnet die Fuzzy-Logik dann selbständig.
    Und wie ist es hinblicklich Drehzahlen? Was soll man da überhaupt groß regeln? Wenn die Konstruktion und Gewichtverteilung halbwegs symmetrisch sind, dann reicht es doch aus, die Drehzahlen der Motoren auf jeweils einer Seite aneinander anzugleichen, und die Drehzahlen links vs. rechts so zu regeln, dass die gewünschte Bewegung (z.B. Drehnung mit 30°/s um sich selbst) ausgeführt wird. Ich würd sagen PID-Regler
    Geändert von amrosik (29.04.2016 um 22:40 Uhr)

  3. #3
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    67
    Beiträge
    2.435
    Zitat Zitat von amrosik Beitrag anzeigen
    Aber was ich nicht verstehe: Wieso genau ist er/es ständig dran vorbeigefahren? Hast Du kein IMU verwendet?
    Das Problem beim GPS ist, dass es ein militärisches System ist, welches von den USA extra gestört wird. Die US-Militärgeräte kennen die Störung und arbeiten im m-Bereich genau.
    Die Zivilen Geräte waren anfänglich auf etwa 100m genau. Wobei die keine feste Abweichung haben. Wenn du den Empfänger fest aufstellst bist du laut Koordinaten dauernd in einem Umkreis von 100m in Bewegung! Im Jahr 2000 hat das US-Militär die künstlichen Störungen abgeschaltet. Schaltet sie aber lokal über Krisengebieten ein.

    Das war auch das Problem des armen Robis. Der hat gemessen wo er ist, aus der Abweichung den Weg berechnet und diesen gefahren. Kaum war er an seinem Ziel, sagte das GPS: Ätsch Bätsch du bist 2m neben dem Ziel! Also alles nochmal von Vorne ...

    Das brachte dann ein paar Leute auf die Idee des Differential-GPS. Man stellt ein GPS an einer bekannten Koordinate auf und berechnet die Differenz zur GPS-Messung. Die Abweichung sendet man dann an bewegliche GPS-Empfänger, welche dann ihre Messung entsprechend korrigieren können. Mit entsprechendem Aufwand kommt dann in den Bereich von mm als absoluter Fehler.

    Zitat Zitat von amrosik Beitrag anzeigen
    Hier hätte ich eine Idee, wie man die absolute Ortung verbessern könnte. Neben platzierten Tags könnte man vielleicht die Streckeneigenschaften mit einbeziehen. Hat die Strecke z.B. die Abfolge {5%-Steigung, Flach, 5%-Steigung, 10%-Gefälle, Flach}, und wenn der Roboter jetzt z.B. jetzt den Übergang Flach-->10%Gefälle wahrnimmt, dann gibts in dem Beispiel nur einen Ort, wo das sein kann. Wenn ich die absolute Position dieser Orte vorher aufgezeichnet habe, dann habe ich jetzt eine absolute Position. Vielleicht könnte man auch andere Streckencharakteristiken einbeziehen. Z.B. Wegübergange (Pflasterstein-->Waldweg), die zu charakteristischen Signalen des IMU führen.
    So in der Art haben die BVB (Basler Verkehr Betriebe) bestimmt wo sich die Trams und Busse befinden. Man hat dazu nur die Fahrstrecke zwischen zwei Stationen gemessen. Im schlechtesten Fall, wusste dann der Computer nach 3 Haltestellen wo das Fahrzeug jetzt sein muss.


    Zitat Zitat von amrosik Beitrag anzeigen
    Und wie ist es hinblicklich Drehzahlen? Was soll man da überhaupt groß regeln? Wenn die Konstruktion und Gewichtverteilung halbwegs symmetrisch sind, dann reicht es doch aus, die Drehzahlen der Motoren auf jeweils einer Seite aneinander anzugleichen, und die Drehzahlen links vs. rechts so zu regeln, dass die gewünschte Bewegung (z.B. Drehnung mit 30°/s um sich selbst) ausgeführt wird. Ich würd sagen PID-Regler
    Die unbekannte dabei ist der Schlupf. Je nach Untergrund dreht ein angetriebenes Rad mehr oder weniger durch. Die berechnete Strecke aus Radumfang * Umdrehungen ist immer grösser als die tatsächlich zurückgelegte. Im Extremfall steht das Rad auf Glatteis und dreht durch. Berechnet bist du unheimlich schnell unterwegs, obwohl du dich real keinen cm bewegst.

    MfG Peter(TOO)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  4. #4
    Benutzer Stammmitglied
    Registriert seit
    16.07.2008
    Beiträge
    54
    Das war auch das Problem des armen Robis. Der hat gemessen wo er ist, aus der Abweichung den Weg berechnet und diesen gefahren. Kaum war er an seinem Ziel, sagte das GPS: Ätsch Bätsch du bist 2m neben dem Ziel! Also alles nochmal von Vorne ...
    Wurde das im Jahr 2000 ganz abgeschaltet, oder nur von 100m auf 2m gedrosselt (Ich geh mal davon aus, dass @Rabenauge das Experiment noch in diesem Jahrhundert gemacht hat)?


    Die unbekannte dabei ist der Schlupf. Je nach Untergrund dreht ein angetriebenes Rad mehr oder weniger durch. Die berechnete Strecke aus Radumfang * Umdrehungen ist immer grösser als die tatsächlich zurückgelegte. Im Extremfall steht das Rad auf Glatteis und dreht durch. Berechnet bist du unheimlich schnell unterwegs, obwohl du dich real keinen cm bewegst.
    Bei der Panzerlenkung sollte man doch sowieso auf Odometrie verzichten, oder? Also so wie ich @Rabenauge verstanden habe.

    Da ich die reale Bewegung nur durch das IMU messe, kann das Rad ruhig durchdrehen wenn es will. Wenn der Roboter die Drehnung mit 30°/s um sich selbst gerade nicht hinkriegt, weil die linken Räder durchdrehen, während die rechten Grip haben, dann wird das IMU diese Diskrepanz feststellen. Das PID wird dann die rechten Drehzahlen reduzieren, und die linken erhöhen.

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2013
    Ort
    Region Basel
    Alter
    67
    Beiträge
    2.435
    Zitat Zitat von amrosik Beitrag anzeigen
    Wurde das im Jahr 2000 ganz abgeschaltet, oder nur von 100m auf 2m gedrosselt (Ich geh mal davon aus, dass @Rabenauge das Experiment noch in diesem Jahrhundert gemacht hat)?
    Naja, das ist eine komplizierte Geschichte.
    Grundsätzlich darf man nicht vergessen, dass GPS ein militärisches System ist! Deshalb gibt es auch das Galileo-Projekt der Europäer, welches ein ziviles System ist.

    Bei GPS gibt es die zivile Nutzung, welche absichtlich gestört werden kann. Dieser Teil ist, ausser über Krisengebieten, abgeschaltet worden. Das US-Militär behält sich aber vor, dies jederzeit wieder zuzuschalten. z.B. im Einflussgebiet des IS dürfte GPS aktuell keine verlässlichen Daten empfangen.
    Teil des GPS-Prinzips ist es, dass der Satellit seine genaue Position kennt und diese, zusammen mit der Zeit, aussendet. Somit kann man auch auf bestimmten Bahnabschnitten ein verfälschtes Signal senden.

    Zudem gibt es noch ein paar Geheimnisse, welche das Militär nicht preis gibt. Ein Teil der gesendeten Daten ist deshalb verschlüsselt.

    Hinzu kommt, dass es mittlerweile um die 6 Generationen von GPS-Satelliten gibt, wobei von der ersten Generation keine mehr in Betrieb sind. Jede Generation ist natürlich etwas besser als ihre Vorgänger.

    MfG Peter(TOO)
    Manchmal frage ich mich, wieso meine Generation Geräte ohne Simulation entwickeln konnte?

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von Rabenauge
    Registriert seit
    13.10.2007
    Ort
    Osterzgebirge
    Alter
    56
    Beiträge
    2.213
    Meine 2m haben weniger mit der Genauigkeit von GPS allgemein zu tun, sondern damit, dass mein Empfänger (neo 6-m von Ublox) beispielsweise die PPP-Technologie _nicht_ unterstützt.
    Dafür nutzt er aber auch so längst nicht nur reine GPS-Daten, sondern beispielsweise (wenn ers empfangen kann) auch die SBAS-Korrekturdaten.
    Nen GPS ist lange nicht mehr ein reiner GPS-Empfänger, die dinger stellen intern mit den empfangenen Daten noch ne ganze Menge an, um die Genauigkeit zu verbessern.
    Allerdings wird da jeder Hersteller sein eigenes Süppchen kochen, und auch vom selben Hersteller gibts oft Teile mit verschiedenen Features, das neo 6-p beispielsweise nutzt PPP-und kommt damit unter nem Meter in der Genauigkeit!
    Leider hab ich das Ding noch nicht als Modul gesehen.
    Grüssle, Sly
    ..dem Inschenör ist nix zu schwör..

  7. #7
    Benutzer Stammmitglied
    Registriert seit
    16.07.2008
    Beiträge
    54
    Kann man das neo 6-p so ohne Weiteres an einem Raspberry Pi betreiben? Bei dem Modul was ich gefunden habe, werden Treiber für Linux angeboten, deshalb gehe ich davon aus, dass man das Modul einfach an die USB-Buchse des Raspberry anschließen kann. Damit wäre es aber noch nicht getan:

    Wie kann man an die Rohdaten in Echtzeit ran, um sie in eigenen Python- oder C++-Programmen zu verwenden?

  8. #8
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    09.04.2008
    Beiträge
    384
    Meine "gps-rover" basiert sich auf eine billiges IMU MPU9250, ein GPS Ublox M8N und eine STM32 µcontroller. Das alles auf eine Hobbyking "Rattler" chassis. Das alles functioniert relatif gut. Folgende problemen :
    GPS Genauigkeit ist ca +/- 1 meter bei gute Bedingungen ! Im Wald wahrscheinlich schlechter. IMU ist absolut notwendig, um die Himmelsrichtung von Rover zu kennen. Eine Bahn abfahren schmaller dan 4 meter, ist sehr schwierig. Hindernis Erkennung ist schwierig, US-sensoren sind sie ungenau, sie wissen nur "da ist etwas in ein Kegel for mich", kann einfach ein unebenheit auf die Strassen sein.
    differential GPS ist eine moglichkeit, aber immer noch relatif teuer (>200€). Meine Rat : fange an mit so etwas, und wenn das klappt konnen sie weiter gehen mit eine 10 kilo rover.
    Videos : Ein einfaches Track (Rechteck)

    Etwas schwieriger in Winter :

    GPS Racen :

Ähnliche Themen

  1. Autonomer Temperaturlogger
    Von Murus im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 2
    Letzter Beitrag: 04.08.2007, 13:04
  2. Autonomer sensorbot
    Von Janus im Forum Vorstellung+Bilder+Ideen zu geplanten eigenen Projekten/Bots
    Antworten: 11
    Letzter Beitrag: 12.02.2006, 09:22
  3. Autonomer Heli
    Von REX im Forum AVR Hardwarethemen
    Antworten: 10
    Letzter Beitrag: 07.05.2005, 17:34
  4. autonomer Staubsauger
    Von SquallFandango im Forum Staubsaugerroboter / Reinigungs- und Rasenmähroboter
    Antworten: 4
    Letzter Beitrag: 19.11.2004, 13:46
  5. autonomer roboter
    Von busty im Forum Motoren
    Antworten: 5
    Letzter Beitrag: 05.08.2004, 16:58

Berechtigungen

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

LiFePO4 Speicher Test