XPlorer 2

[Rabenauge]

Die Sensorbrille ist ein einfaches Druckteil, wo der halt vorne raus sieht, und von hinten angeschaubt wird.
Die wird dann einfach ins Gehäuse geklickt, und ist dadurch auch in Grenzen im Winkel verstellbar.
Das hab ich bewusst so gemacht, um nicht jedem Krempel, der auf dem Boden rum liegt, zu erfassen.
Ich häng mal nen Screenshot von Blender an, da hab ich sie doppelt platziert, so dass man sie von vorne und von hinten sieht (das untere ist die Seite, wo der Sensor rangeschraubt wird).
Die berührt den Sensor auch nur an seiner Platine (muss ja, irgendwie muss man ihn ja montieren), nicht jedoch an den Schallkapseln.



Und ja: eigentlich braucht man etliche solche Sensoren, wenn man eine halbwegs (richtig gut geht es mit US alleine _gar nicht_) gute Hinderniserkennung realisieren will denn: die funktionieren nur unter Laborbedingungen recht gut.
Die erkennen aber eine Wand _nicht_, wenn du im spitzen Winkel drauf zu fährst- dann wird nämlich der Schall vom Sensor weg reflektiert.
Deswegen melden die, wenn sie nach vorne schauen, auch den Boden eben nicht als Hindernis.
Den erkennen die einfach nicht....
Bessere Resultate liefert so ein Ding, wenn man es bewegen kann (per Servo z.B.), aber das wollte ich wiederum nicht, weil ich beim XP2 Wert auf Robustheit lege.

Du hast schon ganz recht mit dem drehen: kann man so machen, aber:
Der XP2 soll ja später ferngesteuert werden. Also durchaus auch ausserhalb meiner Sicht- und da will ich halt wenigstens grob wissen, was hinter dem Roboter los ist.
Und nach vorne macht das halt auch Sinn, so lange die IR-Cut-Kamera noch nicht drauf ist.
Ausserdem: wie du schon sagtest..die Dinger kosten ja nix. Genug freie Pins hat der Nano auch (seit dem Umbau sogar noch zwei mehr, da der neue Motortreiber bloss vier Leitungen braucht, während der alte sechs hatte), warum also nicht.

[inka]

Die Sensorbrille ist ein einfaches Druckteil, wo der halt vorne raus sieht, und von hinten angeschaubt wird.
Die wird dann einfach ins Gehäuse geklickt, und ist dadurch auch in Grenzen im Winkel verstellbar.
Das hab ich bewusst so gemacht, um nicht jedem Krempel, der auf dem Boden rum liegt, zu erfassen.
Ich häng mal nen Screenshot von Blender an, da hab ich sie doppelt platziert, so dass man sie von vorne und von hinten sieht (das untere ist die Seite, wo der Sensor rangeschraubt wird).
Die berührt den Sensor auch nur an seiner Platine (muss ja, irgendwie muss man ihn ja montieren), nicht jedoch an den Schallkapseln.

sieht schon gut aus, richtige details erkennen kann ich da allerdings nicht - da sind so seltsamme dallen an den öffnungen für die schallkapseln, wozu sind die denn? Wäre es möglich eine *.stl oder *.obj datei anzuschauen?

[Rabenauge]

Der braucht Aussparungen auf der Rückseite, weil da auf den Platinen noch ein Quarz oder sowas sitzt.
Anders kann man die Platine nich vernünftig verschrauben- ich häng das Teil mal an.
Passt übrigens für die 04er und auch die 05er (mein 05er hat aber nur zwei Befestigungsbohrungen, in die anderen beiden Löcher hab ich halt Dummy-Schrauben geklebt).

[inka]

ein schönes teil
auch die flächenübergänge an der aussenfläche, gefält mir....
Ich nehme an, das in der STL datei entspricht der einbaulage. Druckst du das auch so? Mit oder ohne stützstrukturen?

[Rabenauge]

Hm-weiss ich nicht mehr genau, wie ich den gedruckt hatte.
Aus dem Bauch raus würd ich sagen: auf der Innenseite liegend- dann braucht es ein bisschen Stütze, aber nich viel.
Als noch noch Cura benutzt hab (bis vor ner Woche etwa...) hatte ich dieses Auto-Orientation-Plugin drin, das kann die beste Lage zum Drucken ziemlich gut ausknobeln.
Allerdings kann mich Cura, bis auf weiteres, erstmal....

Ich drucke bei solchen Teilen meistens "auf Sicht"- Stützstrukturen sind mir, in gewissen Grenzen, Wurst (so viel kostet das bisschen Zeugs auch wieder nicht), daher achte ich lieber drauf, dass die später sichtbaren Flächen ordentlich aussehen werden nach dem Druck.
Bei den Lampengläsern war das ne ziemliche Herausforderung, weil ich den Fresnel-Linsen-Effekt (der sich bei höherer Schichtdicke und klarem Material sowieso ergibt) unbedingt in der passenden Richtung haben wollte.

