Arduino-Messsystem zur Gewichtsausgabe: Biegebalken mit Dehnungsmessstreifen

Hallo zusammen,

ich habe ein Projekt von der Uni bekommen. Im Team sind wir alle Anfänger und kommen momentan nicht weiter.

Das Messsystem besteht aus einem Biegebalken mit jeweils einem Dehnungsmessstreifen (DMS) auf der Ober- und Unterseite des Balkens. Für die Auswertung benötigen wir ja eine Wheatstone'sche Brücke. Wir haben also eine Halbbrücke, bestehend aus den 2 DMS und 2 Ergänzungswiderstände mit dem (Nenn-)Wert 120 Ohm. Wir messen so die Spannungsdifferenz zwischen den Spannungsteilern der Brücke und dieses Signal wird erstmal mithilfe eines Instrumentenverstärkers verstärkt, bevor es in den Arduino geht.

Gemessen wird es vom 1. Analogeingang. Der Wert schwankt richtig, aber dieses Problem haben wir mithilfe des Befehls "Mode" beseitigt, so dass die Ausreißer (meistens) gar nicht vorkommen. Wir haben das ganze System dann auch kalibriert, haben eine Funktion für das Gewicht in Abhängigkeit von der abgelesenen "Bit-Zahl" aus dem Analogeingang erstellt. Die lineare Funktion steht auch in dem Code des Programms. Ausgegeben wird das Gewicht von der hängenden Masse und die maximale Durchbiegung des Balkens, und zwar auf einem Bildschirm. So kriegen wir auch richtige Ergebnisse mit guter Genauigkeit. zB bei einem Gewicht von 1kg wird 1,10 angezeigt. Bei 8,5 kg wird 8,54 angezeigt.

Das Problem ist, wenn wir alles abbauen und wieder aufbauen, funktioniert nichts mehr. Die erstellte Funktion passt überhaupt nicht mehr... Das Problem lässt sich beseitigen, wenn man das ganze wieder neu kalibriert. Kann mir jemand erklären warum das so ist? Stimmt das, dass so ein Problem öfters vorkommt?

Als Info: Die Schaltung ist eigentlich schon komplett gelötet. Also mit "wieder aufbauen" wird gemeint, dass wir den Instrumentenverstärker zur Spannungsversorgung an einer Batterie anschließen und den Biegebalken mit einem Schraubstock am Tisch befestigen.

Vielen Dank schon mal! :slight_smile:

Liebe Grüße,
Farah

fshavira:
Vielen Dank schon mal! :slight_smile:

Du schreibst zwar ziemlich ausführlich, was wie geht (oder auch nicht), zeigst aber weder Schaltung noch Programm. Könntest Du das noch nachreichen?

Gruß

Gregor

Hier sind der Schaltplan und der Programmcode :slight_smile:

Danke! :slight_smile:

Hoppla! Der Schaltplan wurde nicht mit hochgeladen. Hier ist der.

fshavira:
... der Programmcode :slight_smile:

... als Bild kommt das witzig :slight_smile: Könntest Du noch den Schaltplan hochladen?

Gruß

Gregor

Ja, das Programm ist auf dem Laptop vom Teammitglied :o hab eben nur dieses Bild bekommen. Der Schaltplan wurde jetzt auch hochgeladen. Die Datei war wohl zu groß.

Vielen Dank für die Hilfsbereitschaft :slight_smile:

fshavira:
... Der Schaltplan wurde jetzt auch hochgeladen. Die Datei war wohl zu groß.

Auf den ersten schnellen Blick sehe ich nichts Schlimmes (da sollte zumindest nichts Katastrophales drin sein).

Woher stammt Average.h? Scheint mir keine „Arduino-Standardbibliothek“ zu sein.
Und was genau meinst Du mit „ab- und aufbauen“ (das, wonach erst mal nichts mehr funktioniert)? Wenn alles funktioniert, solange Du nur mal den Arduino aus- und wieder einschaltest, liegt es zumindest nicht an der Software :slight_smile:

Gruß

Gregor

Average.h haben wir aus dieser Seite: GitHub - MajenkoLibraries/Average: Templated class for calculating averages and statistics of data sets.

Also, wenn wir Feierabend machen, müssen wir die ganzen Sachen bei unserem Betreuer abgeben. Wie gesagt, die ganze Schaltung ist eigentlich gelötet, also es wird nichts an der Schaltung geändert. Wenn wir einen neuen Test starten möchten, müssen wir nur noch den Instrumentenverstärker an einer Batterie anschließen. Damit ist die Schaltung auch schon vollständig. Und halt den Balken am Tisch mit einem Schraubstock befestigen. Das meine ich mit "aufbauen". Also, dass die Abweichung wegen einer veränderten Schaltung, kann man denk ich ausschließen...

