Zitat von Moppi
(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?
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
Wie soll das gehen? Versuchst du ohne Karte von Ost-Frankfurt in eine bestimmte Straße in West-Frankfurt zu fahren?
nein, er fährt von einem bestimmten punkt in der wohnung in der strasse in der ich wohne und orientiert sich anhand empfangener signale der ladestation. Fährt los, sucht die station, ladet, wenn nötig und fährt einfach im raum weiter....
Ich schätze wir reden hier in verschiedenen sphären, Ihr seid schon in Frankfurt, ich in meiner wohnung...
gruß inka
Dann lass mich das umformulieren. Ich dachte in Deutschland kommen Autovergleiche gut an, hab mich wohl geirrt. Beispiel:
- Deine Ladestation steht im Wohnzimmer
- Dein Roboter ist im Wohnzimmer
- Dazwischen ist Sofa, der direkte Weg der Signale der Ladestation sind deswegen geblockt.
Frage: Wie findet dein Roboter die Ladestation?
im auto nutzt man einen navi
ich habe zwei baken. Eine direkt an der ladestation, eine zweite an einer anderen (zur ersten wand 90° versetzt) wand, die funkt in einer anderen frequenz.
Nur zum verständnis: das ganze liegt jetzt ca. 5 jahre zurück. Ich habe mich damals, beim RP6, mit dem thema baken etwas intensiver auseinander gesetzt. Die sind inzwischen eingemottet, bin inzwischen umgezogen, also weiss ich nur, dass es damals ging, kann es jetzt aber nicht wiederholen...
gruß inka
eine andere möglichkeit gibt es noch (erlebt beim staubsaugerroboter) :
- "sorry- ich weiss nicht wo ich bin"... oder - häufiger
- "kann leider die ladestation nicht finden, bitte stellen Sie den roboter an einen anderen ort und versuchen Sie es erneut"...
da ist es mit den zwei baken doch noch komfortabler - und autonomer...
gruß inka
Na, "irgendwann" wird man da wohl auch ankommen. Ob man es dann merkt, ist eine andere Frage.
Ich bin mir nicht sicher, was Du genau damit meinst. Aber da ich zu 286er- und 386er - Zeiten ein Buch gekauft hatte (PC-Underground), bin ich davon überzeugt, dass vieles einfacher geht. Bei dem Buch waren Beispiele, von Assemblerprogrammen dabei. Fertige. Also das waren Demos, wo jeder Programmierer (oft auch mehrere zusammen) ihr Können presentiert haben (da gab es so Wettbewerbe oder so was .. irgendwo). Das konnte man nicht nur anschauen, sondern das war echt der Hammer! Man kennt ja noch die Speicherausstattung der damaligen Rechner und die langsamen Grafikkarten. Aber die Demos waren allesamt flüssig am Laufen. Am meisten hat mich eine Sphäre beindruckt, die sich über den Bildschirm bewegte und wo ein Spiegelbild drauf zu sehen ist (auch etwas komplizierter - sowas wie ein Gesicht etwa). Ohne Koprozessor, mit den mickrigen Rechenleistungen und in Farbe natürlich. Meist war sogar noch Musik drunter gelegt. Ich glaube ich hatte eine SB 2.0 (war ja damals Standard). Von so was gab es ein paar Demos. Und im Buch wurden Techniken erklärt, wie man 3D-Berechnungen anstellt auch mit nur maximal 16Bit-Operationen. Also Punkte im Raum berechnen, die mit Lininen verbinden, wie man Bilder in die Perspektive skaliert und die dann auf berechnete Flächen setzt. Seit dem ich das Buch gelesen habe, weiß ich, dass sehr viele Sachen oft ganz einfach zu lösen sind, man muss nur wissen wie. Das fängt dann eben vor allem damit auch an, dass man sich wirklich überlegt, wie viel Bit benötige ich, um einen bestimmten Wert / Größe zu speichern. Oft tun es auch nur halb so viele Bits, wenn man genau drüber nachdenkt, welchen Maximalwert man abbilden will und welche Auflösung man aus praktischer Sicht dafür benötigt. Alles in allem betrachtet, kann ich mir daher vorstellen, dass man auch mit einem nodeMCU 1.0 genügend Rechenleistung und Speicher hätte, um Lidar-Daten auszuwerten und in einer Karte zu speichern. Nur der Flash vom nodeMCU 1.0 ist nicht so brauchbar, da gibt es ein paar Tücken. Kann man aber durch eine SD-Karte ersetzen. Aber so weit bin ich jetzt noch nicht.
Diese Denkweise drängte sich mir auch auf, als ich das alles so las. Ich denke, genau darum soll es sich drehen: um autonomes Fahren eines Fahrzeugs (Tesla). Dass das autonome Fahren im Vordergrund steht, inkl. Wegfindung (Navigatonssysteme). Das kann man natürlich auch auf eine Wohnung skalieren. Aber ob es sinnvoll ist? Dafür muss man feststellen, welchen Zweck man verfolgt. Und welche Hardware man einsetzen möchte oder könnte. Ehrlich gesagt, bin ich aber dafür noch kein guter Gesprächspartner, weil ich mich zu wenig bis gar nicht mit diesen Themen beschäftigt habe (bis jetzt). Im Moment reize ich gerade den Speicher eines ATmega328P aus. Und da komme ich jetzt an Grenzen (gebe mir dennoch Mühe, dass das funktionieren kann).
Ich bin noch weit entfernt von dem, was hier so angedacht ist. Bin aber auch nicht so der Freund davon, nur weil es viel einfacher ist, üppige Hardware und überdimensionierte Programme für einfache Lösungen einzusetzen, die man vielleicht normal mindestens mit einem ESP32 hinbekommt. Nur müsste man dann ggf. selbst mehr programmieren, was mehr Zeit in Anspruch nimmt und man muss dann auch wissen, wie man das programmieren kann. Ich glaube, an letzterem mangelt es oft, weil dazu gehört einfach Übung, Übung und nochmals Übung; so dass man alles irgendwann irgendwo schon mal gemacht hat: Bilder auf ner GRafikkarte ausgeben (VESA Standard, weil es etwas einfacher ist), Animationen ablaufen lassen, auch direkte Programmierung der Grafikkarte, Sound direkt ausgeben (Soundblaster, weil alles gut dokumentiert ist), im nächsten Schritt lernen, wie man Linien zeichnet, um Fenster und Buttons darzustellen, lernen, was Memory Mapping in dem Zusammenhang bedeutet, erste Grafische Oberflächen selbst programmieren (sozusagen Pixel für Pixel), Mausabfragen durchführen (Maustreiber macht es einfacher, ohne geht auch), lernen, wie man direkt eine Tastatur programmiert und abfragt (Protokoll .... Register), vielleicht irgendwann auf Festplattenkrontroller zugreifen um die Festplatte zu schreiben und zu lesen (ROM-Bios macht es hier etwas einfacher) usw. Beispielhaft jetzt für die x86ger gesprochen, aber bei den µCs und Verwandten sieht es ähnlich aus. Kurz, ich beschäftige mich gerne mit der Materie im Detail selbst, damit ich weiß, warum was und wie genau funktioniert. Dann bekommt man vieles auch auf schmaler Hardware zum laufen. Hier gibt es schon eine Überleitung. Weil mir war noch was zu dem späteren "herunterstrippen" eingefallen: ich denke dieser Ansatz sitzt am falschen Ende. Wer will denn bitte etwas auf kleineres System umschreiben, was vielleicht mit Fremdsoftware auf einem größeren Computer läuft? Da wird sich dann niemand finden. Einfacher ist es, wenn man klein angefangen hat, auf schmaler Hardware, Sachen auf einen größeren Rechner zum Laufen zu bringen (da sind dann die Programmiersprachen mächtiger und einfacher und die Dinge lassen sich leicht nachbauen). So etwa nach dem Motto: größer geht immer, kleiner fast nimmer. Aber ich wollte eigentlich auch nicht so weit ausholen. Nur noch eins zum Schluss: manche Sachen werden sich sicher nicht ohne mächtigere Hardware machen lassen.
Gruß
Das ist Schade. Kannst Du denn hier etwas mehr über die Technik (Funk/IR, Frequenz, Reichweite, Peilwinkelgenauigkeit) erläutern?
Ich kann es nur aus meiner Sichtweise erläutern: Nachdem ich im Simulator eine befriedigende Lösung gefunden hatte, habe ich mir überhaupt erst die Mühe gemacht, eine Hardware dafür zu finden.
Selbst mit dieser Vorgehensweise liegen noch viele Irrwege und produzierter Schrott bis zum ultimativen Gerät vor Dir, das alle Fallstricke Deiner Wohnung oder Deines Gartens umschifft.
Unter dem modularen Aspekt spricht auch nichts dagegen, sich zuerst ein Fahrgestell mit einfachen Hindernisdetektoren zu bauen oder zu kaufen und es auf Herz und Nieren in der eigenen Umgebung per zufälliger Fahrt zu testen. Spätestens wenn man Odometrie anbaut und aufzeichnet, wird einem sowieso klar, wie unperfekt dieses System ohne Bezugspunkte zur Umgebung ist (einfach, weil sich Fehler während der Fahrt ohne Korrektur beliebig fortpflanzen).
Dann wird es Zeit, sich um die Anbindung der Umgebung zu kümmern. Neben den raster- oder vektororientierten 2- oder 3D-Karten gibt es sicherlich auch andere (featureorientierte) Lösungsansätze. Allerdings glaube ich nicht, dass ein Featureknotennetz bezüglich Sensorik, Parametrierung und Verifikation aus menschlicher Sicht einfacher zu behandeln ist. Auf eine Karte guckst Du nach Deiner Position und Du weißt, wo Du bist. Letztlich ist aus Sicht des Slams die Rasterkarte ein Abfallprodukt, das man als Mensch zufällig gut versteht. Man kann damit arbeiten, Dinge untersuchen (z.B. mal über die Wohnung ein Temperaturprofil oder die WLAN-Abdeckung aufzeichnen) oder auch etwas bedienen (der sophisticated Wecker, der morgens ins Kinderzimmer fährt und die Blagen solange mit pädagogischen Sprüchen vollquäkt, bis sie endlich aus den Betten hoppeln).
Also: Standortbestimmung und Zielpunktvorgabe in lesbarer Form sollte es schon sein.
Berechtigungen
Zitieren
Lesezeichen