Insgesamt aber hab ich beim XPlorer schon darauf geachtet, die Teile gleich so zu zeichnen, dass man möglichst wenige Stützen braucht.
Aber eben: bei so Kleinteilen....*pffff

Ja- die *-stl ist Einbaulage- ich dreh die in Blender immer so, so hab ich im 3D-Programm alles da, wo es hingehört.
Dadurch hab ich den XPlorer, komplett montiert, im Programm, und sehe recht gut, wo was passen wird- oder wo nicht.
Durch die feine Ebenen-Organisation kann man das ja alles fix ein- oder ausblenden.

[Rabenauge]

Nach einigem Hin-und Herüberlegen bin ich zu nem Entschluss gekommen:

Ich werde mir als nächstes (nebenbei zeichne ich trotzdem weiter Druckteile, immerhin fehlt oben noch einiges) eine Fernsteuerung bauen.
Später soll er ja, via RaspberryZero, sowieso ferngesteuert werden, aber ich mach mir da nichts vor: vom Pi hab ich noch zu wenig Ahnung, das wird sich ziehen....ich will ihn aber endlich mal ordentlich probefahren.
Autonom, draussen, mit zwei lausigen (und zudem fest montieren) Ultraschallsensoren wird das nix- das war von Anfang an klar.

Aber wenn ich mir schon eine baue, dann leg ich die gleich so aus, dass sie auch später für andere Roboter verwendet werden kann.
Die Funkstrecke soll per Bluetooth gemacht werden- zwei HC 05 (ich seh keinen Grund, als Empfänger nen 06er einzusetzen, nennenswert billiger sind die auch nich, können aber halt weniger) sind schon da. Die werd ich die Tage mal bespielen....

Aktuell hab ich im "Schaltplan" zwei analoge Joysticks drin (die ich vorerst nicht beide brauche, aber wennschon, will ich die auch später verwenden können), einen Drehencoder, und im Moment drei Taster (solche wie im Bild werd ich natürlich nicht verwenden, da kommt was anständiges rein).
Einige Pins sind noch frei....
Display ein 128x64 LCD (nen blaues, nicht, weil das nun das beste ist was man kriegen könnte, sondern weil ich diesen Retrolook einfach gut finde), das ermöglicht auch einige Telemetrie.
Stromversorgung wird ziemlich sicher eine simple Powerbank (womit wir schonmal 5V haben), allzu gross muss die bei Bluetooth gar nicht sein....möglicherweise brauche ich da noch nen Lastwiderstand, aber ich denke, das Display wird genug Strom ziehen.

Rechner wollte ich zuerst einen Arduino Pro Mini (5V) nehmen, hab das aber verworfen- momentan tendiere ich, wie im XP2, zum Nano.
Immernoch hübsch klein, aber der lässt sich im Gehäuse so einbauen, dass man von aussen an den USB-Port kommt.
Das ist einfach noch praktischer, und kostet auch kaum mehr...

Einer der beiden Joystick-Buttons liegt auf nem Interruptfähigen Pin, so könnte man den z.B. als Notaus verwenden (was bei einer Funkstrecke mit Bluetooth nur in Grenzen Sinn macht), und einer der beiden Ausgänge des Drehencoders auch....damit der ordentlich funktioniert.

