Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #212974 > unrolled thread

Schrittmotoren

Back to article view | Back to de.sci.electronics

Contents

  Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-25 09:53 +0200
    Re: Schrittmotoren Matthias Weingart <mwnews@pentax.boerde.de> - 2016-08-25 08:40 +0000
    Re: Schrittmotoren Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-08-25 11:53 +0200
      Re: Schrittmotoren Matthias Weingart <mwnews@pentax.boerde.de> - 2016-08-25 09:59 +0000
      Re: Schrittmotoren w-buechsenschuetz@web.de - 2016-09-02 02:04 -0700
        Re: Schrittmotoren Bernd Nebendahl <Bernd_Nebendahl@web.de> - 2016-09-02 15:51 +0200
    Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-25 14:13 +0200
      Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 14:06 +0200
        Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-26 17:50 +0200
          Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 21:28 +0200
            Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-29 15:14 +0200
              Re: Schrittmotoren Matthias Weingart <mwnews@pentax.boerde.de> - 2016-08-30 06:12 +0000
                Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-30 09:06 +0200
              Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 11:16 +0200
                Re: Schrittmotoren Volker Staben <volker.staben@hs-flensburg.de> - 2016-08-30 12:33 +0200
    Re: Schrittmotoren "MaWin" <me@private.net> - 2016-08-25 14:40 +0200
      Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 14:13 +0200
        Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-30 10:00 +0200
          Re: Schrittmotoren Stefan <df9bi@arcor.de> - 2016-08-30 11:53 +0200
            Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-30 13:12 +0200
              Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 13:53 +0200
                Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-30 14:09 +0200
                  Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 17:59 +0200
                    Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-31 08:10 +0200
              Re: Schrittmotoren Stefan <df9bi@arcor.de> - 2016-08-31 09:12 +0200
                Re: Schrittmotoren Edzard Egberts <ed_09@tantec.de> - 2016-08-31 09:53 +0200
                  Re: Schrittmotoren Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2016-08-31 12:16 +0200
                    Re: Schrittmotoren Stefan <df9bi@arcor.de> - 2016-09-02 15:59 +0200
          Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-30 11:31 +0200
    Re: Schrittmotoren Rafael Deliano <rafael_deliano@arcor.de> - 2016-08-26 20:18 +0200
      Re: Schrittmotoren Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2016-08-26 22:04 +0200

Page 1 of 2  [1] 2  Next page →

#212974 — Schrittmotoren

Angesichts von Werkzeugmaschinen, Robotern und 3D-Druckern ist das 
vermutlich ein alter Hut. Mich interessieren die Ansätze, mehrere 
Schrittmotoren synchron die typischen 2D Bahnen (Gerade, Ellipse) fahren 
zu lassen. Gibt es dafür so etwas einfaches wie die 
Bresenham-Algorithmen, die zusätzlich noch die zulässigen 
Beschleunigungen berücksichtigen?

Bei Werkzeugmaschinen und Robotern stören mich die abgehackten 
Bewegungen in vielen Filmen, lassen sich da nicht flüssigere Übergänge 
erzielen? Oder gar das flüssige Verfolgen beweglicher Ziele?

Last not least interessieren mich speziell solche Ansätze, die auch auf 
schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären 
auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern 
zulässig sind.

DoDi

[toc] | [next] | [standalone]

#212975

Hans-Peter Diettrich <DrDiettrich1@aol.com>:

> Angesichts von Werkzeugmaschinen, Robotern und 3D-Druckern ist das 
> vermutlich ein alter Hut. Mich interessieren die Ansätze, mehrere 
> Schrittmotoren synchron die typischen 2D Bahnen (Gerade, Ellipse) fahren 
> zu lassen. Gibt es dafür so etwas einfaches wie die 
> Bresenham-Algorithmen, die zusätzlich noch die zulässigen 
> Beschleunigungen berücksichtigen?
> 
> Bei Werkzeugmaschinen und Robotern stören mich die abgehackten 
> Bewegungen in vielen Filmen, lassen sich da nicht flüssigere Übergänge 
> erzielen? Oder gar das flüssige Verfolgen beweglicher Ziele?
> 
> Last not least interessieren mich speziell solche Ansätze, die auch auf 
> schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären 
> auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern 
> zulässig sind.

Das Thema hatte ich mal in meiner Diplomarbeit. Die Lösung ist, die Maschinen 
Klothoiden fahren zu lassen (ruckfrei in die Kurve, der 
Beschleunigungswechsel ist dabei linear von der Geraden in den Kreisbogen). 
Wird auch im Straßenbau so gemacht.

M.
-- 

[toc] | [prev] | [next] | [standalone]

#212978

