Digitale Wasserwaage (ehem. Multitool: Laserwasserwaage)

Hallo zusammen,

entgegen der Huhn oder Ei-Frage, ist der Sachverhalt klar!
Das Zeug war zuerst da und sucht jetzt eine Bestimmung.

Um was geht´s?
Bei einem großen Onlineversandhandel aus China stachen mir rote Laserdioden ins Auge, welche für wenige Cent, wahlweise Punkt, Strich oder Kreuz an die Wand werfen.
Ohne zu wissen welchen Zweck sie erfüllen könnten, sind je zwei pro Bauart erst in meinen Warenkorb und wenige Woche später in den Briefkasten gewandert.

Was nu?
Da ich noch eine Vielzahl von EPS32 und ESP8266 mit OLED Onboard habe, ein Gyro-Shield (GY-291) und Entfernungsmesser (HC-SR04), war die Idee geboren eine digitale Wasserwaage zu basteln.
Mit coolen Zusatzfeatures, versteht sich!

Ein 18650 Akku soll zur Bestromung beitragen und eine Hülle aus dem 3D Drucker das ganze Gerumpel robust zusammenhalten.
Ggf. hält noch ein Piezo einzug, der akustisch die Annäherung an die Waage untermalt.
So könnte man unterstützt Bilder gerade aufhängen, den Wohnwagen ausrichten (ohne ständig zwischen Kurbel und Tür hin und her zu laufen), grob Entfernungen "messen" und Winkel darstellen.

Soweit der naive, unausgegorene Plan!

Welche Ideen hättet Ihr noch? Lasst Eurer Kreativität freien Lauf!

Zuerst sollte man nur Laser mit weniger als 1mW so nackt durch die Gegend schicken. 50mW sind zuviel.
Außerdem verstehe ich nicht was Du mit dem Laser machen willst.

Wennschon nimmst Du den Beschleunigungsmesser und montierst diesen fest auf den Wohnwaagen. Mit den ESP mit Display kannst Du eine Handanzeige bauen, die die Meßdaten darstellt. Da braucht es keine Laser. Alternativ kannst Du auch ein Händy als Anzeige vewenden.

Vieleicht hat jemand eine gute Idee für die Verwendung von Deinen Lasern.

Grüße Uwe

TriB:
Bei einem großen Onlineversandhandel aus China stachen mir rote Laserdioden ins Auge,

Das können Sie. Wortwörtlich.

Du bist Dir schon bewusst, das Du mit einem 50mW / 650nm Laser die Klasse 3B erfüllst und damit potentiell eine Gefahr für Deine Mitmenschen gegeben ist?
Nicht ohne Grund ist der Vertrieb in D für diese Leistungsklasse reglementiert.

Was nu?
Da ich noch eine Vielzahl von EPS32 und ESP8266 mit OLED Onboard habe, ein Gyro-Shield (GY-291) und Entfernungsmesser (HC-SR04), war die Idee geboren eine digitale Wasserwaage zu basteln.

Welche Ideen hättet Ihr noch? Lasst Eurer Kreativität freien Lauf!

Ich hätte die Idee, das Projekt zu begraben.
Der HC-SR04 ist zudem nicht für den Aussenbereich geeignet.
Selbst auf ner Baustelle mit Staub und Dreck ist da schnell Schluss.

Hallo,
danke für Euer Feedback!

Die Idee war nicht auf eine Baustelle zu gehen und professionelle Tools (die es schließlich allesamt bereits gibt) zu ersetzen, sondern mir ein Spielzeug für den privatgebrauch zu basteln. Staub sollte zumindest keine große Rolle spielen.
Der Außenbereich auch nicht wirklich.

Mit dem Kreuz- oder Linien-Laser wollte ich einen Strich an die Wand projizieren, welcher dann über das Display in Waage ausgerichtet werden kann. Einfach zum Bilder aufhängen, o.ä.
Bei grobschlächtigen Messungen, wo die Distanz nicht so groß ist und es nicht auf den Millimeter (oder gar einen cm) ankommt, auch mal was ausmessen.

Über die Klasse der Laser habe ich mir aber tatsächlich keine Gedanken (und ehrlich gesagt auch erstmal keine Sorgen) gemacht!
Guter Einwand und danke dafür!
Lese mich mal in die Thematik ein und ja, ich weiß das hätte ich eigentlich vorher tun sollen :zipper_mouth_face:

