360° Sensor Netz

[nick-d-n]

Hallo ich bin noch neu in dem Thema,

und meinen Roboter hab ich noch nicht mal zu laufen gebracht, weil noch immer die Batterien fehlen.
Aber ich mach mir schon so meine Gedanken wie es weiter gehen soll, wenn die ersten Fahrtest geschafft sind.

Mein Roboter kann wegen den "Mecanum Wheels" Rädern ohne Wendung seine Fahrrichtungen jeder Zeit ändern. Also Fahrrichtung in X und Y Achse.

Ich will eigentlich dass der Roboter irgend wann mal Autonom fahren kann.
Dafür brauch ich ein Sensornetzwerk das nach Möglichkeit alle Hindernisse (360° Rundum) um dem Fahrzeug erkennt.

Ich hab mir schon ein paar Gedanke gemacht.
Wenn ich 4 Sensoren im 45° Winkel schräg vor die Räder, auf den Boden richte. (Rot auf dem Bild)
Dann kann ich die meisten Hindernisse Vor- und Neben den Rädern erkenne.
Sogar Stufen könne ich erkennen und damit verhindern dass der Roboter eine Treppe runter stürzt.

Als Fern-Sensoren würde ich,
in Hauptfahrrichtung zwei Sensoren (Rechts/Links) aufbauen
und noch mal je einen Sensor für Rechts / Links und Hinten. (Grün auf dem Bild)

Bild hier  

Was meint ihr?

Ultraschall Sensoren liefern mir einen Analogen Wert als Abstand, was gut für die Fernsensoren ist.


Für den Nahbereich (also direkt vor den Rädern) würde mir eigentlich Binär reichten, aber ich brauch zwei Arbeitspunkte für die Sensoren (Zu-Tief oder Zu-Hoch um weiter zu fahren)
Also entweder Infrarot oder auch wieder Ultraschall also Messmethode.

Was meint ihr geht das mit so vielen Ultraschall Sensoren?
Was sollte ich beachten?
Und wie lese ich am besten so viele Analogwerte ein?
Gibt es eine Möglichkeit die Sensoren über einen Bus ein zu lesen? z.B. I2C ???

gruß Dirk

[oberallgeier]

Halo Dirk!

.. Was meint ihr geht das mit so vielen Ultraschall Sensoren? .. Was sollte ich beachten? .. Dirk

Na gehen tut das sicher.

Mit Ultraschallsensoren alleine würde ich das nicht machen. Die muss man, wenn man sicher detektieren will, "alleine" - einzeln, nacheinander - benutzen um Störungen von Echos benachbarter Sensoren zu verhindern. Da die meist bis zu sechs Meter funktionieren braucht man - neben der Verarbeitungszeit - ne Laufzeit von 2x6m zwischen einzelnen Messungen. Schall läuft, grob gerechnet, über 12 m Distanz rund 0,04 sec. Mehr z.B. hier. Mit Vorsicht betrachtet also weniger als 20 Messungen pro Sekunde.

Die Charakteristik der US-Sensoren ist zu beachten. Bestenfalls hat man ne Keule von ca. ± 30° bei kürzeren Entfernungen, wenns über einen Meter oder so rausgehen soll, wird man vorsichtig mit ± 15°/20° rechnen. Auf Grundlage ± 20° braucht mal also bis zu neun US-Sensoren für Rundumblick. Nach Milchmädchenrechnung also 20 Messungen pro Sekunde für zehn Sensoren macht zwei Messungen pro Sekunde. Dann fährt der Bot mit 2 m/s bereits im kritischen Bereich (alles mit wenig Sicherheitsreserve/n). Natürlich wird man für Deine Omniweel-Ausrüstung softwaremässig immer nur die Sensoren in Fahrtrichtung betreiben/ingang setzen . . . (natürlich gilt Messung in Fahrtrichtung bei so ziemlich allen autonomen Varianten *gg*)

Möglicherweise bietet da die alte Lösung von Siro mit Leuchtdioden die besseren Möglichkeiten? Sieht jedenfalls im Video gut aus.

