weltweit erstes Neuronales Jordan Netz auf Arduino Due !

[HaWe]

ich bin nicht sicher, ob ich dich richtig verstehe - aber über Backpropagation Learning laufen sowohl das "einfache" als auch das Jordan Backpropagation Netz.
Beide Netze können grundsätzlich ihre Lern-Matrix auf SD Card speichern und wieder abrufen.
Der Unterschied ist, dass das Jordan-Netz auch bei identischen punktuellen Sensorkonstellationen berücksichtigen kann, wie sich ihr ZUstand in der zurückliegenden Vergangenheit entwickelt hat: hier habe ich es erklärt:
http://www.mindstormsforum.de/viewto...&t=5601#p67272

Begonnen habe ich aber nicht mit Backpropagation, sondern mit einschichtigen Feed-Forward-Netzen und der der Perception Training Rule.

Die Skalierbarkeit heißt nichts anderes, als dass ich die Netzmatrix-Dimension frei durch einfache Definitionen der Arraygrößen vorwählen kann, so kann ich die Netzgröße und die Anzahl der gelernten Input-Output-Pattern den Erfordernissen und der cpu bzw. dem verfügbaren RAM jederzeit anpassen, ohne das ganze Programm neu schreiben zu müssen. Alle Neuronen samt allen ihren Verknüpfungen miteinander in sämtlichen Schichten werden automatisch angepasst und korrekt initialisiert. Einfach nach Größenänderung neu kompilieren, fertig, läuft.

Im Moment ist es für den DUE ausgereizt, für größere cpus / RAM könnte man es noch ein Riesen-Stück hochskalieren (hätte man z.B. einen TRE mit Sitara und mit 1GB statt 96kB RAM samt Sketch/Wiring per Arduino IDE). Da es den aber nicht gibt, ist hier für mich erstmal Ende Gelände mit dem momentanen Ausbau.
https://blog.arduino.cc/category/arduino/tre/

Aber vielleicht kommt er ja doch noch irgendwann, oder irgendwer bringt irgendwann WiringPi samt Arduino-IDE auf einem Raspi etc. zum Laufen.

Nicht verstanden habe ich allerdings deine Frage "Die Realtime Berechnungsgrenzen und Lernzeit über native code zu optimieren hat Dir wieviel an Zeit gebracht?"

[Robobionic]

Begonnen habe ich aber nicht mit Backpropagation, sondern mit einschichtigen Feed-Forward-Netzen und der der Perception Training Rule.

Klar, mir gings um Deinen Plan und Implementierung der mehrschichtigen Netze.
Dein Netz hat zu dem Zeitpunkt also immer alles neu berechnet aber noch nicht gelernt , zumindest konnte es durch Erfahrung noch keine Entscheidungen treffen.

Nicht verstanden habe ich allerdings deine Frage "Die Realtime Berechnungsgrenzen und Lernzeit über native code zu optimieren hat Dir wieviel an Zeit gebracht?"

Speichergrenzen waren für Dich ja keine optimalen Voraussetzungen wegen limitierter Neuronen.
Durch die Abhängigkeit mehrschichtiger Netze musstest Du ja das Lerntraining optimieren.

Waren native Executables nur Deine Theorie, oder hast Du dadurch die Performance der NXC VMs in den Griff bekommen?

Im Moment ist es für den DUE ausgereizt, für größere cpus / RAM könnte man es noch ein Riesen-Stück hochskalieren (hätte man z.B. einen TRE mit Sitara und mit 1GB statt 96kB RAM samt Sketch/Wiring per Arduino IDE). Da es den aber nicht gibt, ist hier für mich erstmal Ende Gelände mit dem momentanen Ausbau.
https://blog.arduino.cc/category/arduino/tre/

Das hatte mich interessiert, danke.

[HaWe]

Ach so, du meinst die beiden Plattformen NXT vs. DUE im Vergleich...:

cpu-Takt NXT=48MHz, DUE=84 MHz,
RAM NXT =48kB , DUE=96kB

Viel extremer sind aber execution speed und auch verfügbares RAM während der Laufzeit, da der NXC-Bytecodeinterpreter sehr langsam ist und selber als VM auch RAM benötigt (frei mit NXC-VM=30kB). Mein Benchmark-Test http://www.mindstormsforum.de/viewto...p=64772#p64772 verdeutlicht es besser.

Die Geschwindigkeit von Sketch C Execetubles auf Arduino DUE gegenüber NXC-Bytecode ist bei dieser Applikation (mit überwiegend float-Arithmetik, aber auch umfangreicher Pointer-Nutzung ) in etwa 200x schneller.

(edit: ) Was die Netzarchitektur angeht, so bietet der DUE grob geschätzt ein halbes Dutzend mal so viel Speicher für Neuronen, direkt vergleichen kann ich es nicht, da FF- und Jordan-Netze in ihrem Code nicht vergleichbar sind. Allein die Jordan-Netzstruktur verschlingt aber schon extrem viel RAM, besonders beim Training für temporäre Variablen (gut noch mal so viel wie das reine Netz).