On 25.08.16 09.53, Hans-Peter Diettrich wrote:
> Angesichts von Werkzeugmaschinen, Robotern und 3D-Druckern ist das
> vermutlich ein alter Hut. Mich interessieren die Ansätze, mehrere
> Schrittmotoren synchron die typischen 2D Bahnen (Gerade, Ellipse) fahren
> zu lassen. Gibt es dafür so etwas einfaches wie die
> Bresenham-Algorithmen, die zusätzlich noch die zulässigen
> Beschleunigungen berücksichtigen?

Falscher Ansatz. Es gibt kein Raster.

Wenn Du Schrittmotoren mit Sin/Cos-Generator ansteuerst, laufen sie 
nahezu geräuschlos und ohne Rasterpunkte. Sie können dann in jeder 
Position stehen bleiben.

Beschleunigung ist natürlich so eine Sache. Die Stetigkeit zweiter oder 
gar dritter Ordnung musst Du schon vorher vorgeben.

Mit Raster fügst Du Unmengen an Oberwellen (und Beschleunigungen) hinzu, 
die Du so ohne weiteres nicht wieder los wirst.


> Bei Werkzeugmaschinen und Robotern stören mich die abgehackten
> Bewegungen in vielen Filmen, lassen sich da nicht flüssigere Übergänge
> erzielen? Oder gar das flüssige Verfolgen beweglicher Ziele?

Ja geht.


> Last not least interessieren mich speziell solche Ansätze, die auch auf
> schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären
> auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern
> zulässig sind.

Definiere schmalbrüstig.
Also, ein Raspi wird es schaffen.


Marcel

[toc] | [prev] | [next] | [standalone]

#212980

Marcel Mueller <news.5.maazl@spamgourmet.org>:

> 
>> Last not least interessieren mich speziell solche Ansätze, die auch auf
>> schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären
>> auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern
>> zulässig sind.
> 
> Definiere schmalbrüstig.
> Also, ein Raspi wird es schaffen.

Auch sin, cos schafft man auf kleinen 8MHz Controllern, dann arbeitet man in 
Integer mit Tabellen im ROM und skaliert durch ne Multiplikation hoch. Aber 
die Frage ist, ob man sich das heutzutage noch antun will, wo schnelle ARM 
Controller bald preisgünstiger sind, als alte Atmel 8-bitter....

M.
-- 

[toc] | [prev] | [next] | [standalone]

#213290

X-No-archive: Yes

Am Donnerstag, 25. August 2016 11:53:01 UTC+2 schrieb Marcel Mueller:

> Wenn Du Schrittmotoren mit Sin/Cos-Generator ansteuerst, laufen sie 
> nahezu geräuschlos und ohne Rasterpunkte. Sie können dann in jeder 
> Position stehen bleiben.

Ist dann praktisch eine Mikroschrittsteuerung mit unendlicher Auflösung. 

Allerdings folgen Schrittmotoren zwischen den Vollschritten nicht streng der sin/cos-Kurve der Ströme, sodaß eine entsprechende hochauflösende Rückkopplung notwendig wird, oder evtl. eine Kompensation (d.h. Abweichung von strenger sin/cos-Kurve) nach vorheriger Ermittlung der Abweichungen.

[toc] | [prev] | [next] | [standalone]

#213294

Am 2016-09-02 um 11:04 schrieb w-buechsenschuetz@web.de:
> X-No-archive: Yes
>
> Am Donnerstag, 25. August 2016 11:53:01 UTC+2 schrieb Marcel Mueller:
>
>> Wenn Du Schrittmotoren mit Sin/Cos-Generator ansteuerst, laufen sie
>> nahezu geräuschlos und ohne Rasterpunkte. Sie können dann in jeder
>> Position stehen bleiben.
>
> Ist dann praktisch eine Mikroschrittsteuerung mit unendlicher Auflösung.
>
> Allerdings folgen Schrittmotoren zwischen den Vollschritten nicht streng
 > der sin/cos-Kurve der Ströme, sodaß eine entsprechende hochauflösende
 > Rückkopplung notwendig wird, oder evtl. eine Kompensation (d.h.
> Abweichungvon strenger sin/cos-Kurve) nach vorheriger Ermittlung der
> Abweichungen.

Noch schlimmer, die Abweichung hängt von der Geschwindigkeit und der 
Belastung ab. Damit funktioniert in vielen Fällen die vorherige 
Ermittlung nur mangelhaft oder wir SEHR aufwändig.

Dann besser mir BLDC und (hochauflösendem) Encoder arbeiten. Dann 
entfallen auch Probleme mit Schrittverlusten usw.

Bernd

[toc] | [prev] | [next] | [standalone]

#212984

Am 25.08.16 um 09.53 schrieb Hans-Peter Diettrich:
> Angesichts von Werkzeugmaschinen, Robotern und 3D-Druckern ist das
> vermutlich ein alter Hut. Mich interessieren die Ansätze, mehrere
> Schrittmotoren synchron die typischen 2D Bahnen (Gerade, Ellipse) fahren
> zu lassen. Gibt es dafür so etwas einfaches wie die
> Bresenham-Algorithmen, die zusätzlich noch die zulässigen
> Beschleunigungen berücksichtigen?

