echtzeitfähiges Ethernetprotokoll?

[Klebwax]

Also ich bräuchte dieses Protokoll für ein kleines Projekt von mir:

Ich will mit meinem Computer einen Roboter steuern, allerdings kommt es dabei auf Reaktionsvermögen an - ich brauche also harte Echtzeit

Hallo,

so einfach ist das mit so einem Begriff "harte Echtzeit" nicht. Wie schon Andre_S angemerkt hat, definiere mal "Reaktionsvermögen". Ich kann auch einen Roboter mit einer Trillerpfeife steuern, der Pfiff heißt: mäh mal den Rasen und fahr dich dann aufladen. Wenn er dann losmacht, ist das ganz schön Echtzeit (meine Kinder waren da eher nicht echtzeitfähig ).

Mit Ethernet kann man schon eine ganze Menge erreichen, ohne auf die Echtzeiterweiterungen zurückgreifen zu müssen. Planung und Systemanalyse ist dafür aber fast wichtiger als programmieren. Was man sicher nicht hinkriegen wird, ist Schrittmotoren mit STEP und DIR über das Netz zu steuern. Aber eine CNC so mit G-Codes zu steuern, daß sie nie ins Stottern kommt, sollte machbar sein.

MfG Klebwax

[Manta]

oke! also ich denke mal das ich mir das ganze etwas einfacher vorgestellt habe als es wird! ich hatte vor meinen Bot mal "einfach" von meinem Pc aus anzusteuern und das so das wenn ich ihm sage "Arm hoch" das er das dann auch umgänglich macht! also das zwischendurch keine zeit verstreicht! aber da ich hier anscheinend einen gravierenden denkfehler gemacht habe muss ich eingestehen das ich daneben lag! kann ja mal passieren!
hat hier jemand vllt eine idee wie man sowas anders lösen könnte?
ethernet war mein ausgangspunkt weil ich mir vor einiger zeit einen µC oder besser ein ganzes evaluierungsboard gekauft habe das eine solche schnittstelle besitzt. da hab ich mir gedacht wäre ja mal nett das teil auch zu verwenden wenn es schon da ist .
ich stells jetzt mal einfach so in den raum: hat hier jemand eine idee wie man das anders lösen könnte?
wenn es dafür für nöten ist ich habe folgende kenntnisse:
programmiersprachen: assembler, C und C++ (bevorzugt aber C)
elektrotechnische kenntnisse sind ganz oke und mein wissen bezüglich datenübertragung stufe ich mal selbst als mittel ein! - aber bin immer bereit was neues zu lernen und mich auch gründlich damit auseinander zu setzen

lg Manta

[shedepe]

Mit einem uC wirst du das ganze dennoch so umsetzen können, dass es für dich als "Echtzeit" erscheint. Der PC muss dem Controller ja nicht mehr senden als den Befehl: "Arm hoch", was ja ziemlich schnell zu übertragen ist.

[Manta]

naja bei einem befehl wie "arm hoch" ist das ja noch machbar, aber wie schaut das ganze dann mit z.B. einem fahrgestell aus?wenn der bot geradefährt und dann ausweichen muss, muss er sofort ausweichen. ja das kann man auch mit Sensoren lösen z.B. abstandsensoren usw. aber mir wäre es lieber wenn ich das selbst könnte!

lg

[shedepe]

In dem Fall wäre die langsamste Komponente warscheinlich Du.

[Ceos]

naja bei einem befehl wie "arm hoch" ist das ja noch machbar, aber wie schaut das ganze dann mit z.B. einem fahrgestell aus?wenn der bot geradefährt und dann ausweichen muss, muss er sofort ausweichen. ja das kann man auch mit Sensoren lösen z.B. abstandsensoren usw. aber mir wäre es lieber wenn ich das selbst könnte!

lg

du beliebst zu scherzen, oder ? wie groß schätzt du bitte die Verzögerung ein, wenn du z.B. ein Hinderniss mit einer Webcam oder ähnlich erkennst und den Befehl "ausweichen" gibst und zum Bot sendest? Ich sags mal so:

