Python KI in C einfügen

Für den Produktionseinsatz eines trainierten neuronalen Netzes ist es 
normalerweise nicht so wichtig womit es trainiert wurde. Nach dem 
Training speichert man Struktur und Parameter des Netzes in einem einem 
geeigneten Format ab (z.B., Tensorflow, ONNX), und verwendet dann eine 
kompatible Runtime-Bibliothek die das Netz mit Eingangsdaten füttert und 
die Ausgänge berechnet. Für hardwarenahe Anwendungen gibt es z.B. 
Tensorflow Lite (läuft z.B. auch auf einem Cortex M3 Mikrocontroller, 
siehe https://www.tensorflow.org/lite/microcontrollers). Tensorflow hat 
allgemein den Ruf den Übergang vom Training zum Produktionseinsatz 
relativ einfach zu machen. Für das "offenere" ONNX-Format gibt es auch 
Runtimes (https://github.com/microsoft/onnxruntime), aber das Ökosystem 
ist da m.W. noch nicht ganz so gut aufgebaut.

Timon schrieb:
> Ich habe vor ein künstliches neuronales Netz (KI) z.B.: auf einen
> Computer , Roboter usw. zuladen damit die hardware Bilder zuordnen kann
> zuladen aber die KI ist in Python geschrieben und wenn die hardware in C
> geschrieben ist ob man die irgendwie einsetzen könnte oder übersetzen
> das der Computer das versteht?

Mit Nuitka [1] und Cython [2] stehen gleich zwei Transpiler zur 
Verfügung, die Python-Code in C übersetzen können. YMMV.

[1] https://nuitka.net/
[2] https://cython.org/

Die Frage geht in die falsche Richtung.

Niemand baut eine Riesenanwendung, in der alle Funktionalitäten 
enthalten sind. "KI", Sensoren, Planung, Regelung etc. sind komplett 
separate Komponenten (im einfachsten Fall einzelne Programme), die 
irgendwie über festgelegte Schnittstellen miteinander kommunizieren.

ROS wäre ein Beispiel. Ob eine Komponente in C++, Python oder INTERCAL 
geschrieben ist, ist egal (und von außen nicht sichtbar), solange sie 
ihre Ein- und Ausgangsdaten mit ROS-Botschaften abwickelt.

Tom schrieb:
> Die Frage geht in die falsche Richtung.
>
> Niemand baut eine Riesenanwendung, in der alle Funktionalitäten
> enthalten sind. "KI", Sensoren, Planung, Regelung etc. sind komplett
> separate Komponenten (im einfachsten Fall einzelne Programme), die
> irgendwie über festgelegte Schnittstellen miteinander kommunizieren.

Das ist das Prinzip moderner Microservice-Architekturen, das gegenüber 
klassischen Monolithen zwar klare Vorteile -- Modularisierung, 
Austauschbarkeit von einzelnen Komponenten, geringere Komplexität der 
Einzelkomponenten, Technologieunabhängigkeit, ... -- hat, aber leider 
auch gewisse Nachteile. Insbesondere ist hier der zusätzliche Aufwand 
für die Kommunikation zu nennen, der eine zusätzliche Komplexität sowie 
eine gewisse Latenz bedeutet und daher in bestimmten Anwendungsfällen 
inadäquat ist. In Anwendungsfällen, in denen harte oder echte Echtzeit 
gefordert ist, oder in denen besonders große Datenmomolithen verarbeitet 
werden müssen, kann das ein zwingendes Ausschlukriterium für 
Microservice-Architekturen sein.