Für die Simulation eines Regelsystems brauche Ich ein einfaches Anregungs- und Bewegungsmodell für Haftung und Reibung. Es handelt sich um eine Art von Kupplung, allerdings nicht rotationsorientiert, sondern linear. Aus Messungen ist zu ersehen, daß sich das System durch eine Anordnung aus 3 Blöcken darstellen lassen sollen, welche jeweils mit einer Feder verbunden sind und auf einer Fläche reibend bewegt werden, wobei sie einhaken und haften können, um bei einer bestimmten Spannung wieder weiterzugleiten. Die Blöcke sitzen am Anfang, an Ende und in der Mitte das Modells. Ich brauche also eine Formelbeschreibung für ein Schwingungssystem zweiter Ordnung, mit Dämpfung und einer variablen Beschleunigung, die einmal normal gemass zweiter Ableitung des Weges arbeitet und einmal anders und zwar im Haftungsmodus. Wie formuliert man die Haftung? Eigentlich ist doch dann die Beschleunigung 0, d.h. es ergibt sich keine Änderung der Geschwindigkeit. Andererseits liegt bei Übergang in die Haftung eine sehr hohe Beschleunigung vor, die die vorhandene Geschwindigkeit schlagartig auf 0 bringt. Ich habe mir eine Rechung aufgestellt, die einfach die Beschleunigung unterhalb einer bestimmten GRösse auf 0 setzt - stimmt aber nicht, weil sich keine Schwingung aufbauen kann. Dann habe Ich die Beschleunigung unterhalb einer Geschwindigkeit von z.B. 1cm/s ignoriert und die Geschwindigkeit einfach auf Null gesetzt. Ging auch nicht, weil beim Loslassen keine gültige Beschleunigung zu berechnen war und das Sytem sofort instalbil wurde. Wie macht man sowas?
Hast du versucht die Reibung als zustandsabhängige Kraft zu modellieren? Für die Haftung würde ich ein hysteresiges Modell ausprobieren. LG
Soweit Ich mich an die technische Mechanik Vorlesung erinnere, war es doch so, daß Haftung dadurch gekennzeichnet ist, daß der Gleitreibungskoeffizient gegen Unendlich geht. Den müsst man umschaltbar definieren können, also entsprechend variieren. Das Problem ist dann eher der Übergang zwischen den beiden Modi.
Markus W. schrieb: > Wie macht man sowas? Hast du simulink? Falls ja, damit. Sonst zustandsgleichungen aufstellen und numerisch lösen. Z.b. mit octave. Du brauchst zwingend eine Unterscheidung zwischen Haft und gleitreibung. Je nach Anspruch ein Modell für den stribeck Effekt. Wenn dir die Simulation langsam wird, ist sie falsch, weil es keine stabile Lösung gibt. Die Einschaltung der Modelle ist etwas verzwickt, weil man das Ergebnis der Geschwindigkeit braucht bevor sie berechnet wurde.
Karl schrieb: > Die Einschaltung der Modelle ist etwas verzwickt, weil man das Ergebnis > der Geschwindigkeit braucht bevor sie berechnet wurde. hä?
Moin, das einfache Modell zum Festkörper hat schlicht zwei Zustände Haften/Gleiten, wenn der Schwellwert der Zugkraft im Haften überschritten ist, wird's zu Gleiten, und in der Umkehrung ist etwas Hysterese im Spiel. Das sollte auf einfachen glatten oder einigermassen gleichverteilt rauhen Oberflächen gut passen. Bei nichtlinearer Gleitreibung (in Bezug auf die Geschwindigkeit) könnte es fieser werden und die Zustände oszillieren ev. am Schwellwert. Das dürfte bei Materialen wie Gummioberflächen (wer hat sich nich schon aufm roten Sportplatz die Knie verbrannt) der Fall sein. Edi M. schrieb: > Karl schrieb: >> Die Einschaltung der Modelle ist etwas verzwickt, weil man das Ergebnis >> der Geschwindigkeit braucht bevor sie berechnet wurde. > > hä? Er meint wohl, dass die Anfangsgeschwindigkeit wie jede Anfangsbedingung definiert sein muss. Obiges ist nun aber keine Hexerei, das geht prima mit Runge-Kutta. Nur nicht irgendwas gegen gross("Unendlich") gehen lassen, das sorgt seltenst für numerische Stabilität :-)
Strubi schrieb: > Bei nichtlinearer > Gleitreibung (in Bezug auf die Geschwindigkeit) könnte es fieser werden > und die Zustände oszillieren ev. am Schwellwert. Das dürfte bei > Materialen wie Gummioberflächen (wer hat sich nich schon aufm roten > Sportplatz die Knie verbrannt) der Fall sein. Ist das wirklich ein Beispiel für nichtlineare Gleitreibung? Ist das Gummi nicht eine schnell wechselnde Mischungen aus Gleiten und Haften?
Maik S. schrieb: > Nennt sich auch Stick-Slip Effekt. Also "Haft-Gleiteffekt". Toll! Wo ist hier die Erklärung inbegriffen? Einfach das Problem auf English übersetzt und gut ist? Ich probiere es mal so: Haften ist ein Verhaken der Oberfläche mit einem Spannungsaufbau Oberhalb einer bestimmten Spannung kommt die Oberfläche in Bewegung und schwingt entgegen der Dehnungsrichtung Dabei kratzt sie auf dem Körper entlang. Die Oberfläche des Körpers tut exakt dasselbe nur in der anderen Richtung Beide schwingen aus und wenn sie sich mal wieder sehen und die Geschwindigkeitsdifferenz klein ist, verhaken sie sich wieder.
auf sowas warte ich seit es Schaschlik gibt. Ein Trick damit das Fleisch nicht auf dem Nachbartisch landet, Stäbchen drehen Fleisch festhalten mit der Gabel und wenn das Stäbchen dreht kann/darf man schieben.
Mal ne Frage: warum willst du den Fall "Haften" modellieren? Soll dieser Fall durch die Regelung verhindert werden (Bremsenquietschen oder so)? Der Kraftaufbau und Rücksprung zu "Gleiten" wird ja vermutlich wesentlich schneller passieren als dass irgend eine Regelung eingreifen könnte.
:
Bearbeitet durch User
Edi M. schrieb: > hä? Umschaltung, nicht Einschaltung. Auto"korrektur". Stick Slip lässt sich ohne modellumschaltung nicht simulieren. Die umschaltbedingung darf nicht aus einem vorhergehenden simulationsschritt gebildet werden, sonst kriecht die Simulation mit der kleinsten schrittweise vor sich hin.
Hallo, Stick-Slip simuliert man üblicherweise unter Verwendung von Zero-Crossing Detection beim Geschwindigkeits Nulldurchgang, damit auch wirklich die Haftbedingung kontrolliert werden kann und dann das Teil doch stecken bleibt statt wieder nach unten zu rutschen. Man kann folgende konstruierte Funktion als Reib-Modell nehmen, einen steifen Solver vorausgesetzt: atan(x*10000)*2/pi*(0.8*exp(-abs(100*x))+0.2)+x*20 https://www.google.at/search?client=ubuntu&hs=o10&channel=fs&dcr=0&q=plot%28atan%28x*10000%29*2%2Fpi*%280.8*exp%28-abs%28100*x%29%29%2B0.2%29%2Bx*20&oq=plot%28atan%28x*10000%29*2%2Fpi*%280.8*exp%28-abs%28100*x%29%29%2B0.2%29%2Bx*20&gs_l=psy-ab.3...16259.18882.0.19114.4.4.0.0.0.0.75.288.4.4.0....0...1.1.64.psy-ab..0.0.0.ZlzVkAiPBb0 Es gibt auch noch das LuGre Bristol Model zur Modellierung von Reibung. Habe aber selber nicht damit gearbeitet. http://www8.tfe.umu.se/forskning/Control_Systems/Leonid/WWW/LuGre_poster.pdf Lg
Nachtrag: der ATAN-Ansatz von mir ist ein solcher "Kriecher" :-)
Weinga U. schrieb: > Man kann folgende konstruierte Funktion als Reib-Modell nehmen, einen > steifen Solver vorausgesetzt: Oh, das sieht ja interessant aus. Wie muss Ich das interpretieren? Ist das die Reibung in Abhängigkeit des Ortes oder der Geschwindigkeit? So ganz ist mir die Funktion nicht erklärlich. Brauche Ich damit auch noch eine Modellumschaltung? Im Prinzip hätte Ich kein Problem damit, wenn Ich ein Kriterium hätte. Ein Nulldurchgang in der Geschwindigkeit ist mir auch das Logischste, aber der ist ja immer etwas anders. Z.B. kommt die Geschwindigkeit einmal von -1 auf +17 und einmal von -6 auf +4. Wenn Ich dann einfach auf Haften umschalte habe Ich immer einen anderen Punkt und komme nicht in die Mitte. Will heissen: Ich sehe den echten Nulldurchgang infolge der Abtastungsintervalle nicht genau.
Angehängte Dateien:
-
Stick-Slip.PNG
15 KB -
Sim.PNG
7,8 KB
Weinga U. schrieb: > Stick-Slip simuliert man üblicherweise unter Verwendung von > Zero-Crossing Detection beim Geschwindigkeits Nulldurchgang, damit auch > wirklich die Haftbedingung kontrolliert werden kann und dann das Teil > doch stecken bleibt statt wieder nach unten zu rutschen. This! > Man kann folgende konstruierte Funktion als Reib-Modell nehmen, einen > steifen Solver vorausgesetzt: > > atan(x*10000)*2/pi*(0.8*exp(-abs(100*x))+0.2)+x*20 Ohne das abwerten zu wollen: Genau so gut/schlecht wie eine Kennlinie, weil Weinga U. schrieb: > Nachtrag: der ATAN-Ansatz von mir ist ein solcher "Kriecher" :-) ;-) Simulink warnt einen wenigstens wenn man sowas baut (Number of consecutive zero crossings). Wie es prinzipiell geht oder gehen kann ist im Anhang dargestellt. Nur schnell zusammengeklickt, also bitte nicht auf Details herumreiten. Wesentlicher Punkt ist das Rücksetzen des Geschwindigkeitsintegrators mit Hilfe dessen State-Ports und die Modellumschaltung der Reibkraft (hier: Haftreibung == anliegende Kraft begrenzt, Gleitreibung, Stribeck etc als Kennlinie. Richtungsumkehr der Reibung nicht berücksichtigt, da zu faul)
Markus W. schrieb: > Wenn Ich dann einfach > auf Haften umschalte habe Ich immer einen anderen Punkt und komme nicht > in die Mitte. Will heissen: Ich sehe den echten Nulldurchgang infolge > der Abtastungsintervalle nicht genau. Das ist die Aufgabe des Variable-Step Solvers. Wenn Du Fixed-Step machen musst oder willst: Leb damit ;-)
Naja, variable Step inkl. Zero Crossing Detection! D.h. hat die Zero-Crossing Funktion einen Vorzeichenwechsel, geht der Zeitschrittsolver zurück und versucht genau den Zeitpunkt zu finden, wo die Bedingung=0 ist (bzw. innerhalb eines epsilons). Der DASKR Solver von http://www.netlib.org/ode/ kann das z.B. und heißt dort root-finding. Ich hab vor langer Zeit mich mit Scilab/Scicos damit gespielt. Im Anhang ein ZIP-File mit Source und einem PDF wo alles etwas erklärt wird mit unterschiedlichen Reibmodellen inkl. Modellumschaltung und Zero-Crossing Detection. Lg.
Karl schrieb: > Das ist die Aufgabe des Variable-Step Solvers. Wenn Du Fixed-Step machen > musst oder willst: Leb damit ;-) Das ist alles sehr interessant, allerdings ist mir nicht klar, wie Ich einen solchen Solver in eigene Software integrieren kann. Das Modell soll ja real in Echtzeit berechnend laufen.
Ja was jetzt. Simulation in Echtzeit? Geht auch, ausreichend schneller Rechner vorausgesetzt. Kannst du mehr zu deinen Randbedingungen sagen? Klingt ein bisschen nach HiL...
Angehängte Dateien:
Ich hatte mal im Zuge meiner Geigenemulation so etwas gemacht. Da sind allerdings beide Objekte (Saite und Bogenbespannung) eigene Schwingungssysteme. Das Problem bei der Simulation ist in solchen Fällen vor allem das der Abtastrate: Wenn weitgehend starre oder gespannte Körper im Spiel sind, entstehen sehr hochfrequente Schwingungen, die genau genug abgetastet werden müssen, um sie zu berechnen. Ob das mit DSPs zu machen ist, ist immer wieder Gegenstand von hitzigen Diskussionen in den einschlägigen Gruppen. Tenor und auch meine Meinung: Solange es analytische Beschreibungen dazu gibt oder man mit diesen zufrieden ist, geht es im Rahmen der üblichen Audioabtastraten x2 oder auch x8. Wenn man allerdings im Zeitbereich numerisch integriert, ist es schwierig einen Iteration f+r genügend viele Elemente effektiv rechnend aufzuziehen. In FPGAs z.B. kann man Schwingungen der "üblichen Sorte" mit bis zu 100kHz gut genug abbilden. Mit Getrickse, parallelem Rechnen, Zwischenzeitebenen und pipelines mit Glättung kommt man auch Raten um geschätzt 500kHz. Dh. das was ein mechanischer Schwingkreis zweiter Ordnung treibt, lässt sich bis zu dieser Frequenz einigermaßen genau vorausberechnen. Bei Elektronik mit verketteten Bauelementen, Schleifen über OPs und nichtlinearen Kennlinien geht es schnell runter. Dafür muss man in der Mechanik das Objekt wiederum in unterschiedliche Elemente zerlegen, die eigenständig schwingen können, um das gesamte Systemverhalten zu berechnen. Bei der Geige z.B. sind mal 1000 Elemente der o.g. Art fällig, wenn man eine Saite beschreiben möchte. Um mit einer Beschreibung mit wenigen Elementen die Mischung aus Reibung und Haftung hinzubekommen, erfordert meines Erachtens einen gleitenden Übergang der Rechnungen und auch eine Berücksichtigung der aktuellen Beschleunigungen, der Relativbewegungen der Bereiche, Anpressdruck etc und nicht nur einfache Nulldurchgangsbetrachtungen. Ein solches einfaches Haftmodell ist das des langsam gezogenen Radiergummis. Bei der Saite und auch im Zusammenspiel mit einem nicht völlig statischen Untergrund gibt es dann Reibungshaftung und -beschleunigung in Abhängigkeit der Relativbewegung sowie eine Dämpfung infolge der Absolutbewegung etc, etc.
:
Bearbeitet durch User
Strubi schrieb: > Edi M. schrieb: >> Karl schrieb: >>> Die Einschaltung der Modelle ist etwas verzwickt, weil man das Ergebnis >>> der Geschwindigkeit braucht bevor sie berechnet wurde. >> hä? > Er meint wohl, dass die Anfangsgeschwindigkeit wie jede Anfangsbedingung > definiert sein muss. Obiges ist nun aber keine Hexerei, das geht prima > mit Runge-Kutta. Sehr gutes Stichwort! Daran kann Ich mich erinnern! Man muss nur aufpassen, daß keine Nullen in den Nennern auftreten, bzw über diese Punkte hinweg denken.
Für diese Zwecke bin auch auch gerade im Begriff etwas zusammenzubauen. Vielleicht könnte man sich austauschen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.