Licht in Cam zu Bild wandeln -> 100-500ms ?! (je nach qualität der cam)
Bild von Cam an PC senden -> 10ms ?!
Bild in Anwendung laden -> 10ms ?!
Bild analysieren und Hinderniss erkennen -> 100-500ms ( je nach qualität der Erkennungsmethode )
Befehl an Bot senden (per Netzwerk) -> 1mS
Befehl im Bot zerlegen und Reaktion einleiten -> 50-100ms

die Werte sind alle nur geschätzt und gewichtet um dir mal zu zeigen wo du wahrscheinlich dran arbeiten musst!

Schau dir mal die ArDrone an, die wird mit IPhone/Pod/Pad per WLAN gesteuert und WLAN ist schon von der Übertragung her eher ungünstig! Und soweit ich das richtig gelesen habe, haben sich sogar ein paar Bastler erlaubt das Ding über seine Kameras vom PC allein steuern zu lassen! ... und die Kameras haben ne gute Sekunde Verzögerung, weshalb sich die Drone schon von Hand nur schwer über die Kameras steuern lässt! .. vll. iss mein IPod auch nur Schrott ^^

[Richard]

du beliebst zu scherzen, oder ? wie groß schätzt du bitte die Verzögerung ein, wenn du z.B. ein Hinderniss mit einer Webcam oder ähnlich erkennst und den Befehl "ausweichen" gibst und zum Bot sendest? Ich sags mal so:

Das dürfte sehr unterschiedlich ausfallen. Ich habe hier ein RN Motorkontrol am eepc über W-Lan und Camera VLC übertragung. Auf dem Rad habe ich ein weißes Isoband geklebt. Wenn diese Marke im Bild auftaucht und ich den Stop button drücke macht das Rad noch locker ~15...20 cm. Die Live Bild Übertragung braucht halt auch etwas Zeit......Als "Echtzeit" würde (ich) das nicht mehr betrachten.

Gruß Richard

[Ceos]

dein Problem wird die Webcam und die Trägheit des Motors sein, die Übertragung eines einfachen Befehls bedarf weniger als 1ms ... es sei denn, die Firmware braucht Ewigkeiten um den Befehl aus der Netzwerkschnittstelle zu lesen!!!

Es kommt alles auf dein Können an! Bzw. die Komponentenauswahl!

RN Motorkontrol: .. kenn ich persönlich nicht, vermute mal 1 Prozessor drauf, der ala Round Robin die Netzwerkschnittstelle nicht sofort abruft sondern nur wenn er grad Zeit hat!

Camera VLC : meinst du jetzt vom VLC Player ? Wenn das Bild erst noch codiert wird ist es kein Wunder dass eine Verzögerung entsteht! Lieber ne Kamera nehmen, die mit entsprechenden Treibern und ner API ausgestattet ist um die Bilder direkt zu lesen! Ich habe hier auf Arbeit mal mit ner 1000 € Cam gearbeitet um ein Echtzeitbild über eine Radarkeule zu legen, als Rechner hatte ich da nen Atom auf nem Mini-ITX und der war schon schwer am schaufeln um nur die Kamera auszulesen! Zwecks Einsparungen wollte ich das Bild vorher übern Codec gehen lassen (ne extra Steckkarte) und dann in die Anwendung laden .... Ergebnis war 1 Sekunde Verzögerung etwa ... aber die Prozessorlast hat sich deutlich verbessert.

Ich will damit nur nochmal betonen, dass es NICHT der OUTPUT ist, der langsam ist, sondern der INPUT!

ACHTUNG: Ich werde hier ein paar Links einstellen um ein paar Möglichkeiten aufzuzeigen die ich persönlich favorisiere, es soll keine Werbung sein!

http://www.dacomwest.de/de/ethermodul.htm unter Gatewaymodule finden sich viele Lösungen für eine easy-use Schnittstelle für µCs ans LAN

alles Weitere ist deinen Künsten im Umgang mit Mikrokontrollern bzw. dem Zukauf entsprechender serielle ansteuerbarer Hardware überlassen (bei seriellen Lösungen habe ich bisher nie irgendwelche Probleme mit verzögerungen festgestellt ... abgesehen von Trägheit)