Archiv verlassen und diese Seite im Standarddesign anzeigen : outdoor III
eigentlich wollte ich noch nicht hier starten, aber sonst geht zu viel an info's im arduino thread (https://www.roboternetz.de/community/threads/74136-outdoor-I?p=664738&viewfull=1#post664738) verloren...
das sind so die ersten bilder wo man die grössenordnungen sehen kann:
35515 35516
raddurchmesser 100mm, länge über alles 300mm, gesamtbreite 270mm, höhe 165mm.Im zweiten bild sieht man schon die 12V unterbau-schale, da soll die ganze stromversorgung (12V akku, zwei stepup's für 5V und 3.3V) hin, per stecker verbunden mit der eigentlichen payload im rahmen selbst.
Ob da auch so eine schale hinkommt weiss ich noch nicht, hat vor- aber auch nachteile. Abgedeckt werden soll das ganze mit einem schwenkbaren solarpanel mit den abmessungen von 220x170mm, 14V/5.5W...
--------
@Rabenauge
musste erstmal nachschauen, wie so eine pendelachse aussieht, also "nur" ein mitten-lager ist schon leicht untertrieben, aber man sollte keinen gedanken zur seite schieben, wenn man neu anfängt...
Momentan habe ich sowas (https://youtu.be/NBl9gS4a-us) an radlagerung, ist aber mit einer pendelachse nicht vergleichbar...
Rabenauge
23.05.2021, 11:31
Ok- Missverständnis.
Früher hiessen einfache Achsen, die lediglich in der Mitte um nen Bolzen drehbar waren, so- jedenfalls in der DDR.
Hatte jeder Traktor...die braucht weder Federn noch irgendwelche anderen Führungen, einfach nur in der Mitte ein "Loch längs durch" mit nem Bolzen drin.
Die kann sich dann, in der Fahrzeug-Längsachse, verdrehen, während die starre Hinterachse die Fuhre stützt.
oberallgeier
23.05.2021, 14:05
.. Früher hiessen einfache Achsen, die lediglich in der Mitte um nen Bolzen drehbar waren, so- jedenfalls in der DDR ..Und im Westen hatte Béla Barényi Mitte/Ende 50er die Eingelenk-Pendelachse erfunden (Daimler 180D (https://media.daimler.com/marsMediaSite/de/instance/ko/Die-Highlights-der-E-Klasse-und-ihrer-Vorgaengerbaureihen.xhtml?oid=10855134)) mit nem Gelenk unten am Differential (https://www.google.com/imgres?imgurl=https%3A%2F%2Fmercedes-benz-publicarchive.com%2FmarsClassic%2FThumbnail%3Foid% 3D91574%26version%3D-2%26thumbnailVersion%3D3&imgrefurl=https%3A%2F%2Fmercedes-benz-publicarchive.com%2FmarsClassic%2Fde%2Finstance%2F picture%2FMercedes-Benz-220-Sb--220-SEb.xhtml%3Foid%3D91574&tbnid=Nk2LhS_OEDODNM&vet=10CAMQxiAoAGoXChMI6M2Tj-Hf8AIVAAAAAB0AAAAAEAI..i&docid=9JzK-j7rJ0EmzM&w=700&h=389&itg=1&q=Eingelenk-Pendelachse%20hinten%20mit%20tief%20liegendem%20Dr ehpunkt&client=firefox-b-d&ved=0CAMQxiAoAGoXChMI6M2Tj-Hf8AIVAAAAAB0AAAAAEAI). Barényi selber meinte, das sei die ausgefeilteste Fehlkonstruktion der (damaligen) Autoindustrie: Walken der Räder, Verlust von Bodenfreiheit beim Einfedern . . . Da war die ("Deine") Starrachse an Schwenkzapfen schon freundlicher.
also das mit der kippachse muss noch etwas reifen - vielleicht finde ich etwas fertiges, was als gelenk passen würde...
zunächst mal habe ich mich mit der stromversorgung beschäftigt: 12V akku, motorspannung 12V, zusätzlich 5V, 3.3V, ladebuchse, hauptschalter und steckverbindung zum oberen teil, also der hauptelektronik, mit raspi, sensoren usw...
35517 3551835519
Rabenauge
30.05.2021, 20:48
also das mit der kippachse muss noch etwas reifen - vielleicht finde ich etwas fertiges, was als gelenk passen würde...
Mitm 3D-Drucker doch ganz easy...meiner baut seit Tagen an nem gescheiten (naja...) Tragegestell für den Flieger.
021aet04
30.05.2021, 22:32
Mit einem 3d-Drucker ganz easy, man muss aber einen besitzen.
Wenn du keinen hast, wäre es möglich das dir jemand mit einem Drucker soetwas macht.
Ich hätte einen, warte aber aktuell auf einen Ersatzlüfter (der Alte hat einen Lagerschaden).
Danach wird wieder etwas in mit Carbonfil geruckt (Teile für einen Luftfilter in einem VW Käfer => Umbau Doppelvergaser).
Das muss ich vorher machen, weil der Motor auf einen Prüfstand soll.
Wenn es nicht zu schnell gehen muss, kann ich dir soetwas drucken. Man müsste sich nur ausreden, wer es plant.
MfG Hannes
Rabenauge
30.05.2021, 23:16
Inka hat nen Drucker- daher sagte ich es ja auch....
es gibt eine möglichkeit:
folgender überlegung bin ich gefolgt: ich habe ja keine durchgehende achse, sonder zwei bzw. vier motor-halb-achsen. Und nun möchte ich jede achse auf einem scharnier befestigt rauf und runter pendeln lassen...
35520gibts bei OBI...
und - ja, einen 3d drucker habe ich, allerdings glaube ich nicht, dass man es vernünftig und _pirnaer-kopfstein-pflaster_ gerecht drucken kann. Nicht desto trotz läuft bereits der drucker, es soll ein zweiteiliges scharnier - in einem teil gedruckt - sein. Nur einfach mal ein test...
Rabenauge
31.05.2021, 22:47
Wenn du es so bauen willst, wie ich jetzt denke, dass du es bauen willst, wird das nicht gut funktionieren.
Der Trick einer solchen Achse ist, dass, wenn sich ein Rad wegen ner Unebenheit anhebt, das andere genausoweit absenkt.
Dadurch bleibt die Lastverteilung auf beide Räder gleich, das ist wichtig.
Rauf und runter muss die Achse nicht- sie soll sich gegen die zweite (unbewegliche) verdrehen können.
Genaugenommen heisst es Verschränkung.
Und doch, man kann auch ausreichend stabil für Kopfsteinpflaster drucken, sogar mit relativ wenig Infill: einfach mehrere Wände nehmen.
Damit kriegt man Teile bulletproof, das bringt mehr Stabilität als viel Infill.
Wenn ich was stabiles brauche, drucke ich meist mit drei Wand-Layern, wenns _wirklich_ fest werden muss, vier.
Der Trick einer solchen Achse ist, dass, wenn sich ein Rad wegen ner Unebenheit anhebt, das andere genausoweit absenkt.
Dadurch bleibt die Lastverteilung auf beide Räder gleich, das ist wichtig.
und wenn die unebenheiten nicht auf beiden seiten gleich sind? Dann hängt eine in der luft, wie bei einer starren achse. Warum nicht einzeln kippen? Macht es der thumper nicht auch so?
Und doch, man kann auch ausreichend stabil für Kopfsteinpflaster drucken, sogar mit relativ wenig Infill: einfach mehrere Wände nehmen.
Damit kriegt man Teile bulletproof, das bringt mehr Stabilität als viel Infill.
Wenn ich was stabiles brauche, drucke ich meist mit drei Wand-Layern, wenns _wirklich_ fest werden muss, vier.
meinst du jetzt mehrere modelierte wände als ersatz für ein volumen, oder meinst du wirklich nur die wand-layer?
Rabenauge
01.06.2021, 19:35
Ich meine nur die Wand-Layer.
Standardmässig sind da ja meist zwei eingestellt, was auch reicht für Dinge, die man anfassen kann.
Aber belasten eher nicht....
Klar kann man auch ne Einzelradaufhängung bauen, nur ist die dann deutlich aufwendiger.
Dann _musst_ du nämlich auch Federn haben, die zum einen das Chassis auf den Rädern stützen, als auch die Räder gegen den Boden drücken, mit Gewicht alleine wird das nix.
Die ganzen Probleme hast du bei der Pendelachse, die ich meine, nicht.
Hier siehst du im wesentlichen, was ich meine:
https://www.offroad-forum.de/pserv.php?img=up.picr.de/17720666wl.jpg
Da sind keinerlei Federn oder ähnliches im Spiel.
Da sich beide Achsen ja gegeneinander verschränken können (die eine allein, die andere nimmt halt den Aufbau mit) sind Bodenunebenheiten oder Schlaglöcher kein Problem.
ich drucke mit wandlayer 4 bis 6 teilweise sogar 7 :D für meine modellraketen
nun ja, muss ich ausprobieren. Habt ihr versucht in gedruckte teile gewinde zu schneiden? ich meine die kernbohrung mitdrucken, auch mit 4 layern und dann das gewinde schneiden?
Bei mir klappt es, zumindest teilweise...
Das erste gewinde ist ca. 1 jahr alt, bohrung mit zwei layern gedruckt, da sieht man die risse:
35521
das zweite ca. einen monat alt, mit 4 layeren gedruckt:
35522
bin gespannt ob es nach einem jahr auch die risse gibt...
Rabenauge
02.06.2021, 13:17
Gewinde: Kernbohrung drucken etwas kleiner im Durchmesser (aber nicht viel!), und dann erstmal eingefettete Stahlschraube langsam eindrehen. Die darf auch warm werden dabei, sollte aber wieder raus, ehe sie abgekühlt ist (sonst kann es passieren, man kriegt sie nicht mehr raus, weil sie mit dem Material verschmilzt).
Die "schneidet" das Gewinde dann. Allzu tragfähig wird das allerdings nicht (vor allem bei kleinen Gewinden, M2, M3, so ab M6 geht es ganz gut)- daher mache ich, wo das geht, meistens Mutterntaschen auf der Gegenseite.
Alternativ gäbe es noch diese Einschmelz-Gewindehülsen, das hält auch ganz gut.
Bei senkrecht gedruckten Bohrungen hatte ich oft das Problem, dass die Bohrung selber aus der Fläche bricht- das liegt am Slicen.
Der Prusa hat da irgendwo ne extra Einstellung für..aber auch hier hilft eine Erhöhung der Wanddicke.
Man kann auch den Übergang zwischen senkrechter Bohrung und waagerechter Fläche mit ner anderen Schichtdicke drucken, um diese Stellen stabiler zu bekommen.
Selbstschneidende Schrauben halten allerdings super, wenn genug Futter da ist (Wanddicke).
Wenn man die aber öfter löst und wieder einschraubt, immer erst ne halbe Umdrehung rückwärts, damit sie wieder ins alte Gewinde kommt.
Das gilt aber bei solchen Schrauben in Kunstoffen generell.
also ich habe gewindebohrer zum gewindeschneiden benutzt. Auch gewindeeinsätze, sog. helicoils habe ich schon eingesetzt, war dauerhafter als gewinde im kunststoff. hatte sber bisher offensichlich zu wenige wandlayer...
Rabenauge
02.06.2021, 19:19
Gewindeschneider neigen, besonders bei PLA dazu, Ausbrüche zu erzeugen.
PLA ist spröde.
Wenn du Pech hast, hast du schon beim schneiden die ersten Risse drin.
Es gibt auch, speziell für Kunstoffe, sogenannte Gewindeformer, die gehen wohl etwas sanfter zu Werke.
Hab ich aber auch keinen...
Ne Stahlschraube tuts auch (ich benutze meist ne Zylinderkopfschraube welche mit Imbus, die kann man schön langsam reindrehen)- Vorgehen wie beim Gewindeschneiden: eine Umdrehung rein, ne halbe raus...alles schön mit Gefühl.
Die ganzen Probleme hast du bei der Pendelachse, die ich meine, nicht.
Hier siehst du im wesentlichen, was ich meine:
https://www.offroad-forum.de/pserv.php?img=up.picr.de/17720666wl.jpg
so etwa (https://youtu.be/UvD_ml-w1Go) meintest du das?
Rabenauge
04.06.2021, 22:19
Ja genau.
Sieht doch schon wesentlich besser aus, meinst du nicht?
die traktoren, die ich von früher her ein bischen kenne (Zetor) hatten vorne die kleineren räder, der antrieb war hinten auf den grösseren. Ich glaube nicht, dass das auf dem bild eine kippachse vorne ist, aber wenn, dann wäre sie hier wohl vorne gewesen...
35525
Da ich eigentlich keine fahrten im wald vorhabe war das thema nicht so primär und dringend, aber wenn schon, dann richtig, schaden kanns jedenfalls nicht...
Der aufwand bei der realisierung der kippmechanik bei meinem roboter hält sich sehr in grenzen, deshalb die frage - vorne, hinten, oder beides?
Ist weder die frage nach der radgrösse, die sind alle gleich, noch nach den antriebsrädern, den haben sie auch alle. Was meint ihr?
Rabenauge
07.06.2021, 12:01
Nimm die Seite, wo weniger Last auf der Achse ist...das klingt sinnvoller.
Ansonsten dürfte es weitgehend egal sein.
Den Zetor gabs auch mit Allrad- alles, was wir so an Treckern hatten, war so gebaut (bis auf nen paar Ausnahmen), die Belarus 50/52, 80/82 (die mit der 2 hinten waren auch Allradversionen), ZT 300 (auch 303,305,325, die auch Allrad hatten), selbst die alten Famulus und GT usw.
Bei den Erntemaschinen war es andersrum (Feldhäcksler, Schwadmäher, Mähdrescher)- die hatten die Lenk-Pendel-Achsen hinten, dafür vorn die grossen Antriebsräder.
In der Regel (bei den genannten dürfte das bei allen so sein) war die Hauptlast auf der starren Achse- was auch Sinn macht, da die Seite mit der Pendelachse sich ja beim überfahren von Hindernissen hebt.
Somit wird alles besser abgestützt.
Hallo,
will mal generell Erfahrungenund Sichtweise auf Probleme abgeben.
3D-Druck, wie wir das nutzen, in Schichten, sollte eher ungeeignet für Gewindeschneiden sein. Bin da eher bei Rabenauge. Ich sehe die Schichten und die Freiräume (mikroskopisch klein) dazwischen. Wenn, müsste das so gedruckt werden, dass alle Schichten ohne Freiräume verschmelzen. Das ist aber für die Druckqualität nicht so zuträglich. Die Frage, wie machen das andere, mit Gewinde? - Mit Gewinde habe ich schlechte oder gar keine Erfahrung. Weil Druckmaterialien zu sehr nachgeben (nicht fest genug sind), das Gewinde würde nicht oder nicht lange halten. Ich drucke daher ein "Teilgewinde" so dass eine Schraube Halt findet und Material nach innen verdrängen (verdichten kann), das muss man dabei berücksichtigen. Für dauerhafte Lösungen setze ich auch Muttern in den Druck ein (teils während des Drucks, damit sie komplett eingeschlossen sind).
Gelände: echte geländegängige Fahrzeuge haben, wenn sie im Gelände wirklich über Felsen fahren o.ä. (bpsw.), auch mal ein oder zwei Räder ohne Bodenkontakt. Muss man nur mal Tests von Fahrzeugen anschauen, kommen ja manchmal welche im Fernsehen. Das dann der (Allrad)Antrieb dennoch sauber das Fahrzeug in die angesteuerte Richtung voran bringt, ist womöglich nicht so einfach zu lösen.
Wenn die Räder alle immer Bodenkontakt haben sollen, fällt mir nur eine Kombination aus Stoßdämpfer und Federung ein, die auf das Gewicht und die zu erwartenden Unebenheiten (Federweg) abgestimmt ist.
Freundlichen Gruß
du meinst crawler meist 4wd und wenn du glück hast getrennte steuerung für vorne und hinten.
Gelände: echte geländegängige Fahrzeuge haben, wenn sie im Gelände wirklich über Felsen fahren o.ä. (bpsw.), auch mal ein oder zwei Räder ohne Bodenkontakt. Muss man nur mal Tests von Fahrzeugen anschauen, kommen ja manchmal welche im Fernsehen. Das dann der (Allrad)Antrieb dennoch sauber das Fahrzeug in die angesteuerte Richtung voran bringt, ist womöglich nicht so einfach zu lösen.
Wenn die Räder alle immer Bodenkontakt haben sollen, fällt mir nur eine Kombination aus StoßdämpFreundlichen Grußfer und Federung ein, die auf das Gewicht und die zu erwartenden Unebenheiten (Federweg) abgestimmt ist.
nun ja, auch wenn der thread "outdoor" heisst, habe ich nicht vor damit richtig in den wald zu gehen. Auch wegen der omniwheels, die sind nicht so für offroad geeignet. Vielleicht mal ein test auf rasen, das wäre es aber auch schon. Gepflasterte gewege, vielleicht auch mal mit nem stein drauf oder einem schlagloch - mehr aber auch nicht...
Da es so gut geklappt hat, sind nun beide achsen als kippachsen ausgeführt, sollte das nicht gut sein, lässt sich das relativ leicht wieder rückgängig machen. Wenn die motorsteuerung dann mal funktioniert, gibts wieder ein video...
Mit dem umstieg auf raspberry hab ich jetzt ein ganz anderes problem, vergleichbar mit den libraries bei arduino. Da war klar, die müssen in den ordner libraries. Wie ist es eigentlich bei raspi? Ich habe jetzt mal als simples beispiel das LCD 16x2 in betrieb genommen:
35536
das rudimentäre python progrämmchen macht was es soll, zeigt einfach ein paar buchstaben in zwei zeilen. So weit so gut. Der treiber ist nach der installation des beispiels (https://tutorials-raspberrypi.de/hd44780-lcd-display-per-i2c-mit-dem-raspberry-pi-ansteuern/)im verzeichnis des beispieles abgespeichert, ist aber nur für programme die ebendort abgespeichert sind erreichbar. Das kann eigentlich nicht im sinne des erfinders sein, denke ich.
Ich bin mit linux nun nicht ganz unerfahren, raspi-system ist aber doch noch was anderes. Beim ubuntu gibt es ja verschiedene verzeichnisse, wo nach treibern automatisch gesucht wird, sind alerdings linux-treiber. Wo müssten die raspi-python-treiber sinnvolerweise den hin um von überall und für alle startenden python programme erreichbar zu sein?
die ersten bewegungen des DC-motors:
https://youtu.be/1AXRzORSihY
35539 35540
so stückchenweise geht es weiter. Hier der erste test aller motoren in allen hauptrichtungen
https://youtu.be/pETz2wkB9Hs
bin eigentlich zufrieden bis jetzt, eine frage beschäftigt mich doch:
nach dem was ich so im netz gelesen habe, soll die verwendung eines raspberry vorteilhafter sein als die eines arduinos. Ok, der zero ist ja nicht der leistungsfähigste, bisher kann ich aber nichts finden was sich nicht auch mit einem ESP32 hätte realisieren können:
bisher:
- 4 motoren betreiben
- 4 decoder auslesen
- LCD
- verbindung zum roboter über WLAN (hier über VNC)
geplant:
- hinderniserkennung (US)
- fernbedienung (BT)
- linienfolger (IR)
- personenfolger (wärmesensor)
- GPS(?)
was mir auch nicht so sehr gefällt ist python...
gut, ein komplettes linux-system auf dem ESP32 geht nicht, aber irgendwie erschliessen sich mir da die vorteile eines raspi zero W nicht. Übersehe ich da was?
Rabenauge
29.07.2021, 13:06
Ich denke, du übersiehst da nix.
Das sind alles relativ einfache Aufgaben- nix, womit ein Arduino nich fertig würde.
Grade bei Sachen wie Motorsteuerungen (PWM z.B.) bin ich der Meinung, dass ein Arduino sogar die bessere Wahl ist. Die können das nämlich von Haus aus, ohne irgendwelche Treiber-Geschichten.
Die Vorteile des Raspis, wie höhere Rechenleistung, nutzt du im Moment gar nicht...
Das kommt erst zum Tragen wenn du das Ding z.B. fernsteuern willst (geht natürlich mit nem Arduino auch, aber die meisten Raspis haben halt Wifi und Bluetooth schon an Bord), oder du komplexere Geschichten, wie Kartierung, Bilderkennung (Gestensteuerng oder ähnliches) realisieren willst.
Und ja: Python ist ein bisschen gruselig...nicht ganz so schlimm wie Java, aber schön auch nicht...:)
Sind das Solarzellen obendrauf?
Was bringen die...kannst du das Ding (mit Puffer, ist klar..) damit tatsächlich betreiben?
Das kommt erst zum Tragen wenn du das Ding z.B. fernsteuern willst (geht natürlich mit nem Arduino auch, aber die meisten Raspis haben halt Wifi und Bluetooth schon an Bord), oder du komplexere Geschichten, wie Kartierung, Bilderkennung (Gestensteuerng oder ähnliches) realisieren willst.
könnte man da an ROS denken?
Sind das Solarzellen obendrauf?
Was bringen die...kannst du das Ding (mit Puffer, ist klar..) damit tatsächlich betreiben? betreiben wäre geprahlt. :-) Das ding soll lt. beschreibung 12V/5W liefern. Habe es noch nicht richtig gemessen, habe nur festgestellt, dass sich nach ca. 2h in der sonne die akkuspannung (die schwankt ja von 12.8 - vollgeladen, bis 11.4 - da lade ich normalerweise) um ca. 0.15V erhöht hat. Müsste ich noch genauer messen...
Rabenauge
29.07.2021, 17:40
könnte man da an ROS denken?
Offenbar ist das möglich: https://roboticsbackend.com/using-ros-on-raspberry-pi-best-practices/
Ich hab mich aber nicht damit befasst bisher.
Wegen den Solarzellen: ich kann mir durchaus vorstellen, dass es funktioniert.
Ich meine: der kann ja in Ruhe auf dem Balkon den Tag über tanken, während man arbeiten ist.
Wenn das dann abends für eine oder zwei Stunden Betrieb ausreicht....teste das ruhig mal nebenher ein bisschen, ich bin da schon länger an sowas interessiert.
Es wäre ein Schritt zu nem wirklich autonomen Gefährt.
die letzten wochen habe ich an einem "ortungs-modul" gearbeitet -
https://youtu.be/4P225kCI8J8
was ähnliches hatte ich schon an dem vorgänger, allerdings war die ausführung etwas empfindlicher, hir sind noch zwei lichtsensoren, eines bereits intergiert, das andere soll hier durch dem microprozessor nur ausgewertet werden, der sensor sitzt dann am solarpanel. Der servo soll eben dieses solarpanel rauf und runter bewegen und die optimale position zur sonne finden und halten
Rabenauge
16.09.2021, 00:04
Hm, könnte man da nicht einfach den Strom messen, den die Solarzelle liefert?
naja, auf dem tisch mit einem messgerät sicher machbar, aber wenn es im freien in der sonne steht - da habe ich trotz intensiver suche nichts gescheites für den ESP32 gefunden? Spannungsmessung schon mal, auch wenn relativ kompliziert, aber strom?
Kannst du nicht einfach einen INA auslesen?
Oder AZDelivery ACS712 20A Ampere Stromsensor, offenbar auch für ESP32
ich hab mir das ganze noch einmal überlegt. Die auswertung der effektivität des solarpanels durch den ESP hätte nur dann halbwegs sinn gemacht, wenn ich es per auswertung der sonneneinstrahlung auf's panel gemacht hätte. Räumlich, also von der anordnung der sensoren und auch der controler her. Bei der direkten auswertung des ladestroms macht es mehr sinn das durch den raspi-zero machen zu lassen und da geht es vernünftig nur mit dem INA219 - der ist geordert...
Ich hätte das vermutlich erst einmal mit einem parallel installierten Fotowiderstand versucht.
das hatte ich ja schon mal, hat auch funktioniert...
Sly meinte ob man es nicht direkt an dem ladestrom der geliefert wird erkennen kann ob die lage zur sonne optimal ist. so einen sensor, der auch gleich ins digitale übersetzt hatte ich natürlich nicht, auch wenn ich schon vieles zuhause hab. der sensor ist gekommen und das panel liefert strom. um 17 uhr, nahe Dresden, also schon recht spät am tag kommen 30mA an...
und die variieren natürlich, je nach sonne/panel lage...
Die Idee ist ja nicht verkehrt, aber wenn ein Fotowiderstand funktioniert (dafür sind die Dinger ja gebaut) ist das doch wesentlich einfacher zu handhaben. Weil man das ja an jedem ADC-Eingang messen kann und keine Raketentechnik dafür notwendig ist.
hat der raspi- zero einen ADC-eingang? ich wollte ja auch die info über den ladezustand des akku, das habe ich nun auch :-)
ARetobor
24.09.2021, 11:19
Nö
Das hier:
https://de.pinout.xyz/pinout/adc_pi_zero#
hier erstmal der ladestrom vom solarpanel. auf die sonne ausgerichtet, über mittag, die elektronik incl. des raspberry eingeschaltet, ladestrom 130mA...
https://youtu.be/xco1ASeDDuw
hier der endgültiger aufbau des ortungs-moduls. Aus dem servo habe ich einen getriebemotor gemacht, der muss "nur noch" langsam angesteuert werden, also nicht nur an/aus:
https://youtu.be/TrXDk9ITD9g
und hier noch das modul im roboter eingebaut:
https://youtu.be/xDIO8LxMOp4
Rabenauge
04.10.2021, 07:33
130mA ist jetzt zwar nicht die Welt, aber wenn das zehn Stunden am Tag so laufen kann (mir ist klar: das wird eher seltener der Fall sein), kann man damit schon bisselwas anfangen.
Ich meine: mit grossen Touren wird da nix, aber wahrscheinlich steht er ja sowieso meistens herum. So lange der Pi dabei am Leben bleibt....was brauchen die Zeros denn so? Ich hab das nie wirklich gemessen.
80mA ohne und 100mA mit wlan, habe ich gelesen....
Wie sieht das hier zurzeit mit dem Projekt aus, Inka? Wo soll die Reise hin gehen, wie weit bist Du?
Bei mir liegt alles auf Eis, ist Lebensumständen geschuldet. Werde aber irgendwann noch weiter machen.
MfG
gut sieht's aus Moppi...
- das fahrgestell als solches ist so weit dass ich die motoren bedienen kann, die encoder lesen kann, das alles ist allerdings in python. weil raspi zero. ungewohnt.
- in letzter zeit habe ich mich viel mit dem - so habe ich es zunächst genannt - ortungsmodul beschäftigt. Ultraschall nach vorne und nach unten, IR nach vorne. Ein hebemechanismus für das solarpanel ist ebenfalls integriert. Alles mit einem ESP32 gesteuert, also ein mir vertrauteres terrain, auch wenn es da lücken gibt. Aber wo gibt's die nicht. manchmal glaube ich meine kennnisse bestehen nur aus lauter lücken :-)
- der zero soll mit dem esp per MQTT kommunizieren. noch ein unbekanntes feld...
- habe mir für die nächste woche vorgenommen den stand mal mit einigen fotos zu dokumentieren...
und das ziel? Der weg ist das ziel, insofern gehe ich jeden abend mit einem zufriedenem gefühl ins bett. Naja, ausnahmen gibts auch schon mal... Aber das einzige projekt bei dem ich etwas unter termindruck stand war die geschichte mit dem anti-schlafapnoe-sensor. Ansonsten bin ich "unterwegs"...
Na, dass Du nicht weißt , wann es fertig wird, ist mir bekannt. Mir geht es nicht anders ... :) Aber was es am Ende können soll, was strebst Du an?
Rabenauge
11.10.2021, 08:15
- der zero soll mit dem esp per MQTT kommunizieren. noch ein unbekanntes feld...
Sehr cool.
Da wirst du Spass haben, glaub mir.
Das ist dermassen unkompliziert...
Sehr cool.
Da wirst du Spass haben, glaub mir.
Das ist dermassen unkompliziert...
bin schon gespannt...
Aber was es am Ende können soll, was strebst Du an?
ich strebe einen "quasi" autonomen roboter an, mit folgenden eigenschaften bzw. ausstattung:
- 1 bis 1.5km aktionsradius ohne aufladung des akku
- hauptcomputer raspberry zero-W
- verteilte intelligenz: hauptcomputer / ortung / antrieb / odometrie
- interne kommunikation mit MQTT, evtl. ROS?
- wifi anbindung ans heimische wlan, aber auch eigenständiger AP (operation outdoor)
- ausenkommunikation über wifi / BT / 433mHz, datenabfrage über smartphone
- LCD anzeige mit 2 zeilen
- zielsuche mit hilfe von IR-baken
- bei sonnenlicht automatisches aufladen des akkus
- induktive ladestation als basis (evtl. auch mit einem solarpanel versehen)
- automatisches ausweichen bei hindernissen (oberhalb wie unterhalb der fahrebene)
- fahrgestell aus 10mm alu-makerbeamprofilen (260x170x80mm)
- antrieb durch DC motoren mit encodern (A+B)
- kippachse vorne und hinten
- vier omniwheels 100mm durchmesser
- motoransteuerung mit einem raspi-motozero-hut (https://thepihut.com/products/motozero)
- personenerkennung in fahrtrichtung (wärmesensor)
- videoaufnahmen der umgebung
momentan komme ich nur langsam voran:
- die idee mit dem raspi zero-w als hauptcontroler verwerfe ich wahrscheinlich. Es stört mich die lange bootzeit, (ein ESP32 ist sofort nach dem einschalten da),python ist mehr als ungewohnt und es ist eigentlich ein overshooting um damit vier motoren anzutreiben. ausserden ist der stromverbrauch recht hoch...
- der raspi liefert bereits videos - war überrraschend einfach...
- das "ortungsmodul"ist fertig. Es hat gleich nach dem einschalten folgende funktionalitäten: US-sensor nach vorne, US-sensor nach schräg unten, IRsensor nach vorne, überwachung der akkuladung (samt bewegung des solarpanels), kann zusätzliche module per relais hinzuschalten, wie z.b. das "bewegungsmodul" oder den raspi als bildlieferanten oder während der mission als MQTT schaltzentrale, beides wird ja nicht immer gebraucht...
- bedienung des ortungsmoduls nach dem robotereinschalten per WIFI, später evtl. auch ereignisgesteuert...
- das oben erwähnte "bewegungsmodul" ist in arbeit und besteht ebenfalls aus einem ESP32 und zwei dualmotortreibern mit einem HG7881, also ebenfalls per WIFI erreichbar.
was haltet ihr davon? Hauptsächlich im zusammenhang mit der änderung der hierarchie der controler?
Rabenauge
21.11.2021, 15:56
Die Idee, auf so nem "kleinen" Roboterchen nen MQTT-Server aufzusetzen, hat was.
Damit wird alles _nochmal_ modularer.
Der US-Sensor "schräg nach unten"- soll Stufen nach unten erkennen oder?
Wie gut funktioniert das denn?
Der US-Sensor "schräg nach unten"- soll Stufen nach unten erkennen oder?
Wie gut funktioniert das denn?
eigentlich recht gut, war schon ähnlich auf einem der vorgänger aufgebaut, hab aber das video auf die schnelle nicht gefunden...
momentan komme ich nur langsam voran:
- die idee mit dem raspi zero-w als hauptcontroler verwerfe ich wahrscheinlich. Es stört mich die lange bootzeit, (ein ESP32 ist sofort nach dem einschalten da),python ist mehr als ungewohnt und es ist eigentlich ein overshooting um damit vier motoren anzutreiben. ausserden ist der stromverbrauch recht hoch...
...
was haltet ihr davon? Hauptsächlich im zusammenhang mit der änderung der hierarchie der controler?
grins, wie schnell ist bei dir langsam, aber du hast recht low level sollte man auf microcontroller zurückgreifen, raspberry pico :)
grins, wie schnell ist bei dir langsam, aber du hast recht low level sollte man auf microcontroller zurückgreifen, raspberry pico :)
mit langsam meine ich z.b. eine situation in der ich gefühlt 2 minuten warten muss bis der zero "da" ist um den roboter um ein paar grad zu drehen weil die lage zu sonne nicht mehr optimal ist und ich will weiter laden. Beim laden ist der zero abgeschaltet, wegen stromverbrauch...
aber noch ganz was anderes:
ich hab geschrieben das ortungsmodul ist fertig. An sich schon, man kann damit leben, aber...
Bei der rauf- und runterbewegung des solarpanels wollte ich zunächst ein microservo, also sG90 verwenden, das war zu schwach und es hat sich rausgestellt, dass es besser wäre mehr als die halbe umdrehung des ritzels zu haben. Das stärkere, also das MG996 ist bestellt, gleich als 360°, also ohne anschläge, was also quasi wie ein getriebemotor zu behandeln ist...
Nun habe ich die ansteuerung mit hilfe von PWM (was bei ESP32 ohnehin ganz anders ist) versucht. Mit SG90, ohne anschläge, ohne last. Funktioniert, so dass ich es mit zwei schaltern auf dem smartphone rauf- und runter bewegen kann. Aber nach gefühl, heisst die bewegung ist nicht genau definiert. Macht bei der lage eines solarpanels eigentlich nichts, die frage bleibt - wie kann man es anders machen?
Kann ich z.b. mit hilfe von millis() so kurze impulse erzeugen, dass der DC-motor sich praktisch wie ein schrittmotor dreht? Er muss nicht extra nach jedem impuls gebremst werden, dafür sorgt schon die last - und das getriebe...
Andere möglichkeiten?
Rabenauge
21.11.2021, 23:04
eigentlich recht gut, war schon ähnlich auf einem der vorgänger aufgebaut, hab aber das video auf die schnelle nicht gefunden...
In welchem Winkel schaut der Senso nach unten, damit das funktioniert?
Wegen deinem Servo-Problem: die Arduino-Servo-Library kann auch Gradvorgaben verarbeiten.
Allerdings frage ich mich, wie das in dem Servo wohl gelöst ist: ich kenne kein Poti, was 360 Grad schafft....weisst du da näheres?
Das interessiert mich auch.
In welchem Winkel schaut der Senso nach unten, damit das funktioniert?
die mitte des moduls ist ca. 15cm über dem boden, der sensor ist um 45° nach unten geneigt. Mir ging es nicht um stufe(n), sondern um plötzlich auftauchende löcher im boden, bzw. die ränder der terrasse. Ist aber eigentlich egal...
Wegen deinem Servo-Problem: die Arduino-Servo-Library kann auch Gradvorgaben verarbeiten.
Allerdings frage ich mich, wie das in dem Servo wohl gelöst ist: ich kenne kein Poti, was 360 Grad schafft....weisst du da näheres?
Das interessiert mich auch.
es kursieren etliche beschreibungen wie man einen normalen servo umbaut. da ist der poti nicht mehr drin, nur der motor und getriebe..., also ein getriebemotor im gehäuse eines servos...
Rabenauge
22.11.2021, 17:09
Das kenn ich- hab ich auch schon gemacht.
Die Dinger kannst du dann aber nur noch in Drehrichtung und Drehzahl (letzteres in Grenzen) steuern. Zumindest dann, wenn man die Elektronik drin lässt und den Poti durch nen Festwiderstand ersetzt.
Sowas aber zur Positionierung verwenden, wird schwierig.
Bei deinem Link stand was von "ab Werk umgebaut"- wäre ja denkbar, dass die da das Poti durch nen Encoder ersetzen, das gibts auch. Dann hast du ein echtes 360Grad-Servo, was auch wieder zurück findet.
oberallgeier
22.11.2021, 18:00
.. das Poti durch nen Encoder ersetzen .. ein echtes 360Grad-Servo ..Stimmt (bis auf den Bereich da vom Poti nur Schrott kommt). Aber immerhin ist die Encoderlösung ohne "Durchdrehsperre" wirklich ein gutes Dingelchen (hier mal in den Motor geschaut (https://rn-wissen.de/wiki/index.php?title=Servos#Getriebemotor_aus_Servoumba u_mit_Encoder), der mein Minid0 antreibt (https://www.roboternetz.de/community/threads/36121-Autonom-in-kleinen-Dosen-R2_D03-Nachfolger-R3D01?p=495507&viewfull=1#post495507)). Wenn man >bei diesem Muster< die originale Übersetzung ausnutzt - 768:1 - dann gehts ja bis auf ein halbes Grad genau. Und für reichlich 270 Grad kann man auch die Stellung erfassen - Potileitung separat nach draussen leiten. Aber das alles ist ja nicht neu und sehr einfache Technik.
Rabenauge
23.11.2021, 07:43
Joe, ich hab vor Jahren mal diese Servoelektroniken als Mini-Fahrtregler zu benutzen versucht.
Also einfach ausgebaut, und den Poti auf Mitte gedreht. Es war kaum möglich, ne exakte Nullstellung zu erreichen.
Sehr weit hatte ich das nicht verfolgt, und es kann natürlich auch sein, dass die RC-Fernsteuerung nicht soo exakt arbeitete (da sind auch nur Potis drin als Geber), aber es deutete einiges drauf hin, dass das verbaute Poti keineswegs allzu präzise war. Ein eingebauter Festwiderstand löst das Problem.
Auch das Auslesen eines solchen Potis über nen rausgeführten Abgriff brachte -mit nem Arduino- keine allzu berauschenden Resultate. Letzteres lag vermutlich daran, dass der ADC der AVR ja nicht allzu hoch auflöst.
Wegen deinem Servo-Problem: die Arduino-Servo-Library kann auch Gradvorgaben verarbeiten.
Allerdings frage ich mich, wie das in dem Servo wohl gelöst ist: ich kenne kein Poti, was 360 Grad schafft....weisst du da näheres?
Das interessiert mich auch.
kann ich nur teilweise beantworten. Der 360° servo ist gekommen, hab den eingebaut und nach vielem probieren das herausgefunden, was ich brauche:
- kein anschlag, lässt sich frei durchdrehen
- mit diesem code:
void servo_rauf (void)
{
tastenwert_runter = digitalRead(14);
//Serial.println(tastenwert_runter);
if (tastenwert_runter == HIGH)
{
servoMotor.writeMicroseconds(ROTATE_COUNTERCLOCKWI SE);
delay(100);
servoMotor.writeMicroseconds(STOP);
delay(1000);
digitalWrite(14,LOW);
}
}
/*******************************************/
void servo_runter (void)
{
tastenwert_rauf = digitalRead(15);
//Serial.println(tastenwert_rauf);
if (tastenwert_rauf == HIGH)
{
servoMotor.writeMicroseconds(ROTATE_CLOCKWISE);
delay(100);
servoMotor.writeMicroseconds(STOP);
delay(1000);
digitalWrite(15,LOW);
}
}
kann ich das solarpanel per HTML-taste per einzelstepp rauf und runter bewegen. Er sucht nach dem einschalten auch keinen nullpunkt - vermutlich weil er keinen hat :-)
Rabenauge
27.11.2021, 19:59
Hm, wenn das schrittweise funktioniert, gibts ja immernoch die Möglichkeit, das per Controller (z.b. anhand der Stromausbeute) zu machen.
Klingt gut.
nach dem ortungsmodul ist nun das move modul "fertig". Hardware (beschreibung und video folgen) und ein bischen code...
Prinzipielle fragen stellen sich:
- zuerst, beim einschalten, startet das "ortungsmodul", das kann per US und IR in die richtung schauen, in die der roboter ausgerichtet ist und feststellen ob hindernisse da sind, oder ob es was zum folgen gibt
35700
- der bildschirm ist per WIFI erreichbar. Vorgesehen ist ein start im AP-STA mode, wenn also das heimische WLAN nicht zur verfügung steht, startet der AP, jetzt startet er erstmal nur im heimischen WLAN
- per buttonclick lässt sich von dem ortungsmodul aus das move modul dazu-schalten um eventuelle richtungsänderungen vorzunehmen, screen ist auch per WIFI erreichbar
35701
- beide module bauen - stand jetzt - ihren eigenen WLAN auf, ohne voneinander was zu wissen, man kann beide unabhängig voneinander steuern. Hier über den webbrowser des notebooks, später evtl. über den WLAN eines raspi-zero(?)...
-der controler des ortungsmoduls (ESP32) soll als "erst-starter" - und auch weil er mit den funktionen zum laden versehen ist - die hauptverantwortung haben, soll z.b. auch den zero an- und ab-schalten können (zum laden des akku z.b.)
- für den zero habe ich erstmal nur die aufgabe der bildübermittlung vorgesenen...
bisher habe ich da noch nicht sooo viel arbeit investiert, die einzelnen module bleiben auch in einer anderer reihenfolge der verwendung anwendbar - ist das konzept so in sich schlüssig, oder nur blödsin?
mit dem video klappt es erstmal nicht, wenigstens ein paar fotos zum letzten stand:
hier ist eines der vorgängerversionen mit einer wilden verdrahtung:
35741
hier ein zwischenstand, mit solarpanel, chassis verkleinert auf die grösse des solarpanels, akku längs im gehäuse und als powermodul noch eine leiterplatte:
35742
hier sieht man die einzelnen module: move-modul, power-modul und auf der vorderseite das ortungsmodul:
35746
hier ist das powermodul aufgeklappt:
35747
das aufgeklappte movemodul mit ESP8266 und den treibermodulen:
35745
die leiterplatte des move-moduls mit nano und einem der treibermodule:
35744
Insgesamt finde ich das mal nicht schlecht, was Du baust. Sieht recht ordentlich aus. Du scheinst da viel Zeit zu investieren. Wie sieht es denn mit den Rädern aus, wie schlagen die sich im Gelände? Ich meine diese Art wird nur verwendet, wenn man plane Untergründe hat, wie in Produktions- oder Lagerhallen. Da macht so was auch Sinn, weil oft auch die Wegbeschaffenheiten so sind, dass sehr enge Kurven, also im rechten Winkel, gefahren werden müssen. Aber sonst denke ich, wären Profilräder mit einer richtigen Lenkung für den Betrieb im Außenbereich besser geeignet. Einen Moment dachte ich, ich könnte eine Lenkung auf den Bildern entdecken, aber das sah wohl nur so aus.
Die räder sind für eine anwendung im freien gelände wie wald, wiese oder sand ungeeignet. Da ich solche anwendung aber nicht beabsichtige, stört mich das nicht - ich bin von den anderen eigenschaften der omni-wheels begeistert...
Getestet habe ich die räder bisher innerhalb der wohnung, auf normalen gehwegen, kopfsteinpflaster, asphalt und ähnliches - wie gesagt für das was ich damit vorhabe nicht nur ausreichend. Eine steuerung braucht man dafür nicht, wird alles über drehzahlen, umdrehungen und drehrichtung geregelt...
Momentan arbeite ich an der kommunikation zwischen den drei microcontrolern und dem antrieb auf basis von I2C, so langsam lichtet sich der wald :-)
Und Hindernisse, wie niedrige Bordsteinkanten? Bleiben die Räder an so was hängen? Oder Wasserrinnen?
also ich wollte eigentlich auch nicht ins wasser mit dem ding :-) 2cm hohe türschwellen sind aber kein problem:
https://youtu.be/RSDeOnKTmKc (https://youtu.be/RSDeOnKTmKc)
weiteres modul ist so weit "fertig":
35755 35754
das modul beinhaltet einen ESP8266 D1 mini und die MPU6050, mit wlan-anbindung. Befestigt wird das modul auf der unteren seite des solarpanels, so kann die lage des panels bzw. der aufstellwinkel sensiert werden, im eingefahrenen zustand des panels ist der sensor in der horizontalen und so kann dann die lage des roboters zum norden bestimmt werden. Noch viel arbeit für den programmierer :-)
in arbeit ist das TFT-modul, was hier schon jahrelang ungenutzt rumlag, es fehlt noch der mega2560 mit integriertem esp8266, wird in CH so angeboten. bin gespannt...
35756
es gibt probleme mit dem modul, naja eher problemchen, trotzdem wüsste ich gerne wie man sie umgehen kann:
- das modul ist auf der unterseite des solarpanels angebracht und soll das rauf- und runterfahren des panels messen und die daten ausgeben, das funktioniert.
- es soll aber auch die drehung des roboters um die senkrechte achse sensieren und das funktioniert nicht, weil die roboter- und sensor- drehachse identisch mit der schwerkraftrichtung ist. Ich habe versucht den sensor mit einer solchen aufnahme
3576035761
festzumachen, es steht praktisch auf einer der ecken und somit ist keine der drei achsen identisch mit der schwerkraftrichtung. Es funktioniert trotzdem nicht und es wäre gut zu wissen warum.
Eine einfache lösung wäre ein anderer sensor, das widerstrebt mir aber erstmal, aber als lösung in der hinterhand ist es schon mal gut. Ich hab den code mit dem gemessen und ausgegeben wird als zip mal drangehängt, vielleicht mag ja einer reinzuschauen...
- also das chinesische projekt mit dem ATMEGA 2560 und ESP8266 hat sich als - zumindest für meinen anwendungsfall - ein reinfall erwiesen. Wenn das TFT display auf dem mega aufgesteckt ist, kann man an den ESP nichts anschliessen. Schade, muss halt ohne gehen... - habe jetzt zusätzlich zu dem mega einen 8266 (wg. wifi fähigkeit) zusätzlich verbaut...
- das problem mit dem gyro besteht immer noch, die MPU 6050 zeigt jetzt aber werte, die ich auch auswerten kann, der programmierer arbeitet noch dran :-)
- die vor wochen bestellten getriebe sind eingebaut, zum ersten mal habe ich das gefühl dass die motoren, räder und die übersetzung auch zueinander passen... ( https://youtu.be/2x-0_Se33i8 (https://youtu.be/2x-0_Se33i8) )
- neben dem ortungsmodul am bug kann man auch einen cameramodul erkennen, da ist die ESP32-cam verbaut, was mir daran nicht gefällt ist, dass man immer beim neu flashen des moduls einen jumper setzen muss. mindestens unpraktisch...
- steuern kann ich das alles per gemeinsame webseite. erstmal nur "zusammengeworfen" ohne grosse formatierung....
35793 35794
bis demnächst dann wieder...
ein paar neuigkeiten...
- hier ( https://youtu.be/agHhqmE999Q ) kann man aus der nähe sehen, welche module bereits eingebaut sind. TFT-display, LCD-display, move-modul, power-modul, ortungsmodul, von den gyros habe ich zwei verschiedene eingebaut, kann sie dann vergleichsweise testen...
- im laufe der entwicklung habe ich mich entschlossen auch das induktive laden des akkus zu implementieren, das bedeutet, dass ein "lade-modul", in dem entschieden werden soll wie (solar oder induktiv) geladen wird, noch entstehen muss. Auch die optimale ausrichtung des solarpanels findet hier statt, genauso wie das "suchen & finden" der induktiven ladestation. Die bake hierzu gibt es bereits (seit 2013 (https://rn-wissen.de/wiki/index.php?title=IR-bake_f%C3%BCr_den_RP6)!), damals für den RP6 - jetzt hat sie nur noch ein gehäuse bekommen ( https://youtube.com/shorts/Omznl4FpHt0 )...
so, das lademodul ist teilweise fertig, auch das modul welches das solarpanel zur sonne ausrichten soll, bzw. die sensoren dazu bereit stellt:
35818 35819 35820
die idee dahinter ist die, dass wenn der roboter in der sonne steht, gibts werte von den lichtsensoren. Kippe ich das solarpanel rauf oder runter, werden sich die werte wegen der unterschiedlichen abschattung unterschiedlich verändern, daraus müsste man erkennen können, ob das panel in die sonne oder aus der sonne raus bewegt wird. Das gleiche gilt für die horizontale richtung, wenn sich der roboter dreht. Ich denke dass müsste so funktionieren...
Kennt jemand etwas anderes, oder hat ne andere idee?
Holomino
10.08.2022, 21:22
Das ist schon das Naheliegendste. Könnte mir allerdings vorstellen, das es nicht so gut funktioniert, wenn die Sonne hinter dem Modul steht (kann passieren, wenn Du aus dem Schatten heraus wieder in die Sonne fährst).
Nachtrag: Alternativ oder ergänzend kann man die Sache auch mit Datum, Uhrzeit und Kompass lösen. So flexibel ist die Sonne ja nicht.
ich dachte ohnehin daran zuerst den roboter das panel auf 45° stellen zu lassen und dann einmal messend auf der stelle 360° drehen zu lassen, mit den omniwheels kein problem...
In dem zusammenhang ist mir aber noch was eingefallen. Wäre wichtig zu wissen, ist es tag, oder nacht, scheint die sonne oder nicht - da gibt es zeitserver die man abfragen könnte, allerdings ohne externes wlan? Oder geht das mit hilfe von millis()?
Rabenauge
11.08.2022, 10:24
Hattest du nicht nen Raspi auf dem Spielfeld?
Den kannst du mit einer RTC ausstatten (geht mit den Arduino&Co auch...), und dann mit den Python-Modul Astral Sonnenauf-und Untergang berechnen lassen. Astral funktioniert auch offline, für einen beliebigen Standort.
021aet04
15.08.2022, 10:49
Was mir aufgefallen ist. Du verdeckst das Panel mit deinem Sensor. Das ist keine gute Idee. Der Wirkungsgrad bei Solarzellen sinkt bei einer Abschattung rapide ab. Besser ist es wenn die die Schaltung hinter das Panel gibst und die Sensoren mit Leitungen an die vier Seiten verlegst.
Mfg Hannes
Hattest du nicht nen Raspi auf dem Spielfeld?
Den kannst du mit einer RTC ausstatten (geht mit den Arduino&Co auch...)
gute idee! ist ja geplant, der zero soll ja das ganze per MQTT steuern...
Du verdeckst das Panel mit deinem Sensor. Das ist keine gute Idee. Der Wirkungsgrad bei Solarzellen sinkt bei einer Abschattung rapide ab.
auch wahr! Ich habe zunächst einmal die alu-längsprofile unter das solarpanel verlegt - geht auch so und nun wären die solarzellen alle frei und funktionell. Die sensoren quasi an die vier seitenkanten des solarpanels - das habe ich mir auch überlegt und auch schon mit angefangen. je weiter auseinander die sensoren für die jeweilige schwenk- bzw. drehachse sind, um so besser lässt sich die lage zur sonne einstellen. Einerseits. Andererseits haben mich die langen leitungen quer durch den ganzen aufbau abgeschreckt. Die verdrahtung der sensoren in der sensorbox auf der leiterplatte ist natürlich einfacher. Ich versuche die sensorbox als ganzes - die ist ja schon fertig, so zu platzieren, dass sie seitlich drangeflanscht wird und keine solarzellen verdeckt. Mal sehen wie gut das wird...
das lade-sensor-modul habe ich doch noch neu gemacht. Ursprünglich war es mit einem modul PCD85911, das liess sich alerdings nicht sockeln, die kontakte musste ich verbiegen, um das modul auf eine kleine, gemeinsame modulplatine direkt einlöten zu können. Wenn man da was ändern will...
Also ein anderes ADC modul (ADS 1115) - da gab es diese probleme nicht. Der ESP8266 blieb, auch der code, zumindest weitgehendst:
35824 35825 35826
ich habe für jedes modul einen microcontroler vorgesehen:
ortungs-modul - ESP32
move-modul - ESP8266 / arduino nano
TFT-display - ESP8266 / arduino mega
lade-modul - ESP8266
gyro 6050 - ESP8266
gyro 271 - ESP8266
solar-modul - ESP8266
cam-modul - ESP32S
die kommunizieren alle per wifi mit der "zentrale" - vorgesehen ist ein raspi zero-w. Damit dachte ich kann ich einiges an verbindungen zwischen den modulen sparen. wie man auf den videos erkennen kann ist die verdrahtung recht übersichtlich:
https://youtube.com/shorts/fnXfA4xR8Hc
https://youtube.com/shorts/1uynGFMIZ0w
die gemeinsame webseite für die datenausgabe und steuerung sieht so aus:
35827
der roboter fährt nun, ferngesteuert vom smartphone oder PC, die sensoren liefern ihre daten, man kann nach den bildern der cam auch fahren, die daten der sensoren werden allerdings noch nicht weiter verarbeitet, das kommt jetzt mit dem raspi und MQTT...
https://www.n-tv.de/23274791
weitere änderungen an der solar-sensor-box:
war ja ursprünglich fest montiert, an der seite des panels, das stand zu weit raus, wäre beim autonomen fahren nur im weg und gefährdet. Das habe ich jetzt so abgeändert, dass die box nun auch seitlich, an der gleichen stelle angebracht ist
35879
allerdings ist sie schwenkbar, beim aktivieren des solarpanels zum laden wird sie gleichzeitig mit dem panel herausgeklappt, nach dem laden verschwindet sie wieder ( https://youtu.be/YVI7UDKtk3s (https://youtu.be/YVI7UDKtk3s) )
habe den ablauf für das aus- und einfahren des solarpanels noch etwas optimiert, im video ( https://youtu.be/-f_yNFI8K30 ) ist das aufstellen und wieder-einfahren des solarpanels beim start und ende des solarladens zu sehen. So weit so gut...
nun habe ich eine frage:
der roboter besteht aus 6 modulen, jedes modul hat einen microcontroler, das move-modul noch einen nano zum steuern der motoren. Die module geben hre daten auf einer gemeinsammen webseite aus, die nutze ich um den roboter manuell zu steuern. Das soll bei allen bemühungen um ein autarkes agieren auch so bleiben, man möchte doch für den notfall die möglichkeit haben einzugreifen...
Die gemeinsame webseite läuft jetzt noch auf dem heimnetzwerk, also der fritzbox, die soll durch einen raspi-zero-w ersetzt werden, der auch in einem modul auf dem roboter installiert werden soll. Das ist an sich kein problem, die manuelle steuerung funktioniert dann eben in einem separatem netzwerk auch.
Jetzt zu autonomie:
Die module sollen ja daten untereinander austauschen und entsprechend agieren, bzw. reagieren. Wie sollte der datenaustausch stattfinden? Ich habe schon etwas über verschiedene möglichkeirten gelesen, praktische erfahrungen habe ich hier nicht:
- I2C - habe ich in den modulen realisiert (move modul z.b.) scheint mir für die haupt-kommunikation nicht geeignet
- ESP-now
- easy-mesh
- painless-mesh
- MQTT
- xyz?
wie würdet ihr das machen, was verwenden?
ich hasse buzz wörter,
wenn du ein eigenes wlan netz hast, wo alle module ran kommen, mqtt
ansonsten würde ich auf rs485 oder serielles netz gehen, auf den kurzen strecken, ist nicht die geschwindigkeit des netzes sondern der schnittstellen das problem.
:D
gruß stephan
ok, danke für die info, dann wird es MQTT...
der AP auf dem zero läuft schon, eines der module habe ich probeweise darauf zugreifen lassen - läuft :-)...
die wlan hierarchie habe ich zunächstmal mit hilfe von wifi-multi lib aufgebaut, zuerst wird nach dem AP-zero gesucht, wenn nicht vorhanden, das hausnetz. Die ersten versuche waren erfolgreich...
noch eine frage: ich habe einiges an verbindungen mit dupont steckern und kontakten aufgebaut, wie halt bei arduino üblich. Das zeug gefällt mir immer weniger - ich bin mehr auf der suche nach wackelkontakten statt vernünftig zu arbeiten... Gibts eine alternative dazu?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.