Am liebsten hätte ich nen dreiachsigen Joystick (so ein Ding hab ich hier rumliegen, der steckt noch in ner alten Kamerasteuerung von Philips) benutzt-wenn das Ding nicht so monströs wäre. So ist das Display das Grösste an der Sache- und wenn ich nicht unbedingt _so eins_ wollte, würde ein winziges OLED (die 0.9"-Dinger haben genau die selbe Auflösung) den gleichen Zweck erfüllen-I2C wäre frei, man würde also sogar noch einige Pins mehr gewinnen. Und ablesbar sind die kleinen OLED auch draussen mindestens genauso gut.
Mit dem winzigen Display könnte man das Teil in Gamecontroller-Grösse bauen....aber ich _will_ das Grosse.
Ausschalter verbaue ich keinen-die eine der Powerbänke, die in Frage käme, hat nen Button zum abschalten, die kleineren haben nix-die zieh ich halt einfach raus.
Den Anschluss kann ich, wie bei meinem Lightpainting-Tool mit nem Stück, ins Gehäuse eingeschmiedeten USB-Kabel machen.

Was haltet ihr von dem Entwurf- besonders unter Berücksichtigung der Tatsache, dass diese Fernsteuerung möglichst universell sein soll?

[Defiant]

Wegen der Fernsteuerung: Das du mit relativ wenig Aufwand einen gekauften Game-Controller per Bluetooth an einen rpi anbinden kannst, ist dir bewusst? Du könntest vor allem das Nebenprojekt Fernsteuerung vermeiden und dich auf dem Roboter an sich konzentrieren.

[Klebwax]

Was haltet ihr von dem Entwurf- besonders unter Berücksichtigung der Tatsache, dass diese Fernsteuerung möglichst universell sein soll?

Ich beschreibe mal, was ich mir ausgedacht und zum Teil auch schon realisiert habe.

Als Funk benutze ich Wlan. Für die vielen bei mir vorhandenen Geräte ist es sowieso da. Sollte es im Freien nicht jeden Punkt erreichen, rüste ich mit einem Outdoor-AP zur Not nach.

Der Anschluß an mein LAN ermöglicht es, daß jeder Rechner mit dem mobilen Teil über das gleiche Medium kommunizieren kann. Das war für mich eine wichtige Überlegung. Die Protokolle sind zwar komplex, sie sind aber vorhanden und ich muß mich nicht wirklich darum kümmern. Auf einem Rechner habe ich Sockets, die kann ich aus C, Javascript, Python oder eigentlich jeder Sprache direkt ansprechen. Und sollte ich da mal Probleme haben, stehen bei mir ein halbes Dutzend Bücher im Regal. Praktisch ist das möglich geworden, seit es die ESP preiswert gibt. Auch dort muß ich mich nicht um die Komplexität von (W)Lan kümmern. Ich kann dort auf das bekannten Konzept der Sockets aufsetzen.

Was bietet das für Vorteile? Eine (W)Lan-Verbindung bietet prinzipiell die Möglichkeit, mehrere Kommunikationskanäle gleichzeitig und in jeder Richtung zu nutzen. Über den einen Socket kann ich Fernsteuerkommandos schicken, währen über einen anderen Socket z.B. Telemetriedaten an einen Server in meinem Netz gehen. Und der Programmieraufwand hält sich in Grenzen, einen Socket auszulesen und die Daten in einem für Gnuplot oder Excel passenden Format in eine Datei zu schreiben ist in wenigen Zeilen gescriptet.

Jeder Rechner kann die Funktion des "Fersteuersenders" übernehmen, interaktiv oder als Programm. So lässt sich eine automatische Steuerung realisieren. Zusammen mit der Möglichkeit des Rückkanals kann sie auch intelligent sein. Es kann während der Entwicklung auch die größere Rechenleistung eines PCs genutzt werden.

Nun fehlt nur noch ein "richtiger" Sender. Ich hab mir einen gebastelt.



Das ist ein ESP mit einem Akku und einem Nunchuk als Steuerknüppel. Ich hab mal an anderer Stelle einen meiner Prototypen gezeigt. Für die ersten Versuche hab ich dort den Nunchuk direkt angeschlossen, später kamen die Nunchukdaten über Wlan. Die nächste Platine des Senders wird dann in ein Gehäuse passen.

Wie ist das mit dem ESP realisiert? Im Prinzip kann man die SW, die von Hause drauf ist, verwenden. Die ganze Wlan Angelegenheit kann man, wie bei einem klassischen Modem, über AT-Kommandos auf der seriellen steuern. Ich bin kein großer Fan der AT-Schnittstelle. Ich habe daher eine Art allgemeines Wlan-Modem auf der lua-Firmware für den ESP programmiert. Die Kommunikation läuft dort bidirektional, die Parameter wie die IP-Adresse werden über die gleiche serielle eingestellt. So kommt es als Empfänger zum Einsatz. Für einen Sender, der keinen eigenen µC hat, kommt dann noch I2C für den Nunchuk dazu. Für aufwändigere Sendern, den Umbau eines alten RC-Senders z.B., kann man die die gleiche Firmware wie im Empfänger verwenden und einem µC die Arbeit überlassen.

Soweit mein Konzept. Die ESP sind so billig, billiger als eine RJ45 Buchse mit eingebautem Trafo, daß ich auch eigentlich stationäre Steuerung wie Rollläden so ansteuere. Die Firmware auf dem ESP bleibt (im Wesentlichen) immer die Gleiche. Sie passt auch in den Flash eines ESP-01. Wenn ich auf einer µC-Schaltung, die ich baue den Platz für die 8-Polige Stiftleiste übrig und einen UART frei habe, layoute ich das mit rein. Später fällt einem möglicherweise eine Anwendung dazu ein oder man bestückt es nicht.

MfG Klebwax

P.S.

Wie ich grad sehe, hast du ähnliche Überlegungen angestellt.