Algorithmus für Prototyp

[Eillicht_zu_Vensre_ac055a]

Prost, Gemeinde.

Mir ist eine leicht aus der Art geschlagene Aufgabe ins Portfolio geraten, und ich würde mich freuen, wenn derdiedas Eine oder Andere von euch mal über meinen Lösungsansatz schaute.

Endziel der Übung soll ein selbstfahrendes Gerät sein, das anhand von Umweltbedingungen vor Ort den Standort wechselt und bei Verlassen bestimmter Rahmenbedingungen Alarm schlägt. Anwendungsbereich Lackierung / Galvanik mit Überwachung Staub / Hitze /Dämpfe …

Das läuft im Endeffekt auf eine wie auch immer geartete Messung der Umgebungsbedingungen mit Sensoren oder was auch immer hinaus.

Mein jetzt - und zwar very heidewitzka - zu bauendes Modell müsste demonstrieren können, dass ein fahrerloses System selbständig auf veränderte äußere Bedingungen reagieren kann. Ganz prinzipiell nur : Verändert sich Bedingung X, verändert das System den Standort.

Überlegung : Ich brauche keine externen Sensoren, wenn ich als Demobedingung einfach die interne Temperatur, meinetwegen des Prozessors, verwende. Spart Zeit und Geld.

Steuerungsalgorithmus :

Wiederhole
 Lies aktuelle Temperatur T (des Prozessors).
 Speichere T in U (T=\>U).
 Solange (U\>T)
 Lies aktuelle Temperatur T (des Prozessors).
 Liegt T unterhalb eines Schwellenwertes W,
 mach gar nichts.
 Sonst 
 speichere T (T=\>U),
 verändere den Standort (Koordinaten x/y) innerhalb eines Gatters [es gibt für beide Koordinaten Minima und Maxima].
 Speichere x<sub>alt</sub> und y<sub>alt</sub>.
 Loop.
 Wenn Ualt/y<sub>alt</sub>.
Loop.

Meine Überlegung dazu : Wenn ich dieses Ding mit einer Taschenlampe oder Lötlampe ärgere, wird es sich aus dem Licht (i.e. dem warmen Bereich) verziehen, bis seine Innentemperatur wieder in Ordnung ist. Für diesen ersten Wurf lassen wir den Fall, dass es überall im Raum zu warm ist, außer Acht - im wirklichen Leben müsste dann irgendwo eine Klingel losgehen.

Kann man das so umsetzen?

Gruß Eillicht zu Vensre

[Mario_F_1bfd42]

Hi, nur mal so flüchtig,

Steuerungsalgorithmus :

Wiederhole
Lies aktuelle Temperatur T (des Prozessors).
Speichere T in U (T=>U).

/Hier liegt ein Fehler, durch das speichern ist T=U, das darf erst nach der Auswertung passieren.

Solange (U>T)
Lies aktuelle Temperatur T (des Prozessors).
Liegt T unterhalb eines Schwellenwertes W,
mach gar nichts.
Sonst
speichere T (T=>U),
verändere den Standort (Koordinaten x/y)
innerhalb eines Gatters [es gibt für beide Koordinaten Minima
und Maxima].
Speichere x_alt und y_alt.
Loop.
Wenn Ualt/y_alt.
Loop.Meine Überlegung dazu : Wenn ich dieses Ding mit
einer Taschenlampe oder Lötlampe ärgere, wird es sich aus dem
Licht (i.e. dem warmen Bereich) verziehen, bis seine
Innentemperatur wieder in Ordnung ist. Für diesen ersten Wurf
lassen wir den Fall, dass es überall im Raum zu warm ist,
außer Acht - im wirklichen Leben müsste dann irgendwo eine
Klingel losgehen.

Kann man das so umsetzen?

die innerer Loop würde ich gegen Wenn ersetzen, spart das zweite Auslesen der Temperatur.

Gruß Eillicht zu Vensre

MfG Mario

[StefanS_8166b2]

Morgen!

Kann man das so umsetzen?

Nee ich denke nicht.

Wie schon erwähnt hast du ein GrößerGleich oder KleinerGleich Problem,
desweiteren macht dein Altgorithmus nicht was du möchtest.