J. Man kann in 2D, 3D oder 6D einfach eine geeignete Trajektorie
vorgeben, die in der 2. oder auch 3. Zeitableitung stetig ist - wenn man
will, auch noch in der 4. Zeitableitung. Schwieriger wirds nur, wenn man
"unterwegs" auch noch Hindernissen ausweichen muss, also Einschränkungen
unterworfen ist.

> Last not least interessieren mich speziell solche Ansätze, die auch auf
> schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären
> auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern
> zulässig sind.

Klothoiden waren ja schon genannt. Trajektoriegeneratoren lassen sich
recht elegant und effizient im Zustandsraum implementieren. Da braucht
es lediglich Additionen und Multiplikationen - wenn man nicht mühsam
skalieren will, vermutlich mit Gleitkommaarithmetik. Aber
"schmalbrüstig" ist ja auch relativ...

V.

[toc] | [prev] | [next] | [standalone]

#213037

Zuerst möchte ich mich bei allen bedanken, die geantwortet haben, mit so 
einer überwältigenden Fülle von Gedanken hatte ich garnicht gerechnet :-)

Bitte seid mir nicht böse, wenn ich nicht auf jede Antwort einzeln 
eingehe, davor muß sich die Informationsflut erst einmal bei mir setzen.

Volker Staben schrieb:
> Am 25.08.16 um 09.53 schrieb Hans-Peter Diettrich:
>> Angesichts von Werkzeugmaschinen, Robotern und 3D-Druckern ist das
>> vermutlich ein alter Hut. Mich interessieren die Ansätze, mehrere
>> Schrittmotoren synchron die typischen 2D Bahnen (Gerade, Ellipse) fahren
>> zu lassen. Gibt es dafür so etwas einfaches wie die
>> Bresenham-Algorithmen, die zusätzlich noch die zulässigen
>> Beschleunigungen berücksichtigen?
> 
> J. Man kann in 2D, 3D oder 6D einfach eine geeignete Trajektorie
> vorgeben, die in der 2. oder auch 3. Zeitableitung stetig ist - wenn man
> will, auch noch in der 4. Zeitableitung. Schwieriger wirds nur, wenn man
> "unterwegs" auch noch Hindernissen ausweichen muss, also Einschränkungen
> unterworfen ist.

Das erinnert mich jetzt an sowas wie Splines, die bei vorgegebenen 
Bahnen bzw. Stützstellen komplett durchgerechnet werden können. Bei ggf. 
dynamisch änderbaren Zielen bzw. Zwischenpunkten müßte man die Segmente 
entsprechend öfters durchrechnen, auf Kollissionen prüfen und die 
Stützstellen ggf. entsprechend anpassen.


>> Last not least interessieren mich speziell solche Ansätze, die auch auf
>> schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären
>> auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern
>> zulässig sind.
> 
> Klothoiden waren ja schon genannt. Trajektoriegeneratoren lassen sich
> recht elegant und effizient im Zustandsraum implementieren. Da braucht
> es lediglich Additionen und Multiplikationen - wenn man nicht mühsam
> skalieren will, vermutlich mit Gleitkommaarithmetik. Aber
> "schmalbrüstig" ist ja auch relativ...

Ausgangspunkt meiner Frage war eigentlich, was ein Schrittmotor-Treiber 
können muß, um möglichst alle Anforderungen erfüllen zu können. Aus den 
vielen Antworten ist mir inzwischen klar geworden, daß alles auf einmal 
eher unsinnig ist, zumindest zwischen fest vorgegebenen Bahnen 
(Formerhalt bei Konturen) und Trajektorien mit ggf. variablen Endpunkten 
unterschieden werden sollte (optimale Bewegungen).

Das "schmalbrüstig" wollte ich eher eng verstanden wissen, da 
number-crucher eher nicht zur direkten Ansteuerung von Schrittmotoren 
geeignet sind, und die entsprechende Peripherie ja auch implementiert 
sein will. Auch da habe ich inzwischen mehr Anhaltspunkte für die 
entspechende Abgrenzung.

DoDi

[toc] | [prev] | [next] | [standalone]

#213042

Am 26.08.16 um 14.06 schrieb Hans-Peter Diettrich:
> Das erinnert mich jetzt an sowas wie Splines, die bei vorgegebenen
> Bahnen bzw. Stützstellen komplett durchgerechnet werden können. Bei ggf.
> dynamisch änderbaren Zielen bzw. Zwischenpunkten müßte man die Segmente
> entsprechend öfters durchrechnen, auf Kollissionen prüfen und die
> Stützstellen ggf. entsprechend anpassen.