[HaWe]

gerade erst gelesen...:

Dein Netz hat zu dem Zeitpunkt also immer alles neu berechnet aber noch nicht gelernt , zumindest konnte es durch Erfahrung noch keine Entscheidungen treffen.

nee, wie kommst du darauf? Dinge lernen und entsprechend der Netzmatrix aus den Inputs (Reizen) die entsprechenden Outputs (Reaktionen) generieren, dann gelernte Dinge als "Gedächtnis" auf Flash oder SD speichern, später wieder ein "Gedächtnis" der gelernten Dinge laden:
das könnrn bzw. konnten alle Netze (bereits schon die FF-Netze auf dem NXT), es ist ja nur eine simple Datensatz-schreib/lese-Funktion, die unabhängig vom Netz mit allen möglichen Daten funktioniert. Ich habe lediglich ein paar neue SD-API-Funktionen ähnlich denen von stdio.h dafür zusätzlich geschrieben (u.a. fprintf und fscanf), da es sie bei Arduino noch nicht gab.

[Robobionic]

Hallo HaWe, da habe ich mich wohl etwas missverstaendlich ausgedrueckt.

Ich war davon ausgegangen das Du Dir am Anfang noch nicht sicher ueber die Anforderungen und zukuenftige Entwicklung warst.

Ich kam darauf weil Backpropagation keine Moeglichkeiten fuer "Erinnerungen" bietet. Ich dachte dies sei der Grund fuer Dich gewesen weshalb Du es dann erst spaeter mit Jordan umgesetzt hast.

[HaWe]

ich glaube, das mit den "Erinnerungen" hast du falsch verstanden.
Erinnern an gelernte Muster kann sich jedes Netz (z.B. beim mobilen Robot bei <50 cm Abstand ein Hindernis umfahren oder beim Anstoßen in Stück zurückfahren),
aber ein Jordan Netz hat noch ein zusätzliches "automatisches Kurzzeitgedächtnis", um Situationen besser einzuordnen ("Was ist gerade kurz vorher geschehen und was hat sich soeben verändert?").
Wenn nämlich der Abstand jetzt zwar 49cm ist, aber kurz vorher war er noch 47cm, dann entfernt er sich ja bereits wieder und muss gar nicht mehr irgendwas umfahren. Das könnte z.B. bei einem Tier als Hindernis passieren, das sich inzwischen bewegt hat - oder er fährt bereits schon schräg dran vorbei oder sogar rückwärts - oder was auch immer.
Ich fürchte, du musst dazu wirklich mal eine gewisse Zeit investieren, um dich in die Theorie der Neuronalen Netze einzuarbeiten... bei mir sind es insgesamt fast 10 Jahre, allerdings mit enormen Unterbrechungen...

[Robobionic]

Ja, ein spannendes Thema.

Das von Dir genannte Beispiel ist für die praktische Anwendung in der Robotik von hoher Bedeutung.

Je nach Anwendungszweck müssen autonome Roboter so schnell wie möglich auf ihre Umwelt reagieren.
Das hat jetzt nur noch wenig mit Deinem Projekt zutun aber für die zukünftige Netze ist es ein unverzichtbares Thema.

In der Praxis haben bisherige Modelle neuronaler Netze einige Nachteile, eines davon ist das wir vorhandenes Wissen nicht
auf autonome Systeme übertragen können. Erfahrungen kann man nicht kopieren und vererben sondern müssen immer trainiert werden.
Erschwerend hinzu kommt das Trainingsdaten nur simuliert werden und sehr Anwendungsspezifisch sind.

Kompliziert wird es also immer dann wenn ein autonomes System vor ungelösten Aufgaben steht.
Die Königsklasse künstlicher Intelligenz.

Um Entscheidungsbäume zu entwickeln braucht es immer Antworten die sich durch mangelnde Erfahrung
in bisher gelernten Mustern nicht so leicht finden lassen. Das System ist also Situationsbedingt
unfähig selbstständig zu entscheiden.

Um das zu verbessern orientiert man sich heute immer mehr an der Funktionsweise des menschlichen
Gehirns, genauer gesagt an unserem Großhirn. Den Ansatz verfolgt auch IBM mit True North,
ein Prozessor der die Neocortex von Säugetieren in einfacher Form simuliert.

Die Leistung wird aber erst durch Spiking Netze möglich die sich somit auch besser eignen als Multilayer Perceptron
vor allem dann wenn es sich um Anwendungsbereiche wie Sensorik und Mustererkennung handelt.

[HaWe]

das klingt jetzt wie irgendwo abgeschrieben...
aber es stimmt so nicht ganz:

Selbstverständlich ist mein Jordan Netz für den DUE ja als autonomes System konzipiert,
gelerntes / trainiertes Wissen kann in mannigfaltiger Weise auf SD abgespeichert werden,
und wenn das Netz (als compiliertes .ino- Programm) auf einem anderen Due hochgeladen wurde, dann kann man selbstverständlich die woanders trainierten Daten auch hier von der originalen oder einer beliebigen kopierten SD card lesen, verarbeiten, modifizieren, abspeichern, und dann wieder auf der ersten oder einer 3. oder 4. MCU lesen, laden, und verarbeiten.