Für solche Fälle habe ich früher mal gelernt macht man einen
Schreibtischtest.
Setz dich hin und spiel Computer, gehe jede Zeile einzeln durch
und schreibe alle Variablen Zeile für Zeile auf und mache jede
Bedingung genau mit (achte darauf ob da größer oder GrößerGleich
steht).
Die Ausgaben (bei dir Koordinaten werden auch pro Zeile mit
aufgeschrieben und dann wirst du sehen was passiert.
Du mußt mindesten ein paar Schleifendurchläufe machen um zu sehen
was passiert.

Für diesen Test mußt du dir allerdings vorher überlegen/festlegen wie
sich die Temperatur verändert und natürlich was du erwartest.

Im ersten Überfliegen meine ich das Ding bleibt stehen wenn du es
ärgerst (die Temperatur bei jeder Messung steigt).

Gruß
Stefan

[Eillicht_zu_Vensre_ac055a]

Präzisierung
Hallo.

Besten Dank an Stefan und Mario. Ich habe mich wohl zu unpräzise ausgedrückt : Es geht mir im wesentlichen nicht um den Debug (den kriege ich schon selbst hin, bzw. die monierten Fehler wären mir bei der Simulation aufgefallen); trotzdem habt ihr mir natürlich bereits geholfen.

Ich bin eher unsicher (weil für mich Datenbankeumel so eine Fragestellung nicht alltäglich ist), ob meine grundsätzlichen Überlegungen richtig sind.

Also : Kann man mit einem derartigen Algorithmus (logische und syntaktische Fehler seien erledigt) die Anforderung abdecken? Oder muss ich für den "Labor"test weitere Rahmenbedingungen berücksichtigen?

Es liegen vor : Umgebungstemperatur, Schwellenwert, Standort und Bewegungsspielraum, i.e. Größe des „Käfigs“.

BTW : Wir sind inzwischen (im Kopf) so weit, dass wir einfach einen Modellmotor mit zwei Wellen an den Prozessor flanschen. Dieser Motor bewegt dann zwei Raupenketten (spart die explizite Lenkungsansteuerung). Diese Raupen wie auch den optisch imposanten Rest des Modells werden wir einfach mit LEGO umsetzen *g*.

Besten Dank nochmals.

Gruß Eillicht zu Vensre

[Semjon_Michailowitsch_580bb3]

Hallo.

Also : Kann man mit einem derartigen Algorithmus (logische
und syntaktische Fehler seien erledigt) die Anforderung
abdecken? Oder muss ich für den "Labor"test weitere
Rahmenbedingungen berücksichtigen?

Lass das Ding auch gegen den
Temperaturgradienten (hoch-)
fahren, und zwar proportional P:
P( T_alt > T_neu) => 1
P (T_alt if rand(0…1)

[Reinhard_Kern_4bc529]

Prost, Gemeinde.

Ganz prinzipiell nur : Verändert sich Bedingung X, verändert
das System den Standort.

Hallo Eillicht,

es gibt ja solche Einfach-Automaten, die sich z.B. wie Insekten verhalten und dem Licht zustreben oder der Dunkelheit usw., aber dein Entwurf führt meiner Meinung nach nicht zu sinnvollem Verhalten: dazu wäre es notwendig, einem Konzentrationsgefälle zu folgen, soll heissen, ein lichtscheues Gerät müsste vom Licht weg fahren - und nicht irgendwohin. Das würde nur dazu führen, dass dein Robbie ziellos umherirrt.

Gruss Reinhard

[StefanS_8166b2]

Mahlzeit!

Ich bin eher unsicher (weil für mich Datenbankeumel so eine
Fragestellung nicht alltäglich ist), ob meine
grundsätzlichen Überlegungen richtig sind.

Prinzipiell denke ich schon, der Teufel liegt wie immer …

Also : Kann man mit einem derartigen Algorithmus (logische
und syntaktische Fehler seien erledigt) die Anforderung
abdecken? Oder muss ich für den "Labor"test weitere
Rahmenbedingungen berücksichtigen?
Es liegen vor : Umgebungstemperatur, Schwellenwert, Standort
und Bewegungsspielraum, i.e. Größe des „Käfigs“.

Wenn du nur einen Bewegungsspielraum hast dann wird es problematisch.

1. Startbedingung
   Du mußt du dem Ungetüm sagen wo im Raum es steht, OK man
   fängt immer an der gleichen Stelle an.

Mit linear Motoren kannst du nicht bestimmen wie weit du gefahren
bist. Nach einiger Zeit wird die rechnerische Position erheblich von
der tatsächlichen Position abweichen.
Lösungen wären:
a)
Du kannst die Position irgendwie ermitteln (GPS hüstel, induktiv,
Stoßsensoren, Lichtschranken in den Räder, Schachmuster auf der Erde,
Kameras, etc.)
b)
Du benutzt Schrittmotoren.

Was passiert wenn Hindernisse im weg sind?

Ein elektrischer lesbarer Kompass würde das navigieren vom FlieWaTüt
auch wesentlich erleichtern.