PS: Je länger ich darüber nachdenke, ist die Idee von Uwe eigentlich ohnehin viel praktischer! Wenn ich einen Gyro + ESP32 fest in den WoWa verbaue, kann ich ihn auch nicht vergessen. Und mit Bluetooth bin ich flexibel, wie ich das Ergebnis anzeige 8)
Das wird, unabhängig des Ergebnisses mit den Lasern umgesetzt!

also beim Wohnwagen würde ich einfach bei jeder Kurbel/Stütze eine Kreuzwasserwage im Sichtfeld montieren. Das funktioniert in der Regel ohne Batterie, ohne Smartphone, ohne Display,...

noiasca:
bei jeder Kurbel/Stütze eine Kreuzwasserwage im Sichtfeld montieren.

Dosenlibelle :wink:

wenn du bei der Stütze was was waagrechtes hast wo du sie draufkleben kannst und von oben siehst ohne dass du dir den Kopf verrenkst - gerne.

Da ist mir aber der alljährliche Wechsel der Luftblase zu teuer und aufwändig :stuck_out_tongue:

Das Problem hierbei ist, dass es kaum/keine Fixpunkte gibt, die in Waage sind. Weder die Deichsel, noch die Träger im Unterboden eignen sich als Messpunkte. => Und ist schwer abzulesen, wie noiasca korrekt bemerkt hat.
Deshalb wird i.d.R. drin gemessen. Entweder mittig auf dem Boden oder z.B. auf der Küche.
Oder beim Auffahren auf einen Keil, wäre es sogar praktisch im Auto zu sehen, wie der WoWa steht.

Der ESP landet dann einfach in Batterienähe mit Wandler & Trennschalter, wird einmalig Nullgesetzt, wenn der WoWa in Waage ist und fertig ist die Laube.

Bin entrüstet, dass in einem Arduino-Forum überhaupt in Frage gestellt wird, ob es Sinnhaft ist eine analoge Lösung durch eine vollkommen überzogene digitale Lösung zu ersetzen :grinning:

Das WoWa-Problem löse ich auf sehr altmodische Weise: Ich nehme meine schönere Hälfte mit. Die kann beides: Eine Wasserwaage ablesen und akustisch kommunizieren

Ein ähnliches Modell hätte ich ebenfalls im Angebot. Wenn ich die aber "altmodisch" nenne, bekomme ich Ärger! :confused:

Ist aber nicht immer mit dabei oder gesellt sich erst ins gemachte (und aus tarierte) Nest dazu.

Habe auch schon ein paar Projekte gefunden, die selbiges umgesetzt haben. Z.B. dieses hier.
Der interessante Teil wird wohl die Datenkommunikation an das Smartphone werden. Per Bluetooth benötigt man ja eine App. Per WLAN könnte man eine Seite hosten, welche dann laufend die Werte aktualisiert und darstellt.

Huch. Bei meinem Post fehlt der sachliche Teil:
Laser werden auch gerne in der Modellbauwerkstatt zum Ausrichten von Rümpfen und Leitwerken eingesetzt.
Allerdings muss der da nur Leuchten, einen Arduino braucht es da nicht.
Vielleicht einen ESP und Alexa-Anbindung zum Schalten :slight_smile:

noiasca:
also beim Wohnwagen würde ich einfach bei jeder Kurbel/Stütze eine Kreuzwasserwage im Sichtfeld montieren. Das funktioniert in der Regel ohne Batterie, ohne Smartphone, ohne Display,...

Spielverderber.
Wieso gibst Du für ein hochaktuelles hochtechniches Problem, das leicht zu einen schiefen Wohnwaagen und zusätzlich zu einem schiefen Haussegen führen kann, eine so einfache passive Lösung ? :wink: :wink:

Grüße Uwe

wno158:
Laser werden auch gerne in der Modellbauwerkstatt zum Ausrichten von Rümpfen und Leitwerken eingesetzt.

Genau dieser Laser möchte aber exakt ausgerichtet sein um etwas zu vermessen :slight_smile:
Dazu meine Idee das ganze mit dem Gyro zu kombinieren...

