outdoor I

[inka]

Und nun haben wir ein Problem, das mir nicht gefällt. Hätte ich ganz zu Anfang dran denken können, das zu überprüfen (obwohl ich schon einmal Image Maps verwendet habe, ist allerdings schon etwa 15 Jahre her): die Image Map arbeitet nur mit Pixel. Wir können keine Koordinaten verwenden, die einfach skaliert werden können, indem wir ein anderes Maß, als eben Pixel, verwenden. Falls das doch irgendwie machbar sein sollte, weiß ich noch nicht wie.
Das bedeutet, dass die Tabelle und das Bild - also die Fernbedienung in HTML - in Pixel definiert wird (was ich in der Beispieldatei schon gemacht habe). Sollte die Fernbedienung, in Pixel, breiter oder höher sein, als der Smartphone-Bildschirm, passt die dort nicht vollständig drauf und muss horizontal und/oder vertikal gescrollt werden. Natürlich kann man die Pixelmaße dann an seinen Smartphone- oder Tablet-Bildschirm anpassen, es bleibt aber eine feste Angabe.

die darstellung auf dem smartphone sieht so aus:



ich meine, es muss nicht sein, dass die html fernbedienung das ganze display ausfüllt, toll (und völlig ausreichend) wäre es, wenn es in etwa zentriert zum display wäre.

Die anderen sachen habe ich mir angeschaut, selber programmieren könnte ich es nicht, aber ich habe verstanden wo Du was und wie gemacht hast, müsste also in der lage sein kleine korrekturen selbst durchführen zu können. Toll erklärt!

[Moppi]

ich meine, es muss nicht sein, dass die html fernbedienung das ganze display ausfüllt, toll (und völlig ausreichend) wäre es, wenn es in etwa zentriert zum display wäre.

So etwas mache immer am Ende irgendwann. Manchmal werden ganze Entwürfe wieder verworfen, dann macht man nicht so viel Arbeit umsonst. Wenn das später so bleiben sollte, schauen wir, dass wir das zentriert bekommen. Oder wie auch immer. Berechnen müssen wir das im Programmcode neu. Jetzt passt es zwar, aber mit einem andern Gerät sieht das wieder anders aus. Aber die Berechnung können wir auch später einfügen.

Du kannst ja mal schauen, dass Du die Koordinaten für die anderen Tasten hinzufügst, da fehlen noch 16. Zurzeit feilen wir am Design und HTML-Layout. Deshalb Frage: Wie ist das jetzt überhaupt, ist das schon so in Ordnung oder fehlen noch zusätzliche Funktionen an der Fernbedienung in HTML? Gefällt Dir sonst irgendwas nicht? Oder willst Du lieber was anderes?



MfG

- - - Aktualisiert - - -

Ausgabe zentrieren


Ich habe etwas experimentiert. Und es hat funktioniert. Da es einfach war, hier direkt der neue HTML-Quelltext: ir_fernbedienung_htm2.txt
Umbenennen der Datei kennst Du ja schon.

Noch ist das alles nicht so geordnet, sondern mehr zusammengeschmiert
Das macht aber nichts, weil ich mich so dem Endergebnis annähere.

Ich habe noch einen DIV-Container drumherum gesetzt:

<div style='width:100%;height:100%;display:flex;align-items:center;justify-content:center'>

Der bekommt als Eigenschaften die Breite von 100% (uns unbekannte Displaybreite) und die Höhe von 100% (uns unbekannte Displayhöhe).
In dem Container platzieren wir unser bisheriges HTML. Dann schließen wir den Container mit:

</div>

"display:flex;" sorgt dafür, dass der Browser Kenntnis erhält, wie er mit unserem Layout innerhalb des Containers und mit dem Container umgehen soll (Flex-Container)
"align-items:center;" zentriert alle Elemente (vertikal)
"justify-content:center;" zentriert alle Elemente (horizontal)



MfG

[inka]

seltsam, dass meine links alle funktionieren. wahrscheinlich liegt es daran, dass ich keine conrad-links verschicke. und du kannst ruhig davon ausgehen, dass ich dinge überprüfe bevor ich was behaupte...
btw. den ESP hatte ich schon, wg. Wifi...

[Rabenauge]

Das mit den Conrad-Links ist nichts neues..aber wer kauft da auch, hehe.
Die meisten anderen funktionieren- ich setze ja auch hin und wieder einen....

Hab mir dein Dokument mal angesehen....du willst BT _und_ Wifi nutzen?
Auch, wenn mir nicht ganz klar ist, warum beides- wieso nimmst du dann nicht einfach nen RasPi?
Schon der ZeroW hat beides an Bord...und kostet nun wirklich nicht die Welt (um die 15 Mäuse).

