-         
Seite 8 von 11 ErsteErste ... 678910 ... LetzteLetzte
Ergebnis 71 bis 80 von 110

Thema: Think Modular

  1. #71
    Erfahrener Benutzer Fleißiges Mitglied Avatar von Defiant
    Registriert seit
    17.04.2005
    Ort
    Hamburg
    Beiträge
    161
    Anzeige

    Ja stimmt, war nur etwas verwirrt weil ich in einem Roboter einen ESC habe von dem ich nur die Geschwindigkeit auslesen kann.

  2. #72
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    736
    Tja, genau das geht bei meinem kettengetriebenen Modell nicht. Eine einigermaßen schnelle Geschwindigkeitsregelung über die Messung der Gegen-EMK am Antrieb ist zwar durchführbar, hat aber wegen Schlupf und Bodenhaftung mit der Bewegung des Fahrwerks wenig gemeinsam.
    Ich messe die Odometrie unabhängig vom Antrieb durch zwei zusätzliche Messräder. Da bekomme ich im 8ms-Zyklus von den Inkrementalgebern +/-0..3 Schritte - das reicht für die Posenberechnung, gibt aber zu wenig Fleisch als Istwert einer Geschwindigkeitsregelung.

    Kurz: Ich habe keine Geschwindigkeitsregelung.

  3. #73
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    736
    So, kurz zusammengefasst: Ich hatte bislang Bewegungsmodul, Powermodul und ein Protokoll angerissen. Fehlt eigentlich noch die nach außen gerichtete Sensorik.

    Fertige Lidars (RPLidar/YDLidar < 100€) sind recht erschwinglich geworden und sind mit UART auch problemlos anzubinden. Bei einem Eigenbau mit einem oder mehreren Distanzsensoren (LidarLite, TFMini, VL53L1X) und einer Drehmimik hat man vielleicht noch einige Freiheitsgrade mehr:
    - Man kann mehrere Sensoren auf einen Drehteller packen, ohne dass sie sich gegenseitig die Sicht einschränken.
    - Man kann mit einem leicht nach unten geneigten Sensor das Nahfeld abtasten.
    - Man kann auch Sensoren einbauen, die nichts mit einer Distanzmessung zu tun haben (z.B. die Richtung einer IR-Diode anpeilen).
    Letztlich braucht es zum Eigenbau einen Drehantrieb (Motor), eine Drehwinkelerfassung (damit ein Sensorwert einer Richtung zugeordnet werden kann) und einer Übertragung von Strom und Daten (wenn sich der Teller kontinuierlich 360° drehen soll).

    Andere Möglichkeit: Kameras in 2 oder 3D, also Kinect, RealSense oder CAM. Sind über USB angeschlossen nicht so bastelintensiv, legen aber die Messlatte der Hardwareanforderungen bezüglich Auswertesoftware recht hoch an.

    Dann gibt's auch noch Hilfsmittel zur Positionsbestimmungen per Funk GPS & Co. Die geben aber keine Informationen über die Umgebung (Hindernisse) preis. Man weiß also, wo man in etwa ist, aber ohne Umgebungskarte nicht, wo man entlangfahren kann.

    Was gibt's noch?

  4. #74
    Erfahrener Benutzer Fleißiges Mitglied Avatar von Defiant
    Registriert seit
    17.04.2005
    Ort
    Hamburg
    Beiträge
    161
    Zitat Zitat von Holomino Beitrag anzeigen
    Eine einigermaßen schnelle Geschwindigkeitsregelung über die Messung der Gegen-EMK am Antrieb ist zwar durchführbar, hat aber wegen Schlupf und Bodenhaftung mit der Bewegung des Fahrwerks wenig gemeinsam.
    Wenn man will geht es auch. Mein erster Roboter für den ich einen ROS-Adapter geschrieben habe, hatte auch Ketten. War zugegeben eine Aufgabe über Wochen. Langsam anfahren hilft. Um Fehler bei der Rotation auszugleichen gibt es IMUs. Fehler bei der Rotation führen ja bekanntermaßen zu größeren Fehlern in der Position als Fehler in der Translation. Multikopter bekommen es ja auch hin die Geschwindigkeit über Grund zu messen.

    Zitat Zitat von Holomino Beitrag anzeigen
    Andere Möglichkeit: Kameras in 2 oder 3D, also Kinect, RealSense oder CAM. Sind über USB angeschlossen nicht so bastelintensiv, legen aber die Messlatte der Hardwareanforderungen bezüglich Auswertesoftware recht hoch an.
    Muss nicht sein wenn man nur eine oder N-Bildzeilen auswertet erhält man ein einfaches Array. Dies habe ich anfangs mit der XTion gemacht . Hat gut funktioniert, Lidar ist aber überlegen wegen der geringeren (Die XTion war bei unter 80cm blind) und höheren Reichweite sowie konstanteren Genauigkeit (Die Daten der XTion waren ab 3m für Slam nicht mehr zu gebrauchen).

    Bei den Sensoren würde ich unterscheiden ob ich sie für Hinderniserkennung oder Positionsbestimmung verwende. Dies sind zwei Anwendungsfälle die meiner Meinung nach nichts miteinander zu tun haben, obwohl ich teilweise dieselben Sensoren einsetzen kann. Außerdem würde ich für Hinderniserkennung unterschiedliche Sensortypen miteinander kombinieren, ich verwende z.B. Lidar und US-Sensoren. Das Lidar liefert keine verlässlichen Abstände bei Spiegeln, Fenstern und Sonnenlicht, die US-Sensoren versagen bei schalldämpfenden Stoffen (Kissen..).

  5. #75
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    736
    Zitat Zitat von Defiant Beitrag anzeigen
    Bei den Sensoren würde ich unterscheiden ob ich sie für Hinderniserkennung oder Positionsbestimmung verwende. Dies sind zwei Anwendungsfälle die meiner Meinung nach nichts miteinander zu tun haben, obwohl ich teilweise dieselben Sensoren einsetzen kann. Außerdem würde ich für Hinderniserkennung unterschiedliche Sensortypen miteinander kombinieren, ich verwende z.B. Lidar und US-Sensoren. Das Lidar liefert keine verlässlichen Abstände bei Spiegeln, Fenstern und Sonnenlicht, die US-Sensoren versagen bei schalldämpfenden Stoffen (Kissen..).
    Das ist korrekt. Auch bei den käuflichen Staubsaugern mit Lidar findet man immer noch Bumper und andere Sensoren, die die Umgebung unterhalb der horizontalen Lidarebene abtasten.

    Dieses Thema birgt einige Tücken. Streng genommen müsste der gesamte Roboter von der Ebene der Bodenfreiheit (was er hochsteigen kann) bis zur höchsten Stelle mögliche Kollisionen melden. Bei Rückwärtsbewegungen gilt das auch für's Heck, mit Omniwheels wird's noch wilder.

    (Nähkästchen an)
    Ich habe hier ein Klo (an der Wand befestigt) und einige Heizkörper, deren Unterkante sich genau 1cm mit der Höhe der Sensorplattform meines Roboters überschneiden. Kein Sensor sieht, wenn der Robbi sich daran festsetzt. Die obersten 2cm meines Roboters sind wirklich unüberwachte Zone. Der Drehteller der Sensorik bleibt aber bei einer Kollision stecken. Zur Zeit (weil ich keine Lust hatte, noch einen Sensor leicht nach oben messend dranzubauen) besteht meine kreative Lösung darin, den Störfall "Plattformmotor ist an, Richtungsdetektion zeigt aber keine Drehung" als Reflex auszuwerten, durch den sich der Roboter freifährt.
    (Nähkästchen aus)

    Ich denke mal, jedes "Labor Wohnung/Gelände" hat da so seine Fallen. Da die Hindernisdetektion von den tatsächlichen Abmessungen des Roboters abhängt, spricht aber doch nichts dagegen, sie als Beiwerk in den Modulen, die das Mobil physikalisch vergrößern, zu verpacken. Egal wie viele Sensoren welcher Art man braucht: Ein unpassierbares Hindernis zeichnet sich nur durch seinen Standort aus.
    Geändert von Holomino (30.11.2020 um 09:45 Uhr)

  6. #76
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    736
    Es fehlt immer noch was - der Braincomputer:
    Nachdem wir nun wissen, das wir laufend von Navigations- und Hindernissensorik, Bewegungsmodul und Powermodul mit Daten bombardiert werden, wir auch noch Fahranweisungen und Steuerkommandos zurückschicken müssen, wird es Zeit, sich über den Umfang dieser Aufgabe klarzuwerden.

    Zur Anbindung:
    Ich hatte ja schon im Eingangsthread den Vorschlag gemacht, Bluetooth als Schnittstelle zur Hardware zu verwenden. Dann kann man z.B. auch das ausgediente Smartphone als Brain nutzen oder zur Entwicklungszeit die typischen 10m Reichweite dazu verwenden, komfortabel am PC oder Notebook zu entwickeln. Für den autarken Betrieb braucht man noch einen Versorgungsstecker. Brains ohne eigenen Akku, z.B. Raspberrys, quittieren eine Notabschaltung ohne geordnetes Herunterfahren im schlimmsten Fall mit einer kaputt geschriebenen SD-Karte. Das sollte man im Powermodul durch eine Ausschaltverzögerung berücksichtigen.

    Zur Aufgabe:
    SLAM baut eine Umgebungskarte und verbessert die Pose des Roboters darin. Die Funktion lässt sich am besten durch einen Stitch-Assistenten verdeutlichen, der laufend Teilbilder aus der Navigationssensorik möglichst passend übereinanderlegt und so über die vorgenommene Verschiebung eines eingefügten Teilbildes auf die tatsächliche Pose des Roboters rückschließt.

    Sicher wird ein Roboter die Umgebungskarte für seine Fahrten nutzen, das Generieren der Bahnen ist allerdings nicht direkter Bestandteil von SLAM. Ein Pathfinder sucht auf der Umgebungskarte den kürzesten Weg von A nach B, ein Pathfollower führt die Fahrt durch senden von Steuerbefehlen an den Antrieb aus. Tritt im Verlauf der Fahrt ein Fehler (ein neues Hindernis) auf, muss der Pathfinder neu berechnen.
    Ein Aufgabenplaner plant Abfolgen (z.B.: Fahre von A über B nach C und zurück nach A). Bei einem Überwachungsroboter z.B. werden so eine Reihe von anzufahrenden Wegpunkten und eine Uhrzeit für die Ausführung vorgegeben. Beim Saugroboter generiert der Aufgabenplaner die Wegpunkte in einem Raster, um die gesamte Bodenfläche abzudecken.

    Das alles wollen wir überwachen und auch steuern. Dazu brauchen wir eine lesbare Darstellung der Umgebungskarte, der aktuellen Roboterpose und auch Eingriff in die Aufgabenplanung. Das bitteschön aber nicht am Gerät, sondern bequem vor einem Monitor - sonst müssten wir ja hinterherrennen.

    Mal ein Fallbeispiel: Eine 10mx10m=100qm-Wohnung und ein Lidar

    Die Umgebung lässt sich theoretisch in einem Occupancy-Grid (2D-Array, in dem je ein Wert eine x-y-Rasterfeld als frei, belegt oder unbekannt beschreibt) von 100x100=10000 Bytes mit den Abmessungen 10x10cm darstellen.
    - Praktisch wissen wir nicht, wo und in welchem Winkel zu den Grundabmessunen wir starten. Das vergrößert das Grid ohne weiteres Speichermanagement um den Faktor (2*Wurzel(2))²=8 (Wir starten in der Mitte des OccupancyGrids und lassen in allen vier Himmelsrichtungen Platz für die Diagonale der 10*10m-Wohnung).
    - Wir müssen unterscheiden zwischen Umgebung für den Stitch-Assistenten und Hindernisdetektion (was das Lidar nicht sieht, kann es nicht wiedererkennen). In eine zusätzliche Liste werden Hindernisse eingetragen (das Datenaufkommen ist wahrscheinlch niedrig).
    - Die Umbewertung eines Feldes von "frei (>0)" auf "belegt (<0)" ist im worst case relativ träge (von 127 auf -1). Lidars haben die Eigenschaft, zwischen zwei Einzelmessungen eine Lücke aufzuweisen. So sieht man Stuhl- oder Tischbeine erst bei Annäherung. Man kann das Lidar aber selber als Hindernissensor interpretieren, also z.B. den letzten Scan in die Hindernisliste schreiben. Über die logische Oder-Verknüpfung von Occupancy-Grid des Lidars und Hindernisliste ergibt sich dann, ob ein Feld belegt ist.
    - Die Abmessungen des Roboters und die Auflösung des Grids bestimmen, ob Felder in der Nachbarschaft eines belegten Feldes befahrbar sind. Ein Roboter mit 30cm Umfang stößt bereits auf dem Nachbarfeld eines als belegt markierten Feldes an das Hindernis an. Also muss man im Pathfinder auch diese Nachbarfelder ausschließen. Das kann man tun, indem man in einem neuen Grid (NavigationGrid) einfach die Hindernisse entsprechend der Abmessungen des Roboters vergrößert und im Pathfinder die Position des Roboters weiterhin als Punkt betrachtet.

    Zusammen braucht man so LidarGrid, Hindernisliste und NavigationGrid. Zusätzlich braucht man noch einmal Speicher in der Größenordnung des NavigationGrid für den Pathfinder.
    Ob das Raster so passt, erfährt man erst, wenn man in der Wohnung die schmalsten Wege (zwischen Sofa und Tisch?) sucht. Es ist zwar naheliegend, einen 30cm-Robbi auf einer 30x30cm aufgelösten Karte fahren zu lassen, aber 30cm Auflösung heißt auch nur, dass auf einer Kachel von 30x30cm irgendwo ein Hindernis liegt- vielleicht liegt es am Rand. Dann ist das Befahren des Nachbarfeldes in der Diagonale schon nicht mehr möglich.

    Tröstlich: mit einem persistenten Speicher (SD-Karte,...) benötigt man weniger RAM. Änderungen in Lidar- und NavigationGrid könnnen nur in Sensorreichweite auftreten. Außerhalb der Reichweite liegende Kartenteile können also weggespeichert und bei Bedarf wieder hervorgeholt werden. Beim Pathfinder allerdings spart man ohne Vorberechnungen nix (der braucht zur Berechnung eines Pfades die gesamte Karte).

    Fazit: Das klingt nicht nach einer Aufgabe für einen Microcontroller (die Funktion des "Stitch-Assistenten" habe ich noch gar nicht aufgezählt), zumal man beim Entwickeln ohne die grafische Darstellung kaum die Arbeit des SLAMs verifizieren kann. Die ganze Sache vielleicht noch per Wifi ins lokale Netz bringen zu wollen, macht es nicht unbedingt einfacher oder kleiner. Die Hardware über Bluetooth anzubinden erlaubt erst einmal den Start auf dem größtmöglichen Brain (das Entwickeln am PC). Herunterstrippen kann man später immer noch.
    Geändert von Holomino (03.12.2020 um 16:27 Uhr)

  7. #77
    Erfahrener Benutzer Robotik Einstein Avatar von Moppi
    Registriert seit
    18.03.2018
    Beiträge
    2.387
    Blog-Einträge
    25
    Hallo,

    ich habe gerade etwas Zeit, heute den ganzen Tag Fehlersuche.
    Also für mich ist das zu weit weg, was Du vor hast, bzw. die Gedanken, die Du hegst. Mir würde zuerst mal ein Chassis fehlen, das auch fährt und lädt, bevor ich mich der komplizierten Steuerung mittels Laserscanner usw. widme. Da ich mich mit Lidar noch nicht wirklich beschäftigt habe, kann ich das zwar lesen und verstehen, was Du schreibst, aber mehr erst einmal nicht. Warum man unbedingt jetzt schon Wege auf einer Karte finden können soll, sehe ich auch nicht so ein. Zuerst wäre mal schön, wenn Hindernissen ausgewichen werden kann, würde ich denken. Vermutlich haben wir verschiedene Denk-/Lösungsansätze. Hier steht jetzt Lidar im Vordergrund, und nur das. Das entspricht der Lösung, wie bekomme ich möglichst viele Daten von meiner Umgebung, aus der ich eine Karte erstelle und dann versuche ich mich in Echtzeit durch die riesige Datenmenge zu bewegen, ohne irgendwo anzuecken, immer ein Ziel im Focus. Das kann man auch mit Kameras fortsetzen, womöglich mit mehreren auf einmal, damit man ein möglichst umfangreiches Umgebungsbild erhält, aus dem sich Entfernungsangaben berechnen lassen. Mir ist jetzt auch nicht ganz klar, ob hier ein autonomer, unabhängiger Roboter im Vordergrund steht. Aber ich denke eher nicht. Muss ja auch nicht. Asimo ist es offenbar auch nicht. Und in der Tat wird man dafür nicht nur viel Strom benötigen, sondern auch eine schnelle CPU, am besten mit mehreren Kernen. Ich würde denken, so vier Kerne sollten es schon sein dann. Zwei wäre evtl. etwas zu wenig. Ich kenne mich bei Lidar mit den Datenmengen zu wenig aus, die verarbeitet werden müssen, das betrifft auch die Kartengröße, die dann immer wieder durchkämmt werden und aktualisiert werden muss. Daher hätte ich jetzt gesagt, besser wäre vielleicht eine SSD-Festplatte, statt einer SD-Karte. Aber gut, so langsam sind SD-Karten jetzt auch nicht, vielleicht genügen die gerade noch; da kommt es ja auch auf das System an, das die Daten ausliest.

    Das waren erst mal so meine Gedanken dazu. Vielleicht finden sich noch andere Meinungen.


    MfG

  8. #78
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    736
    Zitat Zitat von Moppi Beitrag anzeigen
    Mir ist jetzt auch nicht ganz klar, ob hier ein autonomer, unabhängiger Roboter im Vordergrund steht.
    Zitat Zitat von Holomino Beitrag anzeigen
    Hier soll es um den modularen Aufbau mobiler autonomer Roboter gehen. Vor dem Hintergrund, dass solche Systeme mittlerweile z.B. auch als Staubsauger systematisch unsere Wohnung abgrasen und damit technisch offensichtlich für wenig Geld machbar sind, ist die Frage: Was steckt drin? Wie spielt es zusammen? Was muss ich tun, um Ähnliches zu erreichen?
    (Aus meinem Eingangspost)

    Sieh es so: Die letzten 8 Seiten listen ganz grob eine Bastler-Minimalkonfiguration für diese Aufgabe auf.
    Das ist schon eine Menge Holz. Eigentlich warte ich die ganze Zeit mit Spannung darauf, dass jemand sagt: Es geht doch viel einfacher.
    Tut es das?

  9. #79
    Erfahrener Benutzer Robotik Einstein Avatar von inka
    Registriert seit
    29.10.2006
    Ort
    nahe Dresden
    Alter
    73
    Beiträge
    1.965
    Zitat Zitat von Holomino Beitrag anzeigen
    Es geht doch viel einfacher. Tut es das?
    ohne jetzt Deine ausführungen in frage stellen zu wollen, bin ich der meinung, dass es tatsächlich einfacher geht:

    Ich stelle für meine roboter erstmal nicht die forderung auf, dass sie in der lage sein müssen eine karte der umgebung zu erstellen. Trotzdem können sie sich autonom bewegen. Mir reicht es schon, wenn sie durch den raum fahren können ohne anzustossen und bevor der saft zu ende ist in der lage sind eine ladestation zu finden. Und dazu reicht ein atmega 2560, ein US-modul ein bischen odometrie und ein linienfolgemodul...
    Der antrieb spielt dabei erstmal eine untergeornete rolle, egal ob schrittmotoren, DC-motoren, mit ketten, normalen rädern oder omniwheels...

    Auch ist es mit diesen wenigen mitteln möglich den roboter auf den weg zu schicken damit er mit einem separaten videomodul aufnahmen macht, die man sich dann "zuhause" in aller ruhe anschauen kann. Ich denke ich bin da ganz in Moppi's nähe...
    gruß inka

  10. #80
    Erfahrener Benutzer Fleißiges Mitglied Avatar von Defiant
    Registriert seit
    17.04.2005
    Ort
    Hamburg
    Beiträge
    161
    Zitat Zitat von inka Beitrag anzeigen
    Ich stelle für meine roboter erstmal nicht die forderung auf, dass sie in der lage sein müssen eine karte der umgebung zu erstellen. Trotzdem können sie sich autonom bewegen.
    Wie soll das gehen? Versuchst du ohne Karte von Ost-Frankfurt in eine bestimmte Straße in West-Frankfurt zu fahren?

Seite 8 von 11 ErsteErste ... 678910 ... LetzteLetzte

Ähnliche Themen

  1. Roccat Nyth im Test: Die 130-Euro-Modular-Daumentasten-Gaming-Maus
    Von Roboternetz-News im Forum Neuigkeiten / Technik-News / Nachrichten / Aktuelles
    Antworten: 0
    Letzter Beitrag: 01.10.2015, 10:10
  2. ROV-CONTROL - a modular control system for diving robots
    Von Diron im Forum Sonstige Roboter- und artverwandte Modelle
    Antworten: 0
    Letzter Beitrag: 03.02.2015, 23:58
  3. Atmel Studio modular Programmieren
    Von Che Guevara im Forum C - Programmierung (GCC u.a.)
    Antworten: 4
    Letzter Beitrag: 12.06.2014, 00:48
  4. Kennt ihr MTRAN3 Modular Robot?
    Von Sergetg im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 0
    Letzter Beitrag: 09.11.2009, 15:46
  5. Modular, shape-shifting robots
    Von johns im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 3
    Letzter Beitrag: 01.05.2008, 10:40

Berechtigungen

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