Heute Abend musste ich aber nochmal kurz am Wohnwagen-Ausrichtungsprojekt schrauben.
Die Lernkurve zu SPIFFS war steil und kurz.
Der ESP32 liefert mir eine HTML-Seite, welche alle 500ms per WebRequest die Winkel abruft. Die Darstellung erfolgt noch in einfachen Textboxen, sollen aber durch sprechende Grafiken ersetzt werden.
Die Rückgabewerte des ADXL345 waren mir nicht ganz schlüssig. Auch die verschiedensten Tutorials waren sich nicht ganz einig. Also habe ich mir einen rechten Winkel gesucht und die Werte notiert.
Per map() dann einfach gerade gezogen. Scheint auch gut zu passen!
Was noch nicht funktioniert hat, ist der AccessPoint. In ein WLAN einwählen klappt. Stelle ich einen AP und verbinde mich, "panicked" der ESP :frowning:

Darum werde ich mich morgen weiter kümmern!
Was ich super fänd, wäre dass sich nach dem Verbinden automatisch die Webseite öffnet. Nach etwas Recherche habe ich auch einen Weg gefunden. Muss ihn nur noch vom 8266 auf den 32 portieren und das o.g. Problem mit dem AP lösen.
Das Zauberwort ist Captive Portal.

EDIT: Es gibt für das Captive Portal sogar einen Beispiel Sketch für den ESP32 (Unter DNSServer).
Dort wurde dann auch klar woran das Problem lag:
WebServer != WiFiServer
Der WiFiServer hat aber keine elegante on()-Methode. Mal sehen wir ich das kombiniere.

Soooo, die Seite ist mehr oder weniger fertig!

Sie liegt zusammen mit dem favicon, JavaScript und CSS im SPIFFS.
Alle 500ms wird ein request abgesendet und die "Wasserblasen" aktualisiert.
Der Button "Calibrate" speichert die aktuellen X-& Y-Werte.

Vorher hatte ich mit die Min- & Max-Werte gespeichert, wenn der Gyro bei -90° und +90° war und gemappt.
Das ist aber natürlich quatsch, wie sich schnell herausgestellt hat! Eine echte Wasserwage "schlägt" schon bei ~2° an und die Blase komprimiert sich bei ca. 10°, so dass sie an der inneren Linie abschließt.
Das habe ich nun erstmal als Richtwert genommen und das Ergebnis sieht deutlich besser aus!

Trotzdem übermittle ich noch den anfänglichen Wertebereich -90 bis +90. Da muss ich mir mal Gedanken machen, wie ich den Wertebereich festlege und die Anzeige sinnvoll gestalte.

Zu guter Letzt war da noch dieses CapativePortal. Meine Vermutung mit dem WebClient vs. WiFiClient war verkehrt. Der "Panic" des ESP´s lag an der falschen Reihenfolge von:

// Create SoftAP
  WiFi.mode(WIFI_AP);      
  WiFi.softAP("Caravan Leveler");  
  delay(500);
  WiFi.softAPConfig(local_ip, gateway, subnet)

So herum gehts, setzt man die Config zuerst, knallt es.

Auf meinem neueren Android klappt auch alles wie gewünscht. Auf einem älteren Testgerät unterstützt die Authentifikationsseite kein JS.
Das iPhone funktioniert ebenfalls tadellos.

Nun erfolgt noch ein Code-Cleanup und ich stelle die Scripte und den Sketch hier rein.

TriB:
Soooo, die Seite ist mehr oder weniger fertig!

//s12.directupload.net/images

Bitte hänge die Grafik hier ran - ich seh sie nicht und irgendwann ist das da auch verschwunden. Dann sieht es keiner mehr.

Nun erfolgt noch ein Code-Cleanup und ich stelle die Scripte und den Sketch hier rein.

Dann mal gleich als Hinweis:
Es gibt einen Thread "Zeigt her Eure geilen Projekte" Zeigt her eure geilen Projekte! - Deutsch - Arduino Forum
Die Vorstellung dort mit Verweis auf diesen Thread - und hier den Verweis dorthin wäre die optimale Ergänzung.

Und weiter geht´s!

Die GUI wurde noch etwas überarbeitet, ein Gehäuse gedruckt (was aber noch nicht 100%ig passt) und mit der Berechnung gespielt.
Da bin ich aber immer noch ziemlich unzufrieden:

Der ADXL345 liefert in Waage
X -6.35
Y -1,05
Das speichere ich mir als integer. Um den Endpunkt der Wasserblase zu berechnen, habe ich eine echte Wasserwaage genommen und gemessen wann die Blase am ersten Ring anliegt.
Sowohl bei X als auch bei Y war das bei rund 2,00 Differenz zum Nullpunkt.

Beim rumspielen erschien mir das etwas zu ungenau und zu nervös. Also habe ich mich bei 1,50 eingependelt:

int levelXcalibration = -635;
int levelYcalibration = -105;
uint8_t levelOffset = 150;
void getLevel() {
  sensors_event_t event;
  accel.getEvent(&event);

  float x, y, z;
  x = event.acceleration.x;
  y = event.acceleration.y;
  z = event.acceleration.z;

  //Set a factor to let the "bubble" reach the end on about 5° (instead of 90°)
  levelX = map(x * 100, levelXcalibration - levelOffset, levelXcalibration + levelOffset, -90, 90);
  levelY = map(y * 100, levelYcalibration - levelOffset, levelYcalibration + levelOffset, -90, 90);

  Serial.print("X: ");
  Serial.print(levelX);
  Serial.print(" Y: ");
  Serial.println(levelY);
}

Das optische Ergebnis wirkt ganz passabel. Auch kann ich in jeder Position kalibrieren und erhalte das gewünschte Resultat.

Aber:
Diese korrigierten Werte sind nun natürlich vollkommener Quatsch! Die Anzeige auf der Webseite schlägt bei 90 an, was nicht im entferntesten mit dem Winkel zu tun hat.
Besser wäre es natürlich die tatsächlichen Grad zu übermitteln und auf der Webseite den Anschlag zu definieren.

Dann müsste ich jedoch wieder die genauen Werte bei -90 & +90 Grad kennen um vernünftig kalibrieren zu können. Und von int auf float umstellen, da der interessante Bereich nur zwischen etwa 0-2° stattfindet.

Oder ich lasse alles, wie es ist und blende die Zahlen einfach aus...

So sieht es aktuell aus. Wenn ich kalibriert habe, werden die Daten auf dem Button angezeigt.
Tippe ich auf den Offset, wird der Slider eingeblendet und ich kann den Wert auf dem ESP aktualisieren:

Besser wäre es natürlich die tatsächlichen Grad zu übermitteln und auf der Webseite den Anschlag zu definieren.

Dann müsste ich jedoch wieder die genauen Werte bei -90 & +90 Grad kennen um vernünftig kalibrieren zu können. Und von int auf float umstellen, da der interessante Bereich nur zwischen etwa 0-2° stattfindet

Keine Ahnung was du mit einer Gradzahl anfangen willst.
Und zum Kalibrieren höchstens einen Bereich von +- 5% Steigung verwenden.

Wenn überhaupt, wären evtl. Ausgaben in mm (oder cm?) sinnvoll (wie viel höher/tiefer die eine Seite als die andere sein müsste, damit die Kiste waagerecht steht). Natürlich individuell unterschiedlich zwischen längs und quer.

Aber die graphische Wasserwaagen-Anzeige gefällt mir gut.

thisThreadIsWorthlessWithoutSketch.gif

thisThreadIsWorthlessWithoutSketch.gif

michael_x:
Keine Ahnung was du mit einer Gradzahl anfangen willst.
Und zum Kalibrieren höchstens einen Bereich von +- 5% Steigung verwenden.

Wenn überhaupt, wären evtl. Ausgaben in mm (oder cm?) sinnvoll (wie viel höher/tiefer die eine Seite als die andere sein müsste, damit die Kiste waagerecht steht). Natürlich individuell unterschiedlich zwischen längs und quer.

Aber die graphische Wasserwaagen-Anzeige gefällt mir gut.

Danke :smiley:

Tja, das ist ja genau meine Überlegung. Ob ich dort die exakten Grad 0-2° sehe oder wie jetzt gemappt 0-90, spielt eigentlich keine Rolle. Sind ja "nur" Zahlen. Die " 0 " ist das Ziel! Daher lasse ich es vielleicht einfach so und blende die Werte einfach aus.
Ui, die Idee mit den Zentimetern ist natürlich auch super! Die Kalibrierung dann aber wohl der Horror :o

Habe nun V2 des Gehäuses prototypisch ausgedruckt. Leider hat sich der Deckel verzogen und ich muss nochmal ein paar "Pinne" optimieren.

3D Case.png

Drin ist der Spannungswandler und der Gyro. Darüber trohnt der ESP, dessen USB rausgeführt ist.
Das Loch an der Seite ist dann für die Kabeldurchführung gedacht.

@noiasca
Halbfertig macht das noch wenig Sinn 8) Die aktuell problematische Stelle wurde ja auch so klar.
Denke alles Skripte, Sketch, 3D-File, usw. kommen am Montag im Laufe des Tages.