Ich glaube aber, dass die Abweichung definitiv nicht vom Temperaturunterschied stammen kann, da:

  1. Wir machen das immer im selben Raum, und die Temperatur kann sich nicht viel ändern
  2. Wenn's funktioniert kriegen wir beispielsweise im unbelasteten Fall 0,06kg. Wenn wir das ganze so wie es ist lassen und am nächsten tag wieder testen kriegen wir -5kg.
    Also ich glaube nicht, dass die Temperaturänderung so eine Abweichung verursacht.

Wir haben jetzt schon 5-mal an 5 verschiedenen Tagen kalibrieren müssen... Hier ist noch ein Bild von den Messwerten Bit-Zahl in Abhängigkeit von dem Gewicht in kg. Wie du sehen kannst, manchmal kommt eine Bit-Zahl von 318 und mal so hoch wie 378 im unbelasteten Fall. Ich glaube eine Funktion aus den Mittelwerten zu erstellen würd auch nicht viel helfen, weil wie du siehst, 318 oder 378 ist noch ein Stückchen weit weg von 345.

Könnte es denn weitere Gründe geben? Hast du denn ähnliche Probleme schon mal gehabt? Auch wenn am Ende das Messsystem nicht 100%ig funktioniert, müssen wir im Bericht begründen woran es vielleicht gescheitert hat und ggf. Optimierungsmöglichkeiten vorschlagen. Also deine Erfahrungen bei einem ähnlichen Problem könnten mir auch weiterhelfen :slight_smile:

Ich danke dir vielmals für die schnelle Antwort :slight_smile:

Wie Du das beschreibst, liegt es wohl nicht am Aufbau. Derartige Abweichungen sind saublöd.

Was solche „Effekte" angeht: Denen begegne ich fast täglich. Fluchen hilft :slight_smile:

Was mir aufgefallen ist: Es wird mit Werten gerechnet, die ziemlich groß [sind|werden können]. Habt Ihr schon geprüft, dass die benutzten Variablentypen mit solchen Werten umgehen können? Sind Rundungsfehler ausgeschlossen?

Mit Dehnungsmessstreifen kenne ich mich halt ü-ber-haupt nicht aus. Ich habe nur gesehen, dass wohl eher niedrige Widerstandswerte zum Einsatz kommen und die Änderung(en) der Messgrößen sehr klein sein können (weshalb sie wohl verstärkt werden müssen).

Mit anderen Worten: Mir fällt gerade nichts Sinnvolles ein. Sollte sich das in den nächsten 1-2 Stunden ändern, erfährst Du das.

Gruß

Gregor

Entschuldige die (vielleicht wahrscheinlich) dumme Frage. Wir sind Maschinenbaustudenten, die so gut wie kein Hintergrundwissen in Informatik oder Elektrotechnik haben :cold_sweat:

Meinst du damit die Variablentypen float und int, die wir benutzt haben? Also wie ich das verstanden habe, ist int für ganze Zahlen von -32000 bis +32000irgendwas. Und float geht ja bis 10^8, auch ins negative. Sollte doch passen oder? Oder meinst du damit was ganz anders?

fshavira:
Entschuldige die (vielleicht wahrscheinlich) dumme Frage.
...
Meinst du damit die Variablentypen float und int, die wir benutzt haben?...

Ja, die meine ich. In diesem Wikipedia-Artikel steht einiges dazu. Ich weiß nicht, wie viele Stellen die Mantisse (das bla bei „bla hoch zwei“) in (Arduino-)C haben kann/darf. Dafür (und damit) kenne ich mich zu wenig aus.

Gruß

Gregor

Nachtrag:
Ein schnell zusammengehacktes Programm ergibt, dass die Genauigkeit bei „double“ noch einige Stellen weiter reicht. Tauscht das mal aus (float zu double machen) und messt damit.

In meinem Testprogramm habe ich zwei Variablen definiert:

float foo=3.123456789012345678901234567890;
double bar=3.123456789012345678901234567890;

Bei der Ausgabe wurde daraus:

foo='3.1234567165374755859375'
bar='3.123456789012345691247674039914272725582122802734375'

Da der Aufbauplan identisch ist, geht es offensichtlich um den selben Aufbau wie vor zwei,drei Wochen: Dehnungsmessstreifen mit Arduino auslesen

