-         
Seite 8 von 8 ErsteErste ... 678
Ergebnis 71 bis 76 von 76

Thema: Think Modular

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

    Praxistest und DIY Projekte
    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
    704
    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
    704
    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
    150
    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
    704
    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
    704
    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)

Seite 8 von 8 ErsteErste ... 678

Ä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
  •