Linux kennst du ja eh schon (sehr hilfreich, wenn man mit RasPi's spielt)...den Mega kannst du trotzdem die Steuerung der Antriebe machen lassen. Das können die besser als ein Pi, zumindest, wenn man den mit Python programmiert.
Ne Kamera könntest du dann auch ganz einfach noch an Bord holen...

[inka]

Hab mir dein Dokument mal angesehen....du willst BT _und_ Wifi nutzen?
Auch, wenn mir nicht ganz klar ist, warum beides- wieso nimmst du dann nicht einfach nen RasPi?
Schon der ZeroW hat beides an Bord...und kostet nun wirklich nicht die Welt (um die 15 Mäuse).

Ich bin nicht sicher was und wann sinnvoll ist, wollte mir beide möglichkeiten offen halten...
Und - ich hatte den eindruck, dass es hier von manchem als zu viel des guten gesehen wird wenn man schon den ESP nimmt und den nicht in allen belangen nutzt - und den RasPi? Ein overshoot ohne gleichen, oder? Einen hätte ich ja auch bereits

habe ich mir 2012 mal gekauft, nur ein bischen damit rumgespielt, also nicht richtig warm geworden damit. Wahrscheinlich schon total veraltet...

Linux kennst du ja eh schon (sehr hilfreich, wenn man mit RasPi's spielt)...den Mega kannst du trotzdem die Steuerung der Antriebe machen lassen. Das können die besser als ein Pi, zumindest, wenn man den mit Python programmiert.

Das ist aber kein muss mit python?

Ne Kamera könntest du dann auch ganz einfach noch an Bord holen...

das ist allerdings ein argument. Also nach ZeroW suchen? Oder doch was anderes?

[morob]

ob du den zero nimmst oder den alten rpi ist das gleiche, beide haben nur 1 cpu und beide haben wahrscheinlich 512mb, eventeull hat der alte auch nur 256mb, was bei kamera nutzung dann nur noch 128mb sind.

[inka]

ob du den zero nimmst oder den alten rpi ist das gleiche, beide haben nur 1 cpu und beide haben wahrscheinlich 512mb, eventeull hat der alte auch nur 256mb, was bei kamera nutzung dann nur noch 128mb sind.

ich habe jetzt einen zeroW bestellt , es dauer ein paar tage bis der kommt...

Das zusammenfügen der zwei codeteile hat gut funktioniert, muss noch die eingestellten entfernungen ausgiebig testen. Den mittleren vorderen US-sensor wollte ich nach "schräg-unten" ausrichten und so mögliche "negative hindernisse" im boden messen zu können. Bin gespannt ob und wie das funktioniert - gottseidank funktioniert nun die fernbedienung, die ich im notfall als bremse einsetzen kann...

Frage: hat schon jemand versucht von einem HC SR04 einen ping zu schicken und den von einem anderen SR04 zu empfangen?

[inka]

das erinnert so bischen an die RP6 zeiten (so 2010), wo das ganze kompilieren und flashen von der Kommandozeile aus erfolgte 🤨 - fand ich persönlich nicht so toll...

- - - Aktualisiert - - -

würde sich für die umschaltung der RX/TX paare so etwas eignen?

[inka]

ich habe mir die ideen und vorschläge angeschaut und versucht sie nachzuvollziehen. Das ergebnis sieht so aus:

hinzu:
#include <TimerOne.h>

im setup hinzu:
  Timer1.initialize(4000);
  Timer1.attachInterrupt(stepper_isr);

in loop entfällt:
    stepper_VL.run();
    stepper_HL.run();
    stepper_VR.run();
    stepper_HR.run();

isr funktion hinzu:
void stepper_isr(void)
{
  stepper_VL.run();
  stepper_HL.run();
  stepper_VR.run();
  stepper_HR.run();
}

und es funktioniert meine furcht vor den ISR's war wohl übertrieben - natürlich habe ich den einfachsten weg gewählt, die idee mit der lib (danke Rabenauge) und die ausführlichen beschreibungen des geschehens bei der verwendung von der accelstepper lib (danke Klebwachs) haben mir sehr geholfen. Ich habe ganz sicher nicht die ganze tiefe der ISR-problematik damit erfasst, nur ein bischen an der oberfläche gekratzt, für den moment ist mein problem des stotternden antriebs gelöst und ich kann mich anderen kleinigkeiten wieder zuwenden...

danke nochmals

[inka]

so wie es auf dem foto zu sehen ist...

EDIT:

Auf dem Akkuaufkleber steht zwar "Polymer", scheint aber nach dem Ladegerät und dem Aufbau ein Li-Ion zu sein. Einen LiPo mit Schalter habe ich noch nicht gesehen.

auf dem original aufkleber steht nichts mehr von polymer...