outdoor III

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

[inka]

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]

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]

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

[Rabenauge]

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.

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

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_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);
  }
}

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]

Hm, wenn das schrittweise funktioniert, gibts ja immernoch die Möglichkeit, das per Controller (z.b. anhand der Stromausbeute) zu machen.
Klingt gut.

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