3D Case.png

Tach zusammen,

da hat es doch mal wieder länger gedauert als erwartet :slight_smile:
Mich hat es nach wie vor gewurmt, dass man keinen Bezug zu den dargestellten Werten hat.
Die einzig korrekte Lösung war es, alles auf Grad (-90.0 bis +90.0) umzustellen und dann den Darstellungsbereich festzulegen.

Das hat auch lediglich dazu geführt, alles komplett umzuschreiben :o

Nachdem das geschafft war, musste die Kalibrierung einem neuen Ansatz weichen:
Die Adafruit_ADXL345_U-Library liefert float-Werte. Man kann aber auch einfach per getX() auf die integer Werte zugreifen.
Die Wertebereiche wurden festgelegt, in dem ich einfach auf -90 & +90 Grad gelevelt habe.
Das waren in meinem Fall X: -432 bis 109 Y: -287 bis 247.
Entspricht einem Wertebereich von 541 / 533. Geteilt durch zwei, erhalten wir den Bereich für 90°.
Passt nicht 100%ig, aber sollte für die Genauigkeit ausreichen.

Zu guter Letzt muss noch auf Null gelevelt werden, in dem man den rohen Wert in Waage speichert und vom Wertebereich abzieht (bzw. drauf rechnet).

In Code gesprochen:

int calibrationX = -150;
int calibrationY = -25;
int valuationX = 271;
int valuationY = 267;

void getLevel() {
  int x = accel.getX();
  int y = accel.getY();
  int z = accel.getZ();
  //-90 -> +90
  //-432 -> 109 / -287 -> 247
  //541 / 533
  //Divide by 2

  //Zero
  //-150 / -25
  levelX = map(x, (valuationX - calibrationX) * -1, (valuationX + calibrationX), -900, 900);
  levelY = map(y, (valuationY - calibrationY) * -1, (valuationY + calibrationY), -900, 900);
}

Die "900" werden dann im JavaScript noch durch 10 geteilt, um die passende Genauigkeit zu erhalten.

Das Ergebnis ist okay! Muss nochmal im Wohnwagen selbst ausprobiert werden, aber mein 12V Stecker ist noch nicht angekommen.
Der Rest ist dann noch Feinjustierung.

Im Prinzip ist alles an HTML und JavaScript nur "für Schön". Die Kernfunktion ist einfach einen WebRequest abzusetzen und entsprechend Werte zu übermitteln oder das Ergebnis zu verarbeiten.
Im Falle der Festlegung für die Wertebereiche sähe das dann so aus:

function Valuation(){
    var oRequest = new XMLHttpRequest();
    var sURL  = '/valuation?x=';
    sURL += document.getElementById("ValutationX").value;
    sURL += '&y=';
    sURL += document.getElementById("ValutationY").value;
    oRequest.open("GET",sURL,true);    
    oRequest.onerror = function (e) {SetOutput("Valuation failed!", true);};
    oRequest.send(null);
}

Und das Gegenstück:

webServer.on("/valuation", handle_valuation);
void handle_valuation() {
  // /valuation?x=270&y=267
  Serial.println(F("Handle Valuation"));

  if (webServer.args() == 2) {
    Serial.println(String(F(" ")) + webServer.argName(0) + F(": ") + webServer.arg(0));
    Serial.println(String(F(" ")) + webServer.argName(1) + F(": ") + webServer.arg(1));
    valuationX = webServer.arg(0).toInt();
    valuationY = webServer.arg(1).toInt();
    StoreLevelValuation();
    String txt = "OK (";
    txt.concat(String(valuationX));
    txt.concat("/");
    txt.concat(String(valuationY));
    txt.concat(")");
    webServer.send(200, "text/plain", txt);
    return;
  }
  webServer.send(400, "text/plain", F("Parameter missing or out of Range!"));
}

Den Sketch, HTML, JS & CSS Dateien, samt 3D Druck, Bebilderung und kurzer Anleitung (auf Englisch) habe ich aufgrund der Größe und des Umfangs auf GitHub geschoben:
GitHub / Caravan Leveler

Sofern Ihr das selbst ausprobieren möchte, bedenkt bitte dass auf dem PC ausgeführt, der WebRequest auf den ESP als CrossSiteScripting Attacke gewertet wird.
Entweder übergebt (so wie ich) im onerror Dummy-Werte oder testet direkt auf dem ESP.