Wie du siehst ist nach meiner Meinung die Positions- und
Lage-bestimmung ein wesentliches Problem der Aufgabe.
Falls es allerdings nur heißt, „Mach dich aus dem Staub vor dem
Licht“, bis zur nächsten Wand dann sollte es gehen.

Das du weißt, dass man die erste und zweite Ableitung eines Signals
benötigt um Gradienten zu erkennen, davon gehe ich mal aus. Auch
davon, dass man mal einen moment an einer Stelle stehen bleiben muß
um den Gradienten zu bekommen.

Gruß
Stefan

[Eillicht_zu_Vensre_ac055a]

Hallo, Reinhard.

Besten Dank - an dieser Stelle auch an die anderen Antwortenden.

es gibt ja solche Einfach-Automaten, die sich z.B. wie
Insekten verhalten und dem Licht zustreben oder der Dunkelheit
usw., aber dein Entwurf führt meiner Meinung nach nicht zu
sinnvollem Verhalten: dazu wäre es notwendig, einem
Konzentrationsgefälle zu folgen, soll heissen, ein
lichtscheues Gerät müsste vom Licht weg fahren - und nicht
irgendwohin. Das würde nur dazu führen, dass dein Robbie
ziellos umherirrt.

In diesem Schritt ist auch genau das gefordert. Es geht eigentlich darum, zu beweisen, dass die Reaktion auf äußere Einflüsse prinzipiell möglich ist, auch ohne dass das Gerät irgendetwas von seiner Umwelt weiß. Sprich, ohne Sensoren, Detektoren oder andere „Sinnesorgane“ einem äußeren Reiz zu „folgen“. Alles, was später folgen soll, wird natürlich mit entsprechenden „Wahrnehmungsorganen“ ausgerüstet sein (wie erwähnt, Zusammensetzung der Atmosphäre usw. usf.).

Du fragst Dich jetzt vermutlich - mit Recht -, was denn ein „Roboter“ für einen Zweck hat, der nicht mit seiner Umwelt interagiert, sondern einfach in der Gegend herumdüst?

Ich darf nicht zuviel darüber verraten, aber es soll im Endeffekt bezwecken, dass das Gerät auch dann, wenn alle Verbindungen zur Außenwelt (Netzwerk, Ortungssysteme oder was weiß der Geier) nicht mehr tun (der „Robbie“ also auf sich allein gestellt ist), trotzdem einen, nennen wir ihn einmal Alarm, auslöst. Sprich : es ist dunkel, die Luft ist bäh, die Elektrik im Areal ist ausgefallen, nur der Robbie tut noch. Die einfachere Möglichkeit besteht darin, Alarm auszulösen, wenn für eine gewisse Zeitspanne keine Sendungen mehr ankommen. Man möchte aber die kompliziertere Variante haben

Robbie müsste also unter oben genannten Bedingungen einen außerhalb des kontaminierten Areals angebrachten Schalter drücken. Das geht relativ einfach per Kontaktschwelle. Es reicht aber nicht, zu sagen „wenn die Bedingungen an der Stelle, wo du dich befindest, bäh sind, dann fahre zum Punkt x/y [wo der Schalter sitzt]“, sondern es heißt „wenn die Bedingungen in der Fläche bäh werden, dann hau ab“.

Dass das prinzipiell geht, auch ohne dass der Robbie (im eigentlichen Sinne) kommuniziert, möchte ich beweisen. Nix weiter (erstmal). Pst, geheim : wir wollen den Fürsten ein Budget aus den Rippen leiern und müssen deswegen rapidement so einen Prototyp haben.

Gruß Eillicht zu Vensre

[Peter_TOO]

Hallo Eillicht,

Ich darf nicht zuviel darüber verraten, aber es soll im
Endeffekt bezwecken, dass das Gerät auch dann, wenn alle
Verbindungen zur Außenwelt (Netzwerk, Ortungssysteme oder was
weiß der Geier) nicht mehr tun (der „Robbie“ also auf sich
allein gestellt ist), trotzdem einen, nennen wir ihn einmal
Alarm, auslöst. Sprich : es ist dunkel, die Luft ist bäh, die
Elektrik im Areal ist ausgefallen, nur der Robbie tut noch.
Die einfachere Möglichkeit besteht darin, Alarm auszulösen,
wenn für eine gewisse Zeitspanne keine Sendungen mehr
ankommen. Man möchte aber die kompliziertere Variante haben

