outdoor III

[inka]

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]

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?

[inka]

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...

[inka]

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

- 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

- 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?

[inka]

so, das lademodul ist teilweise fertig, auch das modul welches das solarpanel zur sonne ausrichten soll, bzw. die Sensoren dazu bereit stellt:



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]

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.

[inka]

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?

[morob]

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

[inka]

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]

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.