Aber selbst wenn der Netz-.ino-Sourcecode in seiner Struktur nicht per Arduino IDE für den DUE kompiliert wurde, sondern auf GCC/Geany für RasPi portiert wurde und als .cpp source für den Raspi kompiliert wurde (nur die reine Netz-Architektur muss die gleiche sein, damit alle Inputs und Outputs an den gleichen Array-Stellen landen), selbst DANN kann man das auf dem DUE trainierte Netz-Gedächtnis (sein erworbenes "Wissen") auf den Raspi kopieren - und es wird in identischer Weise auch dort laufen.

Das ist hier ja auch gerade ein - für manche Leser - neuer Aspekt meines autonomen Netzes.

Und du brauchst dir nur sämtlich Gewichte und Schwellwerte sämtlicher Neuronen auf einem Display anzeigen zu lassen (es sind ja alles nur simple floats in durchnummerierten arrays), schon hast du das Gedächtnis in "Zahlenform" und kannst direkte float-Werte bestimmter Neuronen manuell patchen - und schon hast du das Gedächtnis manuell modifiziert und kannst auch diese Gedächtnisversion wieder abspeichern für später. Genau so funktioniert ja auch das Speichern und Lesen des Gedächtnisses auf SD !

Willst du hingegen beim autonomen Betrieb (!) direkt bestimmte Input-Konstellationen mit einer bestimmten output-Reaktion "manuell designen" (d.h. manuell erstellte Matrix-patterns) , so kannst du dies auch tun:
Das User-Interface meines Programms bietet die Möglichkeit dazu!
Einfach nach dem input-output-verknüpfen per Knopfdruck einen neuen Trainingslauf durchführen (kannst du autonom ebenfalls jederzeit zwischendurch tun!), schon ist auch das neue manuell eingegebene pattern zusätzlich gelernt!

Aber auch andere von dir angeführte theoretische oder generelle Aspekte deines letzten Posts stimmen nicht, ich will aber jetzt hier nicht weiter darauf eingehen, denn es führt hier deutlich zu weit, und muss daher wieder auf entsprechende Lehrbücher verweisen.


ps,
Interessant finde ich allerdings die Frage, warum du hier in diesem Thread per Gastaccount schreibst - du bist doch sicher hier auch registrierter Benutzer in diesem Forum und schreibst hier sicher nicht zum ersten Mal - warum versteckst du dich also hinter "Robobionic (Gast)" ?

[Robobionic]

das klingt jetzt wie irgendwo abgeschrieben...
aber es stimmt so nicht ganz:

Selbstverständlich ist mein Jordan Netz für den DUE ja als autonomes System konzipiert,
gelerntes / trainiertes Wissen kann in mannigfaltiger Weise auf SD abgespeichert werden,
und wenn das Netz als Programm auf einem anderen Due hochgeladen wurde, dann kann man selbstverständlich die woanders trainierten Daten auch hier von der originalen oder einer beliebigen kopierten SD card lesen, verarbeiten, modifizieren, abspeichern, und dann wieder auf der ersten oder einer 3. oder 4. MCU lesen, laden, und verarbeiten.

Wie bereits erwähnt ging es in meinem Beispiel nicht mehr um Dein Projekt sondern allgemein um die Netztypen und ihre Leistung.
Die Nachteile haben also nichts mit baugleichen Robotern zutun bei denen man einfach mal von A nach B kopiert sondern
mit dem Wissen unabhängiger Systeme das man theoretisch teilen könnte, technisch aber noch nicht möglich ist.

[HaWe]

doch, auch das geht:
wenn du eine wichtige Verknüpfung (ganz simpel: auf einen bestiimten Sensor-Input einfach eine Rechtskurve fahren) auf einem Robi gelernt hast, dann brauchst du dieses input-output-Muster nur auf das andere System transponieren (ggf. die array-Indizes anpassen, wenn einmal der besagte Button an Input 10 hängt und das andere Mal an Input 11 und einmal die Motoren an D22-D31 und das andere Mal an D32-D41... das kann sogar automatisiert beim Einlesen der Daten erfolgen!) - und schon kann der 2. Robi genau das, was der 1. gelernt hat, nämlich bei einem bestimmtem Buttonclick rechtsrum fahren, selbst wenn der 1. einen ganz anderen Hardwareaufbau und ganz andere weitere Sensoren besitzt: alles was dazu nötig ist wäre ein Verfestigen des neuen Wissens per einmaligem Trainingszyklus.

Aber natürlich gilt das mit Einschränkungen, gewisse Ähnlichkeiten der Netze müssen schon vorhanden sein, man kann ja auch (bisher) kein Vogel-Gedächtnis auf einen Goldfisch portieren.