Leider wurde damals nicht geschrieben, ob es eine Lösung gab. Jedenfalls wäre es wohl sehr sinnvoll, wenn ihr euch mit der anderen Praktikumsgruppe kurzschließen würdet.

Im Programm sehe ich analogRead(1);, im Schaltplan ist aber A0 angeschlossen. Ist das ein Fehler in der Doku oder in Real?

gregorss:
Ein schnell zusammengehacktes Programm ergibt, dass die Genauigkeit bei „double“ noch einige Stellen weiter reicht. Tauscht das mal aus (float zu double machen) und messt damit.

Double ist eigentlich nur auf dem ARM was anderes als float

https://www.arduino.cc/en/Reference/Double

Ansonsten gilt natürlich, dass Gleitkommazahlen zwar einen sehr weiten Wertebereich haben (rein nach oben und unten), aber die Anzahl der Bits ist endlich, wodurch bei weitem nicht alle Zahlen dargestellt werden können.

0.0492366266 als float ((239.5 * 239.5 * 239.5) * 9.81 ) / (3.0 * 210000.0 * 4344.67):
0,0492366182 Taschenrechner

Da reden wir aber über Genauigkeit, nicht über Reproduzierbarkeit von heute auf morgen.

Kritischer erscheint mir der geringe Meßbereich von 347 bis 403, da doch ein Instrumentenverstärker davor geschaltet ist. Der schafft keine 0 bis 5 V, sondern nur 0,2 V?

Wenn ich die Spannung an A0 zwischen 0 und 5 V ändere, bekomme ich an meinem UNO an A1 Werte zwischen 373 und 403 ... :wink: Morgen könnte das andere Werte ergeben :sleeping:

gregorss:
Ja, die meine ich. In diesem Wikipedia-Artikel steht einiges dazu. Ich weiß nicht, wie viele Stellen die Mantisse (das bla bei „bla hoch zwei“) in (Arduino-)C haben kann/darf. Dafür (und damit) kenne ich mich zu wenig aus.

Gruß

Gregor

Nachtrag:
Ein schnell zusammengehacktes Programm ergibt, dass die Genauigkeit bei „double“ noch einige Stellen weiter reicht. Tauscht das mal aus (float zu double machen) und messt damit.

In meinem Testprogramm habe ich zwei Variablen definiert:

float foo=3.123456789012345678901234567890;

double bar=3.123456789012345678901234567890;




Bei der Ausgabe wurde daraus:



foo='3.1234567165374755859375'
bar='3.123456789012345691247674039914272725582122802734375'

Meines Wissens sind float und double baim Arduino der gleiche Variablentyp. Eine 4 Bit Gleitkommazahl, die nur auf 6 bis 7 Stellen genau ist. Ein long ist da genauer.

Grüße Uwe

@fshavira

  1. Wie ist der Balken gebaut. Kann da durch erneutes Einspannen die Hebellänge verändert werden bzw umgekehrt (oben / unten) eingespannt werden?
  2. Was ein Problem ist es, nach dem Einschalten 10 Sekunden zu warten und dann den Nullwert des unbelasteten Balkens zu messen und diesen als Referenzwert zu verwenden? Auch kann man programmieren daß anschließend ein referenzgewicht angehängt werden muß und dadura automatisch den Offset und die Steigung zu berechnen.
  3. Zeig mal den Sketch (aber nicht abfotografieren)

Grüße Uwe

Serenifly:
Double ist eigentlich nur auf dem ARM was anderes als float
https://www.arduino.cc/en/Reference/Double

Das wusste ich noch nicht. Dann ist mein Vorschlag, von float auf double umzustellen, total für den A.

Gruß

Gregor

Für physikalische Größen, die mit 10 Bit Auflösung gemessen werden, reicht die Genauigkeit von float (mit 23 bit Mantisse) in der Regel dicke. Selbst die 10 bit (0 .. 1023) Messbereich liegen in der Regel über der Genauigkeit der eigentlichen Sensoren und Messverfahren...

Kritischer erscheint mir der geringe Meßbereich von 347 bis 403

Tja, das sind nur 26 bit... oder 1,5% Auflösung.

Aber wenn die Ursache dies ist:

Wenn ich die Spannung an A0 zwischen 0 und 5 V ändere, bekomme ich an meinem UNO an A1 Werte zwischen 373 und 403 ... :wink:

Da fällt mir nur ein, dass manche Leute nicht damit zufrieden sind, einen offenen Analogeingang als Randomseed zu verwenden :grin:

Unsere zukünftige Elite ist merkwürdig sprachlos, was Spekulationen Raum gibt. :wink: