Druckbare Version
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?
Sehr cool.Zitat:
- der zero soll mit dem esp per MQTT kommunizieren. noch ein unbekanntes feld...
Da wirst du Spass haben, glaub mir.
Das ist dermassen unkompliziert...
bin schon gespannt...Zitat:
Zitat von Rabenauge
ich strebe einen "quasi" autonomen roboter an, mit folgenden eigenschaften bzw. ausstattung:Zitat:
Zitat von Moppi
- 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
- 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?
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?
eigentlich recht gut, war schon ähnlich auf einem der vorgänger aufgebaut, hab aber das video auf die schnelle nicht gefunden...Zitat:
Zitat von Rabenauge
grins, wie schnell ist bei dir langsam, aber du hast recht low level sollte man auf microcontroller zurückgreifen, raspberry pico :)Zitat:
Zitat von inka
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...Zitat:
Zitat von morob
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?
In welchem Winkel schaut der Senso nach unten, damit das funktioniert?Zitat:
Zitat von inka
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.
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...Zitat:
Zitat von Rabenauge
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...Zitat:
Zitat von Rabenauge
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.
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, der mein Minid0 antreibt). 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.Zitat:
.. das Poti durch nen Encoder ersetzen .. ein echtes 360Grad-Servo ..
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.
kann ich nur teilweise beantworten. Der 360° servo ist gekommen, hab den eingebaut und nach vielem probieren das herausgefunden, was ich brauche:Zitat:
Zitat von Rabenauge
- kein anschlag, lässt sich frei durchdrehen
- mit diesem code:
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 :-)Code:void servo_rauf (void)
{
tastenwert_runter = digitalRead(14);
//Serial.println(tastenwert_runter);
if (tastenwert_runter == HIGH)
{
servoMotor.writeMicroseconds(ROTATE_COUNTERCLOCKWISE);
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);
}
}
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
Anhang 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
Anhang 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:
Anhang 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:
Anhang 35742
hier sieht man die einzelnen module: move-modul, power-modul und auf der vorderseite das ortungsmodul:
Anhang 35746
hier ist das powermodul aufgeklappt:
Anhang 35747
das aufgeklappte movemodul mit ESP8266 und den treibermodulen:
Anhang 35745
die leiterplatte des move-moduls mit nano und einem der treibermodule:
Anhang 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
weiteres modul ist so weit "fertig":
Anhang 35755 Anhang 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...
Anhang 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
Anhang 35760Anhang 35761
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 )
- 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....
Anhang 35793 Anhang 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!), 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:
Anhang 35818 Anhang 35819 Anhang 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?
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()?
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.
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
gute idee! ist ja geplant, der zero soll ja das ganze per MQTT steuern...Zitat:
Zitat von Rabenauge
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...Zitat:
Zitat von 021aet04
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:
Anhang 35824 Anhang 35825 Anhang 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:
Anhang 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...
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
Anhang 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 )
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