Aber bei geringerer Geschwindigkeit funktionieren viele Bots hier im Forum auch mit weniger Sensoren. Und für den Nahbereich ist die Lösung mit Fühlern wie z.B. beim Nibobee recht praktisch; sieht bei zwei "Fühlern" auch pfiffig aus.

Da man ja, wie oben erwähnt, eher nur in Fahrtrichtung "fühlen" muss, gehts ja z.B. wie bei meinem Dottie oder dem fast baugleichen System im MiniD0.

[Defiant]

Wieso nimmst du keinen Laserscanner, z.B. RPLidar? 5 US-Sensoren sind auch nicht gerade billig und haben das oben beschriebe Problem mit der ungenauen Keule, du siehst dann ein Tischbein, kannst aber nicht genau detektieren wo es ist, also ob links oder rechts mehr Platz ist zum Vorbeifahren.

Die Hauptfrage hier ist wohl, ob du die Datenmengen von einem Laserscanner verarbeiten kannst, was hast du denn für einen Prozessor an Bord?

-

Die SRF10 und SRF08 US-Sensoren können auch I2C.

[nick-d-n]

Hallo, ich danke Euch schon mal für die guten Antworten.
Die Ultraschall Sensoren abhängig von Fahrrichtung und dann Pulsweise Inbetrieb zu nehmen ist eine Idee die ich noch nicht hatte.

Der 2D Laserscanner ist natürlich die Luxus Variante, die mir auch sehr gefällt.

Standardmäßig ist eine Atmel MEGA2560 verbaut, also nicht ganz unfähig das kleine Ding.
Aber ich will abhängig vom Entwicklungsstand gern mehrere µC verbauen.

Einer für die Sensoren,
Einer für die Fahrmodi´s
Einer für die Kartenerstellung,

Falls die Fahrdaten und Karte noch an ein Tablett gesendet werden soll oder,
Falls noch ein ( Fangen / Jagen ) von zwei Roboter statt finden soll,
dann würde ich dies noch mal über einen µC realisieren.


Ihr seht schon Ideen hab ich noch einige (ich will halt gern mich mit dem Roboter aus toben, um mich mal wieder etwas mit Elektronik und Programmierung auseinander zu setzen.


gruß Dirk

[oberallgeier]

Hallo Dirk,

.. Sensoren abhängig von Fahrrichtung .. Idee die ich noch nicht hatte ..

Na schön, vielleicht hilft´s. Und wenns nicht grad für nen Roboterkampf sein soll, dann ist auch kein Angriff(Crash) "von NICHTvorne" zu befürchten.

.. Aber ich will abhängig vom Entwicklungsstand gern mehrere µC verbauen ..

Genau so hab ich es bei meinem archie gemacht. Kopfcontroller (KoCo) im Kopf, Armcontroller (ARCo + ALCo) in den Oberarmen usf. UND ! ! ich hatte schon anfangs ziemlich genau die Topologie des Ganzen geplant und aktuell gehalten. Dann hat man es bei der Kommunikation (manchmal?) etwas leichter. Kommunikation archie-intern eigentlich nur I²C, JEDE Platine mit UART für Testläufe und Information etc. vom Terminal/PC aus, die Zentralplatine zusätzlich mit RC-5 (IR-TV-Steuerung) um verschiedene Tasks starten zu können. Beim archie recht ordentlich den ferngesteuerten Modus beim Fahren mit Befehlen links, rechts, schneller, langsamer, Richtungswechsel, stopp, auch mal halbe und ganze Turns rechts und links rum etc.

Nachträge :
Hier noch die IR-TV-FB mit dem Tastencode

Siehe Angabe im Topo : I²C läuft mit tatsächlichem Clock 600 kHz bzw. TWBR = 8,6667 - theoretisch, tatsächlich 8bittig, also 8 obwohl ich fast zwei Meter Buskabel habe.

[nick-d-n]

Hallo Oberallgeier,

Ja I²C als Bus zwischen den µC schwebt mir auch vor.

Na ja Roboter Kampf klingt so dramatisch, das soll es auch nicht werden.
Aber wenn ich einen Roboter so weit hab, dass er alleine sich im Raum gut und sicher bewegt.
Dann war mein Gedanke halt dass zwei Roboter mit IR Licht Fange oder Versteck spielen.

Auf Bewegliche Hinderniss zu reagieren,
ihnen auszuweichen oder zu flogen halte ich für so anspruchsvoll,
dass ich mich damit die nächsten 10 Jahre sicher austoben kann.

@ Alle
Mein Favorit wäre jetzt ja der 360° Laserscanner und für den Nahbereich (Boden) dann die Ultraschall Sensoren.
Je nachdem wie groß der Kegel ist müssten es vielleicht sogar 2 Sensoren je Rad sein.
IR geht ja wahrscheinlich nicht als Überwachung, da ich ja Löcher und Hindernisse erkennen möchte und das Unabhängig vom Untergrund.

Was ich aber zur Zeit überhaupt nicht einschätzen kann ist der Aufwand für den Laserscanner, ich hab schon etwas im Forum gesucht.
Aber viellleicht könnt ihr mir wenigstens das Prinzip der Auswertung etwas nähr birngen.

Der Scanner misst die Entfernung zum nächstem Hinderniss. Dann dreht er sich weiter und misst wieder.
Und als Daten Output bekommt man den Winkel und die Entfernung?
Wie wird daraus eine Karte?

Bei Binärmeldungen hätte ich gedacht dass man in einem Mehrdimensioales Arrays alle Hindernisse als Bit abspreichern kann.
Aber bei einer rotierenden Messung wäre es für mich zur Zeit noch nicht verständliche wie man die Daten verarbeiten kann.
Vielleicht könnt hier mir das etwas erklären.

gruß Dirk

[Defiant]

Vom Laserscanner bekommst du ein Array der Entfernungen, also Beispiel bei einer Auflösung von 1° bekommst du ein Array mit 360 Float-Werten. Diese Datenmenge mit einem AVR zu verarbeiten wird schon schwierig genug, für die Erstellung von Karten wird üblicherweise ein simultaneous localization and mapping (SLAM)-Algorithmus verwendet, auf einem AVR halte ich das nicht durchführbar.

[HaWe]

ich würde auch allen, die mit mobilen Robots und room mapping per LIDAR etc anfangen, empfehlen, mindestens einen SAM3X8E (Arduino Due), SAMD51 (Adafruit Grand Central) oder ESP32 zu verwenden. Oder einen Rasperry Pi 2B, 3B oder 3B+.

[nick-d-n]

Danke für Eure Tipps,

Ich glaub ich weiß jetzt, wie ich das Thema angehe.

Ich werd wirklich erstmal 4 Ultraschall Messungen für den Nahbereich nehmen.
Und wenn der Roboter dann sicher vor Treppenstufen Hindernissen anhält und umdreht.
Also dann werd ich eine Laserscanner mit einem eigenen µC Nachrüsten.

Ich werd aber kein SLAM Verwenden (also keine Karte erstellen)
sondern nur die Messdaten nutzen um vorrauschauender zu fahren und um die Sensorlücken (in der Horizontalen) zu schließen.
Von dem Array muss ich ja auch nicht alle Daten lesen.
Die 90° die in Fahrtrichtung Messen würden ja reichen.
Nach dem kleinsten Wert suchen und ggf. dann einen Ausweichkurs setzen.

Aber jetzt erstmal den Nahbereich absichern und alles zum laufen bringen.

gruß Dirk

[Moppi]

Hallo!

Ein Gedanke am Rande:

Was können heute Kameras in Sachen Objekterkennung (runde, eckige, evtl. Türrahmen, Pfosten, Farben).
Vielleicht ist es nicht schlecht, auch mal in diese Richtung zu experimentieren, um zu sehen, was sich damit an Erkennung
abdecken ließe. Ergänzen kann man dies mit den üblichen Methoden zur Entfernungsmessung.

MfG