Ja. Wobei 1. Splines üblicherweise Polynome 3. Grades sind, der Ruck
also nicht stetig verläuft. Mit einem Trajektoriegenerator kann man
Stetigkeit einer beliebig hohen Ableitung erreichen.

2. liefert ein Trajektoriegenerator immer auch bei "Kurswechseln"
zwischendurch automatisch die passenden Zeitableitungen. Mit Splines
muss man bei Kurswechseln vom Momentanzustand aus neu rechnen - und auch
ggf. akzeptieren, dass dann möglicherweise die Krümmung nicht mehr
minimal sein kann.

Und 3. bietet ein Trajektoriegenerator die Möglichkeit, aus den
Ableitungen gleich Vorsteuersignale für eine Kaskadenregelung
herauszuziehen.

> Ausgangspunkt meiner Frage war eigentlich, was ein Schrittmotor-Treiber
> können muß, um möglichst alle Anforderungen erfüllen zu können.

Warum "möglichst alle"? Es reicht doch, die jeweils gegebenen zu erfüllen?

V.

[toc] | [prev] | [next] | [standalone]

#213045

Volker Staben schrieb:
> Am 26.08.16 um 14.06 schrieb Hans-Peter Diettrich:
>> Das erinnert mich jetzt an sowas wie Splines, die bei vorgegebenen
>> Bahnen bzw. Stützstellen komplett durchgerechnet werden können. Bei ggf.
>> dynamisch änderbaren Zielen bzw. Zwischenpunkten müßte man die Segmente
>> entsprechend öfters durchrechnen, auf Kollissionen prüfen und die
>> Stützstellen ggf. entsprechend anpassen.
> 
> Ja. Wobei 1. Splines üblicherweise Polynome 3. Grades sind, der Ruck
> also nicht stetig verläuft. Mit einem Trajektoriegenerator kann man
> Stetigkeit einer beliebig hohen Ableitung erreichen.

Hast Du irgendwelche Links zu Informationen über Trajektoriegeneratoren, 
die zum Verständnis und Implementierung beitragen können?

DoDi

[toc] | [prev] | [next] | [standalone]

#213138

Am 26.08.16 um 21.28 schrieb Hans-Peter Diettrich:
> Hast Du irgendwelche Links zu Informationen über Trajektoriegeneratoren,
> die zum Verständnis und Implementierung beitragen können?

mit den Suchbegriffen "Trajektoriegenerator" oder
"Führungsgrößengenerator" findest Du jede Menge Infos im Netz. Das
meiste ist allerdings in Richtung zeitoptimale Regelung in der
Antriebstechnik orientiert - also optimales Abfahren von Bremsparabeln o.ä.

Das, was mir spontan einfiel, ist ein so alter Hut, dass man kaum Infos
darüber findet. Wenn - und das ist auch der Kontext, den ich kenne -,
dann im Zusammenhang mit flachheitbasierten Steuerungen und Regelungen.
Aber darauf muss man erst einmal kommen :-) Dort "bastelt" man sich ja
eine notwendige Stellgröße genau aus gefordertem Eingangssignal einer
nichtlinearen Strecke und deren Ableitungen so zusammen, dass die
Regelgröße einem gewünschten Zeitverlauf entspricht. Man realisiert also
eine gewünschte Trajektorie der Regelgröße, indem man die genau dafür
nötige Trajektorie der Stellgröße realisiert.

Das Prinzip habe ich mal in folgender PDF skizziert - vereinfacht für
den einachsigen linearen Fall:

https://cloud.fh-flensburg.de/owncloud/index.php/s/mo7uLfWrtuYtQkc

Im Grundsatz ist der Trajektoriegenerator ein im Zustandsraum
formuliertes System: eine Kette von Integratoren - im Bild mit ihrer
Übertragungsfunktion 1/s bezeichnet. Zeitdiskret funktionierts natürlich
genauso. Mit Hilfe der Rückführungskoeffizienten a wird das dynamische
Verhalten des Generators auf gewünschte (hinreichend schnelle)
Eigenwerte dimensioniert. Das geht mit Hilfe von
Standard-Entwurfsverfahren im Zustandsraum ziemlich simpel. Ein
Koeffizient k am Eingang sorgt dafür, dass im stationären Fall am
Ausgang "Ort" das gleiche Signal ansteht wie am Eingang "Sollwert Ort"
vorgegeben. Der Ausgang "Ort" folgt nun dem Eingang "Sollwert Ort" mit
einer Dynamik mit den vorgegebenen Eigenwerten, die man ja grundsätzlich
beliebig vorgeben kann.

Dadurch, dass die Signale für Geschwindigkeit, Beschleunigung und Ruck
jeweils aus den vorgelagerten Integratoren herausgezogen werden, stellen
diese Signale immer die zum jeweiligen Zeitverlauf des Orts gehörenden
zeitlichen Ableitungen des Orts dar, auch bei zeitlich veränderlicher
Ortsvorgabe (also dem sich "unterwegs" ändernden Ziel). Deswegen kann
man diese Signale für z.B. eine Vorsteuerung einer Kaskadenregelung in
der Antriebstechnik verwenden. Und weil alle Signale - auch der Ruck -
durch mindestens einen Integrator hindurch müssen, muss auch der Ruck
stetig verlaufen, egal, was am Eingang "Sollwert Ort" passiert (endliche
Signale vorausgesetzt). Wenn man will, kann man so auch noch die 7.
Ableitung stetig realisieren, indem man das Prinzip erweitert.

Nachteile hat das Ganze natürlich auch: die Synchronisation von mehreren
Achsen ist nicht ganz trivial, wenn man die vorgezogenen Signale
Geschwindigkeit etc. nutzen will. Braucht man nur den Ort in x und y und
ist Mehrdeutigkeit nicht gefordert, kann man einfach den Ort y als
Funktion des Orts x für die zweite Achse verwenden. Hat man
Mehrdeutigkeiten, dann muss das Ganze sowieso anders konzipiert werden,
vielleicht mit vorgelagerten Splines, die drei Orte x,y,z als drei
Funktionen einer Laufvariabe l realisieren - l könnte z.B. der Weg längs
des Splines sein. Die Orte x, y, z aus dem Spline können dann in drei
Trajektoriegeneratoren wie im Bild verarbeitet werden, um die drei
Achsen dann ruckstetig anzusteuern. So kann man dann auch bspw. mit
einem Werkzeug mit konstanter Schnittgeschwindigkeit durch ein Werkstück
fahren.

Zeitoptimal ist das Ganze auch nicht, daher auch der Kontext zur
Regelungstechnik.

Aber vielleicht ist das immerhin ein geeigneter Denkanstoß.

Gruß, V.

[toc] | [prev] | [next] | [standalone]

#213163

Volker Staben <volker.staben@hs-flensburg.de>:

> Die Orte x, y, z aus dem Spline k”nnen dann in drei
> Trajektoriegeneratoren wie im Bild verarbeitet werden, um die drei
> Achsen dann ruckstetig anzusteuern. So kann man dann auch bspw. mit
> einem Werkzeug mit konstanter Schnittgeschwindigkeit durch ein Werkstck
> fahren.
 
Konstante Schnittgeschwindigkeit ist manchmal eine wichtige Vorgabe, das 
klappt aber nur, wenn die Kontur auch entsprechend geformt ist. An einer 
rechteckigen Kante schaffst Du keine konstante Schnittgeschwindigkeit. D.h. 
die Zeitverläufe Deiner Ort-Sollwerte müssen für konstante Geschwindigkeit 
angepasst werden, sonst wird das nicht ruckfrei...

M.
-- 

[toc] | [prev] | [next] | [standalone]

#213164

Am 30.08.16 um 08.12 schrieb Matthias Weingart:
> Volker Staben <volker.staben@hs-flensburg.de>:
> 
>> Die Orte x, y, z aus dem Spline k”nnen dann in drei
>> Trajektoriegeneratoren wie im Bild verarbeitet werden, um die drei
>> Achsen dann ruckstetig anzusteuern. So kann man dann auch bspw. mit
>> einem Werkzeug mit konstanter Schnittgeschwindigkeit durch ein Werkstck
>> fahren.
>  
> Konstante Schnittgeschwindigkeit ist manchmal eine wichtige Vorgabe, das 
> klappt aber nur, wenn die Kontur auch entsprechend geformt ist. An einer 
> rechteckigen Kante schaffst Du keine konstante Schnittgeschwindigkeit. D.h. 
> die Zeitverläufe Deiner Ort-Sollwerte müssen für konstante Geschwindigkeit 
> angepasst werden, sonst wird das nicht ruckfrei...

logisch. Ideal "eckige" Ecken gehen mit durchgängigen Splines sowieso
nicht, da muss man schon anders planen.

V.

[toc] | [prev] | [next] | [standalone]

#213170

Volker Staben schrieb:
> Am 26.08.16 um 21.28 schrieb Hans-Peter Diettrich:
>> Hast Du irgendwelche Links zu Informationen über Trajektoriegeneratoren,
>> die zum Verständnis und Implementierung beitragen können?
> 
> mit den Suchbegriffen "Trajektoriegenerator" oder
> "Führungsgrößengenerator" findest Du jede Menge Infos im Netz.

Die 10 Treffer bei meiner Recherche erscheinen mir sehr übersichtlich. 
Über den Generator selbst konnte ich praktisch nichts finden :-(


> Das Prinzip habe ich mal in folgender PDF skizziert - vereinfacht für
> den einachsigen linearen Fall:
> 
> https://cloud.fh-flensburg.de/owncloud/index.php/s/mo7uLfWrtuYtQkc

Das sieht mir wie ein Beobachter aus?

> Im Grundsatz ist der Trajektoriegenerator ein im Zustandsraum
> formuliertes System: eine Kette von Integratoren - im Bild mit ihrer
> Übertragungsfunktion 1/s bezeichnet. Zeitdiskret funktionierts natürlich
> genauso. Mit Hilfe der Rückführungskoeffizienten a wird das dynamische
> Verhalten des Generators auf gewünschte (hinreichend schnelle)
> Eigenwerte dimensioniert. Das geht mit Hilfe von
> Standard-Entwurfsverfahren im Zustandsraum ziemlich simpel.

Das würde mich näher interessieren, insbesondere wie Grenzen für 
Geschwindigkeit und Beschleunigung vorgegeben werden können.

Mit Zustandsreglern habe ich mich schon im Studium beschäftigt, bin aber 
immer bei der Identifikation der Regelstrecke stecken geblieben. Für 
Otto Normaluser ist das jedenfalls kein brauchbarer Ansatz :-(


> Nachteile hat das Ganze natürlich auch: die Synchronisation von mehreren
> Achsen ist nicht ganz trivial, wenn man die vorgezogenen Signale
> Geschwindigkeit etc. nutzen will. Braucht man nur den Ort in x und y und
> ist Mehrdeutigkeit nicht gefordert, kann man einfach den Ort y als
> Funktion des Orts x für die zweite Achse verwenden.

Das setzt aber voraus, daß die zweite Koordinate die Bahngeschwindigkeit 
nicht begrenzt?


> Aber vielleicht ist das immerhin ein geeigneter Denkanstoß.

Im Prinzip schon, nur habe ich Zustandsregler/Beobachter für später 
zurückgestellt.

DoDi

[toc] | [prev] | [next] | [standalone]

#213172

Am 30.08.16 um 11.16 schrieb Hans-Peter Diettrich:
> Die 10 Treffer bei meiner Recherche erscheinen mir sehr übersichtlich.
> Über den Generator selbst konnte ich praktisch nichts finden :-(

Es ist natürlich auch schon ein Thema, das etwas über den Horizont der
Allgemeinheit hinausgeht. In wissenschaftlichen Publikationsdatenbanken
gibt es durchaus Zehntausende von Treffern.

> Das sieht mir wie ein Beobachter aus?

Nein. Ein Beobachter ist ein Modell eines realen Systems, das dem realen
System nachgeführt wird, indem die Abweichung der Ausgangsgrößen von
realem System und Modell über eine Rückführmatrix minimiert wird.

Der Generator ist letztlich ein Filter, das in einer
Zustandsraum-Normalform formuliert wird. Und diese
Zustandsraum-Normalformen sehen natürlich immer ähnlich aus, sowohl bei
einem Zustandsraummodel, einem Beobachter, einem Kalman-Filter oder eben
hier dem Trajektoriegenerator.

>> Im Grundsatz ist der Trajektoriegenerator ein im Zustandsraum
>> formuliertes System: eine Kette von Integratoren - im Bild mit ihrer
>> Übertragungsfunktion 1/s bezeichnet. Zeitdiskret funktionierts natürlich
>> genauso. Mit Hilfe der Rückführungskoeffizienten a wird das dynamische
>> Verhalten des Generators auf gewünschte (hinreichend schnelle)
>> Eigenwerte dimensioniert. Das geht mit Hilfe von
>> Standard-Entwurfsverfahren im Zustandsraum ziemlich simpel.

Die Dynamik des Generators der Ordnung n wird durch vorgegebene n
Eigenwerte lambda_1, lambda_2,... festgelegt. Dann ergibt sich ein
charakteristisches Sollpolynom P_soll durch Ausmultiplizieren von

P_soll = (lambda - lambda_1)*(lambda - lambda_2)*...

Man beschreibt die Integratorkette des Generators durch die vier
Standardmatrizen A, B, C, D eines Zustandsraummodells, damit wird bei
geeigneter "Nummerierung" der Zustandsgrößen

1. die Eingangsmatrix B so festlegt, dass der (skalare) Eingang nur auf
den "ersten" Integrator wirkt, also B = (1 0 0 0 ...)',

2. die Ausgangsmatrix C so festlegt, dass der Ausgang des "letzten"
Integrators die (skalare) Ausgangsgröße wird, also C = (... 0 0 0 1)
ist, und

3. Die Systemmatrix eine Hauptdiagonalparallelform besitzt, es wird also
A zu

      / 0  0  0  0 usw. \
     /  1  0  0  0       \
A = (   0  1  0  0        )
     \  0  0  1  0       /
      \ usw.       usw. /

4. D = 0, da nicht sprungfähiges System.

Das charakteristische Polynom P des Generators ergibt sich dann mit der
Einheitsmatrix I aus

P = det(lambda*I - A + B*R)

und ein Koeffizientenvergleich P_soll = P liefert n Gleichungen für die
Koeffizienten der Rückführmatrix R (die ich in meiner Handskizze
blöderweise mit a_1, a_2,... benannt hatte).

Dann muss man nur noch dafür sorgen, dass das stationäre Verhalten auf
Verstärkung eins führt, also einmal den Endwertsatz bemühen. Damit folgt
dann der Ausgang mit gegebener Dynamik dem Eingang und die vorgelagerten
Integratoren liefern die Ableitungen des Ausgangs.

That's it. Standard-Entwurfsverfahren im Zustandsraum, wie bei einer
klassischen Regelung mit Rückführung des Zustandsvektors oder der
Dimensionierung der Rückführmatrix eines Beobachters. Nur beim
Kalman-Filter geht man i.d.R. anders vor, weil dort die
Beobachterdynamik nicht per Eigenwertvorgabe, sondern für optimale
Unterdrückung von Störungen dimensioniert wird.

> Das würde mich näher interessieren, insbesondere wie Grenzen für
> Geschwindigkeit und Beschleunigung vorgegeben werden können.

Bei begrenztem Eingangssignal werden Maximalwerte für die Ableitungen ja
durch die gewählte Generatordynamik festgelegt. Das Ganze ist nur nicht
zeitoptimal, d.h., die Grenzen werden genau einmal erreicht und man
fährt nicht eine maximal mögliche Zeit auf der Grenze.

Andererseits kann man den Generator auch schnell auslegen, die Bahn
anders planen und den Generator dann nur noch verwenden, um die
Ableitungen online zu berechnen - dann vielleicht auch gleich
mehrdimensional. Möglichkeiten gibt es viele...

> Mit Zustandsreglern habe ich mich schon im Studium beschäftigt, bin aber
> immer bei der Identifikation der Regelstrecke stecken geblieben. Für
> Otto Normaluser ist das jedenfalls kein brauchbarer Ansatz :-(

Es ist wie immer: wenn man es einmal kapiert hat, ist es supereinfach
und superpraktisch.

>> Nachteile hat das Ganze natürlich auch: die Synchronisation von mehreren
>> Achsen ist nicht ganz trivial, wenn man die vorgezogenen Signale
>> Geschwindigkeit etc. nutzen will. Braucht man nur den Ort in x und y und
>> ist Mehrdeutigkeit nicht gefordert, kann man einfach den Ort y als
>> Funktion des Orts x für die zweite Achse verwenden.
> 
> Das setzt aber voraus, daß die zweite Koordinate die Bahngeschwindigkeit
> nicht begrenzt?

Natürlich. Deswegen ist es für den allgemeinen Fall stetiger
mehrdimensionaler Bahnen sicher günstiger, einen Spline über einer
Laufvariablen zu definieren. Allein schon ja wegen der möglichen
Mehrdeutigkeiten. Damit hat man dann die Bahngeschwindigkeit im Griff.

V.

[toc] | [prev] | [next] | [standalone]

#212988

"Hans-Peter Diettrich" <DrDiettrich1@aol.com> schrieb im Newsbeitrag 
news:e27mgiF9n3eU1@mid.individual.net...
> Angesichts von Werkzeugmaschinen, Robotern und 3D-Druckern ist das 
> vermutlich ein alter Hut. Mich interessieren die Ansätze, mehrere 
> Schrittmotoren synchron die typischen 2D Bahnen (Gerade, Ellipse) fahren 
> zu lassen. Gibt es dafür so etwas einfaches wie die Bresenham-Algorithmen, 
> die zusätzlich noch die zulässigen Beschleunigungen berücksichtigen?
>
> Bei Werkzeugmaschinen und Robotern stören mich die abgehackten Bewegungen 
> in vielen Filmen, lassen sich da nicht flüssigere Übergänge erzielen? Oder 
> gar das flüssige Verfolgen beweglicher Ziele?
>
> Last not least interessieren mich speziell solche Ansätze, die auch auf 
> schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei wären 
> auch (etwas) größere Abweichungen akzeptabel, als bei Industrierobotern 
> zulässig sind.

Schau dir mal grbl auf Arduino an, wie er eine 3d-Form fräst.

-- 
MaWin, Manfred Winterhoff, mawin at gmx dot net
Homepage http://www.oocities.org/mwinterhoff/
dse-FAQ: http://dse-faq.elektronik-kompendium.de/

[toc] | [prev] | [next] | [standalone]

#213038

MaWin schrieb:
> "Hans-Peter Diettrich" <DrDiettrich1@aol.com> schrieb im Newsbeitrag 

>> Last not least interessieren mich speziell solche Ansätze, die auch 
>> auf schmalbrüstigen Mikrocontrollern laufen (siehe Bresenham). Dabei 
>> wären auch (etwas) größere Abweichungen akzeptabel, als bei 
>> Industrierobotern zulässig sind.
> 
> Schau dir mal grbl auf Arduino an, wie er eine 3d-Form fräst.

Grbl war ein gutes Stichwort :-)

Frage: kann ein Arduino neben grbl noch mehr tun (Speicher? 
Rechenzeit?), oder wäre das lediglich ein back-end für die 
ausschließliche Programmierung via G-Code?

DoDi

[toc] | [prev] | [next] | [standalone]

#213167

Hans-Peter Diettrich wrote:
> Frage: kann ein Arduino neben grbl noch mehr tun (Speicher?
> Rechenzeit?), oder wäre das lediglich ein back-end für die
> ausschließliche Programmierung via G-Code?

"ein Arduino" ist nichts anderes als ein Atmel-Prozessor mit
USB-Schnittstelle, Stromversorgung und Bootloader, z.B. ATmega328
https://www.arduino.cc/en/Main/ArduinoBoardUno:

2 kB SRAM; 32 kB Flash Memory; 1 kB EEPROM; 16 MHz Clock Speed

Das gibt es auch noch größer:
https://www.arduino.cc/en/Main/ArduinoBoardMega2560

8 kB SRAM, 256 kB Flash, 4 kB EEPROM, 16 MHz Clock Speed

Das ist für die Erstellung und Verwaltung von XYZ-Programmen also etwas
eng, deshalb würde ich sagen, dass das wirklich eher als Backend zu
gebrauchen ist.

[toc] | [prev] | [next] | [standalone]

#213171

Am 30.08.2016 um 10:00 schrieb Edzard Egberts:
> Hans-Peter Diettrich wrote:
>> Frage: kann ein Arduino neben grbl noch mehr tun (Speicher?
>> Rechenzeit?), oder wäre das lediglich ein back-end für die
>> ausschließliche Programmierung via G-Code?
>
> "ein Arduino" ist nichts anderes als ein Atmel-Prozessor mit
> USB-Schnittstelle, Stromversorgung und Bootloader, z.B. ATmega328
> https://www.arduino.cc/en/Main/ArduinoBoardUno:
>
> 2 kB SRAM; 32 kB Flash Memory; 1 kB EEPROM; 16 MHz Clock Speed
>
> Das gibt es auch noch größer:
> https://www.arduino.cc/en/Main/ArduinoBoardMega2560
>
> 8 kB SRAM, 256 kB Flash, 4 kB EEPROM, 16 MHz Clock Speed
>
> Das ist für die Erstellung und Verwaltung von XYZ-Programmen also etwas
> eng, deshalb würde ich sagen, dass das wirklich eher als Backend zu
> gebrauchen ist.
>

Es gibt aber auch die Möglichkeit, am Arduino eine SD-Karte zu 
betreiben. Ich hab hier an meinem 3D Drucker ein 4GB Karte auf die ich 
die Druckdateien speichere.

[toc] | [prev] | [next] | [standalone]

#213173

Stefan wrote:
> Am 30.08.2016 um 10:00 schrieb Edzard Egberts:
>> Hans-Peter Diettrich wrote:
>>> Frage: kann ein Arduino neben grbl noch mehr tun (Speicher?
>>> Rechenzeit?), oder wäre das lediglich ein back-end für die
>>> ausschließliche Programmierung via G-Code?

>> "ein Arduino" ist nichts anderes als ein Atmel-Prozessor mit
>> Das ist für die Erstellung und Verwaltung von XYZ-Programmen also etwas
>> eng, deshalb würde ich sagen, dass das wirklich eher als Backend zu
>> gebrauchen ist.
> 
> Es gibt aber auch die Möglichkeit, am Arduino eine SD-Karte zu
> betreiben. Ich hab hier an meinem 3D Drucker ein 4GB Karte auf die ich
> die Druckdateien speichere.

Warum wird das nicht per USB übertragen? Oder warst Du der mit den Störern?

Mein Ansatz war eher, dass der Arduino zu klein ist, um ein vernünftiges
Display mit Tastatur zu betreiben - mit 2 Zeilen LCD kommt man bei der
Anforderung wohl kaum hin. Also die Programme besser am PC mit
Bildschirm, Maus und Tastatur eingeben und mit dem Arduino ausführen.
Man kann mit dem Arduino auch vollständige Geräte mit (numerischer)
Tastatur/ (LCD-) Display bauen, aber das entsprechende Gerät war bei mir
ruckzuck vollprogrammiert - um die letzten Zeilen reinzuquetschen musste
ich woanders optimieren. Und das Display musste auch in einen
Timer-Interrupt, weil das alles sonst zu langsam geworden wäre.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web