Robbie müsste also unter oben genannten Bedingungen einen
außerhalb des kontaminierten Areals angebrachten Schalter
drücken. Das geht relativ einfach per Kontaktschwelle. Es
reicht aber nicht, zu sagen „wenn die Bedingungen an der
Stelle, wo du dich befindest, bäh sind, dann fahre zum Punkt
x/y [wo der Schalter sitzt]“, sondern es heißt „wenn die
Bedingungen in der Fläche bäh werden, dann hau ab“.

OK, wenn alles zusammenbricht muss Robi ja seine XY-Koordinaten noch irgendwo gespeichert haben, zudem kennt er die XY-Koordinaten des Schalters. Soweit alles richtig ??

OK, dann hol die mal ein SChachbrett

1. Wenns dem Robi zu bäh wird, geht er ein Feld richtung Schalter.

2. Ist es da weniger bäh, macht er einen weiteren Schritt in diese Richtung, bis er beim Schalter angekommen ist.

3. Ists nach dem Schritt 1. noch bäher, wars die falsche Richtung, also ein Feld zurück und eine andere Richtung wählen.

Ich würde dabei auch noch eine Karte zeichenen und die Bähigkeit der besuchten Felder eintragen. Möglicherweise ist er ja vom Bäh umzingelt und muss dann einen Ausfall versuchen, also Nase zu und dort wo das Bäh am wenigsten war mal einen Schritt weitergehen.

OK, bei der Karte kommt jetzt noch die Zeit und Form des Bäh hinzu. Ein Feuer breitet sich ja aus. Je nachdem kann es auch sinnvol sein es da weiter zu versuchen wo das Bäh am stärksten war, weil dort nach 5 Minuten das Feuer schon alles verbrannt hat.

Mit bähen Grüssen
Peter(TOO)

[Eillicht_zu_Vensre_ac055a]

Hallo.

OK, wenn alles zusammenbricht muss Robi ja seine
XY-Koordinaten noch irgendwo gespeichert haben, zudem kennt er
die XY-Koordinaten des Schalters. Soweit alles richtig ??

Das ist schon wieder vieeel zu viel Bähtionalität

Der weiß nicht, wo er im gegebenen Moment ist (in meinem Modell weiß er nur, wo er im Moment x-1 war, das ist das einzige Zugeständnis). Er wird nämlich auch nach dem Prototypstadium keine Ortungssoftware bei sich tragen - das wäre dann ja einfach. Und wo der Schalter von seiner augenblicklichen Position aus ist, weiß er auch nicht. Er muss im Grunde nur entscheiden können, ob seine jetzige Position bäher, genauso bäh oder unbäher ist als die vorherige. Ist sie bäher, soll er zur vorigen Position laufen. Ist sie genauso bäh, soll er weiterlaufen (alles außer rückwärts). Ist sie unbäher, soll er die Richtung beibehalten. Ist eine bestimmte Fläche gleichmäßig bäh (nein, bäh>Grenzwert), ist das die Alarmbedingung, aber erst in einer späteren Phase; in der Prototyp-Phase soll das noch keine Spiele rollen.

Bähsten Dank fürs Mitdenken.

Gruß BähEillicht zu Vensre

[Peter_TOO]

Hallo Eillicht,

Lese ich da einen kleinen Wiederspruch ??

Also eine Map hat der Robi nicht, aber er soll entscheiden wenn ein bestimmtes y Areal = (bäh>Grenzwert) ist ??

Irgendwie muss er aber dazu in der Lage sein Strecken zu schätzen. Also zumindest in der, ungenauen, Form, Zeit mal eingestellte Speed mal Akkuspannung oder so ähnlich.

mit verbähten Grüssen
Peter(TOO)

[Eillicht_zu_Vensre_ac055a]

Huhu.

Also eine Map hat der Robi nicht, aber er soll entscheiden
wenn ein bestimmtes y Areal = (bäh>Grenzwert) ist ??

Richtig. Und zwar dergestalt, dass er eben soundsoviele Felder anfährt. Ist der Bäh in allen Feldern > Grenzbäh, dann …

Überitzens hat er heute Nachmittag seinen ersten Probelauf gehabt. Auf den Fön reagiert er, auf die Taschenlampe innerhalb 3 Minuten nicht. Wir haben ihm ein 5x5-Feld gebaut, und er fährt tatsächlich mit Trial&Error dorthin, wo er am weitesten vom heißen Luftstrom entfernt ist. Meine Kollegen ermitteln zur Zeit per Versuchsreihe, ob sich das Verhalten immer ähnlich gestaltet oder ob Ausreißer nach oben bzgl. der Reaktionszeit drin sind. Ich werde mich mal damit befassen, ob er nicht beim Wegfahren Bäh sagen kann

Wenn nichts dazwischen kommt, ist am nächsten Dienstag die große Vorführung in einem 20x20-Raster.

Aufgabenstellung : very strange für einen alten Bitschieber, aber interessant.

Gruß Eillicht zu Vensre

[Peter_TOO]

Uhu Eillicht,

Also eine Map hat der Robi nicht, aber er soll entscheiden
wenn ein bestimmtes y Areal = (bäh>Grenzwert) ist ??

Richtig. Und zwar dergestalt, dass er eben soundsoviele Felder
anfährt. Ist der Bäh in allen Feldern > Grenzbäh, dann …

Aber das ist ja schon eine Map !!!

Aufgabenstellung : very strange für einen alten Bitschieber,
aber interessant.

Du bist eher noch zu jung !!
So in den 70er, als „Graphik“ noch aus Buchstaben bestand, gab es schon ein Ein Spieleprogramm „Mäuse im Labyrinth“.
Zuerst wurde ein Gitter erstellt, mit RAND() Ein- und Ausgang festgelegt und dann weiter mit RAND() Wände gelöscht …
Dann suchten sich die „Mäuse“ den Weg durch, am einfachsten mit der Links- oder Rechts-Regel.

Mein Onkel und ich, haben dann den Mäusen noch etwas intelligenz verpasst, weil die Typen von Wang der Meinung waren, dass sowas nicht machbar sei. Im Prinzip hat jede Maus in jedem betretenen Feld einen Richtungswektor hinterleg, also eine einfache Spur hinterlassen. Die nächste Maus, hat dann alle Felder gemieden, bei denen die vorherige Maus auf sie zugekommen wäre. Dadurch fanden die weiteren Mäuse schneller durch.

Hardware: Wang 2200 VP … so 16KiByte RAM, BASIC, aber frag mich nicht nach dem Takt

MfG Peter(TOO)

[Eillicht_zu_Vensre_ac055a]

Na, Du Fossil

Du bist eher noch zu jung !!

Diese besondere Feststellung wäre aber doch mit etlichen Pfund Salz zu nehmen. Meine ersten Schritte datieren auf das Jahr 1976 (kann auch 77 gewesen sein, hau mich nicht). Auf dem TI-59 mit Magnetkarten gefuhrwerkt, auf dem guten alten ZX-81 mit der unglaublichen Speichermenge von 1k Textverarbeitung betrieben. Und im Jahre 1979 unter BS 1000 einen Stapel Lochkarten fabrizoren, der, in der richtigen Reihenfolge eingelesen, den Sorter dazu brachte, den River-Kwai-Marsch zu spielen [||:ft-ft, ft-ft-ft ft-ft-ft:expressionless:|ft-ft ft-ft-ft-ft-ft ft-ft-ft-ft-ft ft-ft-ft ft-ft). Also Multimedia … *g*

*It’s time to go back to technology that actually WORKS!*

Gruß Eillicht zu Vensre

[Peter_TOO]

Uhu Eillicht,

Na, Du Fossil

Nein, das war ein Treiber für Modems )

Du bist eher noch zu jung !!

Diese besondere Feststellung wäre aber doch mit etlichen Pfund
Salz zu nehmen. Meine ersten Schritte datieren auf das Jahr
1976 (kann auch 77 gewesen sein, hau mich nicht).

1976 habe ich beruflich meine erste Hardware entwickelt, und 6502 Programme von Hand assembliert --> KIM 1

Meine ersten Schritte waren 1972, mit „Klingonen abschiessen“, auf dem besagten Wang.

Den TI (War das noch der 52er ??), mit Magnetkarten, habe ich schon 1975 wieder beiseite gelegt, weil der Speicher zu klein war um vernünftie Filterberechnungen zu programmieren reichte der Speicher nicht. Und der Trick mit Magnetkarten nachladen brauchte länger als das ganze von Hand mit Taschenrechner zu berechnen (

TI59 hab ich noch zwei hier und einen passenden Drucker dazu.
Die akkus sind zwar futsch, aber vor 2 Jahren funktionierte noch alles.

Also hast du doch zu spät angefangen )

MfG Peter(TOO)

[erichsz]

Kennst du das:
Braitenberg, V.: Vehikel. Experimente mit kybernetischen Wesen. Rowohlt Taschenbuch, Deutschland (1993) [Note: Neudruck im LIT-Verlag, Münster (2004), ISBN 3-8258-7160-6 Buch anschauen]

englische Version:
Vehicles, Experiments in Synthetic Psychology
MIT Press

http://www.kyb.mpg.de/~braitenb

Genuss und Gewinn wünscht dir
Erich