Stabilste Verbindung der Wifi Extension gesucht

[webster7567]

Hallo,

 

ich hab soeben mein Seilkamera Projekt weiter gebaut und es ist wieder ernüchternd. Wenn ich den ganzen Stapel per USB hab funktioniert alles wunderbar, aber die Wifi Extension macht noch nicht so mit...

 

Aufgrund von gewissen Parametern muss ich auf Situationen im 10 mS bereich reagieren können. Was mir jetzt sehr komisch vorkommt ist das die Wlan Verbindung hänger hat. Das sieht man auch wenn man einen permanenten Ping auf die Extension macht... 20 pings gehen mit 2-3ms durch, dann ist einmal eine Zeitüberschreitung und dann wieder welche mit 60-70 ms.

 

Um hier weiter zu kommen würden mich die Einstellungen interessieren die zur stabilsten möglichen Verbindung führen. Kann man die Übertragungsgeschwindigkeit irgendwie fest einstellen etc. damit keine Außreißer vorhanden sind.

 

Derzeit hab ich mich mit einem Laptop direkt per Adhoc verbunden. Entfernung 30cm...

 

Danke, Karl

 

[borg]

Ich denke die beste Lösung für so ein Projekt ist es, ein kleines Embedded Board (Raspberry PI, BeagleBoard o.ä.) mit auf die Seilkamera zu bringen und die eigentliche Regelung machen zu lassen.

 

D.h. du schickst eine "High-Level Anweisung" per Wi-Fi an das Embedded Board (fahre 10m nach links mit 20km/h) und das Embedded Board macht die eigentliche Regelung.

 

Eine Regelung über Wi-Fi wird nie Echtzeitanforderungen genügen, also nie eine definierte minimale Paketlaufzeit haben.

 

Welche Verbindungsart theoretisch am stabilsten sein könnte kommt sicherlich auf das verwendete Equipment an. Wenn ein AP mit sehr hoher Sendeleistung verwendet wird, kann es denke ich durchaus sein dass eine Verbindung stabiler ist als direkt AdHoc.

[webster7567]

Danke für die Meldung. Ist jetzt natürlich schon blöd wo ich alles gekauft hab 

 

Kann man am WiFi Modul nicht irgendwie einstellen welche Geschwindigkeit er übertragen soll? Ich kenn es nur von den üblichen APs wo man eben genau das machen kann. Und die Tatsache das es ja Daumen mal Pi eine Minute sehr konstant läuft und dann ein Rucker drinnen ist lässt für mich rückschließen das hier was am Modul passierne muss. Ich muss es noch mit einem anderen Notebook versuchen um die Gegenstelle auszuschließen, aber ggf. macht das WLAN modul periodisch einen Check wegen Geschwindigkeitsübertragung etc.

 

Karl

[borg]

Was du probieren könntest ist der Aufbau:

 

PC -> WLAN -> PC -> USB -> Bricks

 

Also sprich: Der Brick Daemon läuft auf einem PC wo der Brick direkt per USB angeschlossen ist und die Kommunikation läuft über Wi-Fi von einem anderen PC aus.

 

Verhält es sich in dem Fall anders?

 

 

Bzgl. eines Checks wegen der Geschwindigkeit steht zumindest nichts im Datenblatt des Moduls. Ich könnte dir aber eine Firmware machen in dem ich die "Transmit Rate" auf einen festen Wert setze.

[webster7567]

Das kann ich versuchen, bringt in meinem Fall aber nicht viel weil ich keinen PC in die Seilkamera einbaun kann.... Ich versuch es morgen einmal in einem anderen Wlan bei mir zu Hause wo nicht so viele Geräte herumstrahlen, aber eine fixe RX/TX Rate wäre sicher auch kein Nachteil.

 

Wenn man bedenkt sind es ja gar nicht so viele Werte die übertragen werden müssen, dass muss ja auch mit 1 MBIt normal locker reichen...

 

Karl

[borg]

Es geht nicht darum zu gucken ob das eine Alternative wäre, es geht darum zu gucken ob es sich anders verhält. Wenn es sich genauso verhält wie die WIFI Extension werden wir da an der WIFI Extension keine Konfigurationen finden um die Aussetzer zu beheben.

[AuronX]

Ich muss aber Borg recht geben:

Eine Funkstrecke ist per Definition eine unsichere verbindung, gerade wenn du mit deiner Kamera auf Konzerten utnerwegs bist wird es zu (kurzen) Aussetzern kommen (egal mit welcher Funktechnologie).

 

Die Konsequenz ist, dass dein Aufbau damit klarkommen sollte. Warum kannst du keinen PC an der Seilkamera befestigen? Nen Rasp-Pi ist ja gerade mal Scheckkarten groß...

 

Nur meine paar Cent...

[remotecontrol]

Das hier

Wenn ich den ganzen Stapel per USB hab funktioniert alles wunderbar, aber die Wifi Extension macht noch nicht so mit...

hört sich doch nach ähnlichen Problemen an, wie bei mir (http://www.tinkerunity.org/forum/index.php/topic,1339.msg9767.html#new).

 

Aussetzer habe ich auch, mal kurz mal lang, wobei "lang" auch 1 ganze Sekunde sein kann, bis zu dem Punkt, wo sich die WLAN Extension dann ganz verabschiedet. Das ist noch kein "normales" Verhalten, auch für potentiell unsichere Verbindungen.

[webster7567]

Ja da habt ihr wohl recht.

Ich werde versuchen das Beste daraus zu machen. Schön langsam muss ich wohl einsehen das es nicht funktioniert wenn der Antrieb für die Kamera auf der Kamera montiert ist. Bei den anderen Systemen wird der Schlitten mit einem externen Motor hin und hergezogen.

 

Das mit dem Pi würde schon gehen, aber ich hab die ganze Software schon fertig und auf die Hardware abgestimmt und in knapp 2 Monaten soll sie laufen. Wenn ich da jetzt nochmal bei 0 anfangen muss werde ich wohl entweder nicht fertig oder die Nerven verlieren ;-)

 

Ich hab gerade einen neuen AP angeschlossen und versuch es jetzt nicht mit Ad Hoc sondern mal über einen AP. DAs hat bis jetzt leider noch nicht funktioniert... verbindet sich einfach nicht.

 

Karl

[webster7567]

Kurzer Zwischenstand nach ca. 15 Minuten:

Viel Viel besser! Hab jetzt einen Netgear WNR2200 im Einsatz und da hängen in einem eigenen Test-WLAN nur der Laptop und der Tinkerforge Stack. Ich hab auch einen fixen Kanal festgelegt um Kanal-Hops zu vermeiden. Bis jetzt hatte ich noch keinen einzigen Timeout und der längste Ping der derzeit aufgetreten ist lag bei 73 ms... in der Regel sind sie aber zwischen 2 - 6 ms.. minimale Ausreißer bei 11-12 ms.

 

Ich denke so kann man das lassen. Jetzt die Software und den Router noch optimieren. Da geht noch was!

 

Karl

 

Edit: Jetzt hab ich noch getestet das ich mich per Kabel (Gigabit) auf den Router hänge und nur der Stack per WLAN hängt. Funzt noch besser!

[AuronX]

@remote: Das mit dem Totalausfall ist natürlich nicht normal. Eine Sekunde je nach Störeinflüssen aus der Umgebung schon. Wenn ich hier im Plattenbau mit zig Nachbarn ein 2,4 GHz WLAN betreibe brauche ich keine Computerspiele übers Netz spielen, weil meine Verbindung zu oft zu lange aussetzt, einfach weil alle Kanäle mindestens 3-fach belegt sind.

 

@webster: Vor einem Live-Einsatz würde ich jeweils schauen auf welchen Kanälen die meisten Störungen sind und jeweils mit meinem eigenen Kanal "ausweichen". Wenn dir das dann so reicht ist ja alles cool. Ansonsten wäre noch meine Frage: Wie hast du es (software-technisch) momentan umgesetzt, dass ein Umstieg auf nen Rasp-Pi dich auf 0 zurückwerfen würde?

[webster7567]

Also kurze Softwarebeschreibung:

 

Die Software steuert die Bewegung des Schlittens (Vor/ Zurück von 0 - 100%) und die Steuerung des Remoteheads (Pan Tilt Zoom). Die Steuerelektronik sind alles RC ESCs... wurde eben so ausgelegt aufgrund des tollen TF Servo Modules...

 

Was die Software jetzt zusätzlich macht ist eine Kontrolle der Schlittenbewegung (Hintergrund: Ich hab die Kamera letztes Jahr normal mit einer RC Fernbedienung betrieben und an das Seilende geknallt). Das heißt es sind vorne und hinten an der Kamera Ultraschall-Sensoren montiert die ein Hinterniss erkennen und sofort eine "Notbremsung" mit einem definierten Verzögerungsmoment einleiten (es darf nicht sofort auf "0" gebremst werden da sonst die Haftreibung in Gleitreibung übergeht und dann rutscht das Ding auf dem Seil weiiiiiit... *peng*).

Weiters wird die aktuelle Stellung des SErvos (= Geschwindigkeit) inkrementiert und somit die Position am Seil (0-100%) ermittelt. Damit hab ich einige Automatik-Funktionen (Hin und Herpendeln zwischen 20 und 80% Seilposition, One-Shot-Start = Einmal von Startposition losstarten bis 75% -> Bremsen -> 5 Sekunden warten -> Mit Rangiergeschwindigkeit auf Startposition zurückfahren etc) realisieren können.

 

Und das ist alles fix fertig... Nur mehr den Stapel in die Kamera schrauben, Servokabel anschließen und ab gehts. Beim Rasp-PI müsste ich da eben wirklich wieder von Null Anfangen, und da steckt doch schon ein bisschen Zeit und Hirnschmalz drinnen!

 

Wenn ich dann fertig bin möchte ich das Projekt (wie in einem anderen Thread schon angesprochen) vorstellen. Auch wenns keinen breiten Nutzen hat sind vielleicht die ein oder anderen Features drinnen die wer brauchen kann.

 

Karl

[AuronX]

Ich muss anders fragen: Warum bringt der Pi dich auf 0?

 

Musst du durch sein Gewicht alles neu berechnen?

Oder kannst du dein Programm nicht auf dem Pi ausführen?

 

Weil der Pi ist ja nur ein kleiner Computer. Bei den meisten Programmiersprachen würde ich erwarten, dass du die Programme auch auf dem Pi nutzen kannst. Aber vermutlich übersehe ich den wesentlichen Punkt der dich auf null zurückwirft.

[Nic]

Ich tippe mal, dass er die SW auf einer Windows-Umgebung implm. hat und u.U. in einer Sprache, die nicht so ohne weiteres auf Linux portierbar ist.

 

Für so ein Echtzeitsystem, einen Kameraschlitten, der mit 50km/h auf einem Seil ev. über die Köpfe von Zuschauern rauscht, würde mir ein Windows-OS da schon schlaflose Nächte bereiten. Sorry, aber da würde ich ein paar Sicherheitsfaktoren mehr einplanen. OnDevice-Programm., Ardunio oder eben den Pi als Umgebung anvisieren.  Die TF-Sachen befinden sich (noch) in den Kinderschuhen. Für solch ambitionierten Projekte ev. zu früh.

[AuronX]

...würde mir ein Windows-OS da schon schlaflose Nächte bereiten...

 

Ohne das zu einer zu weiten Diskussion führen lassen zu wollen: Aber auch ein normales Linux ist dafür nicht besser geeignet.

 

Gebe dir aber recht, direkt per USB wäre besser und noch viel besser wäre OnDevice, zumindest was die garantierte Antwortzeit betrifft.

 

Niemand wird garantieren können, dass es nicht wieder Kamerasalat gibt, solange die Regelung über WiFi läuft und kein "Notschalter" für Verbindungsabbrüche vorhanden ist.

[webster7567]

Ja es wird wohl nicht das gelbe vom Ei sein. Dieses Jahr wurschtl ich mich somit noch drüber und dann überleg ich mir wieder was neues, oder schieb das Projekt dann in die geistige Tonne. Nicht ganz motivierend zur Zeit das Ganze....

[webster7567]

Notschalter gibts über das Monoflop vom Industrial Quad... Spätestens nach 100ms Ausfall ist schluss mit fahren.

 

Ich leg mir mal so ein Arduino zu... kostet ja nicht so viel und eventuell kann ich es noch ummodeln. Nur wie bekomm ich da meine analogen Steuersignale vom Steuerpult zur Kamera hoch.... hm

[AuronX]

Ich würde statt des Ardu ein Rasp-Pi nehmen.

 

Für die Steuersignale ist WLAN gut genug...

 

Nur die Regelung sollte nicht über Funk laufen.

[batti]

Webster, was ist denn das aktuelle Problem. Wenn ich mich nicht verlesen habe, dann waren deine Posts von heut morgen positiv.

Wie kommt es zu der Sinneswandlung? Das las sich ja so als wenn es mit dem Netgear funktioniert.

 

Was ist mit der Raspberry Pi Geschichte? Dafür ein Linux aufzusetzen ist echt nicht schwierig. Kenne auch deine Software nicht, aber ist das nicht portierbar? Im besten Fall kannst du einfach alles übernehmen und tauscht nur die IP Adresse der WIFI Extension durch localhost aus.

 

Grüße,

 

Bastian

 

 

[webster7567]

Naja ich hab das Ding jetzt mal 2 Räume weiter weg gestellt und dann siehts wieder etwas schlechter aus und ich hab die Befürchtung das die Funktion dann im eingebauten Zustand (Richtfunk der Videoübertragung, Hochstrom ESCs etc.) dann das noch weiter einschränkt.

 

Ich blick da nicht so durch noch. Ich brauch auf jeden Fall ein Element das mir die 4 Analogsignale der Joysticks einliest (am Steuerpult) und auf der Kamera ein Ding (Rasbp PI?) das mir die Distanzmessung und Regelung macht. Da muss ich also 2x Analog in und 4x RC Servo Out haben.

 

Ich lass euch mal in Ruhe damit und mach mir selbst darüber Gedanken. Will euch nicht mit solchen Käse nerven...

 

Karl

 

[borg]

Ich blick da nicht so durch noch. Ich brauch auf jeden Fall ein Element das mir die 4 Analogsignale der Joysticks einliest (am Steuerpult) und auf der Kamera ein Ding (Rasbp PI?) das mir die Distanzmessung und Regelung macht. Da muss ich also 2x Analog in und 4x RC Servo Out haben.

 

Ich würde folgenden Hardwareaufbau machen:

 

Aufbau Steuerung: 1x Laptop + Master + 2x Joystick Bricklet über USB

Aufbau Regelung: 1x Raspberry PI + USB WLAN Stick + Step-Down Power Supply + Master + Servo Brick + 2x Analog In

 

Und folgenden Aufbau für die Software:

 

Programm Steuerung: Läuft auf Laptop. Es nimmt die Befehle der Joysticks entgegen und wandelt sie in High Level Anweisungen um (z.B.: Fahre mit 10km/h nach rechts). Diese Anweisung wird über einen Socket über WLAN an Programm Regelung welches auf Aufbau Regelung läuft geschickt.

Programm Regelung: Läuft auf dem Raspberry Pi. Hier übersetzt du die High Level Anweisungen die vom Programm Steuerung kommen. Des weiteren kannst du dich hier jetzt austoben bzgl. der Regelung und Notausmaßnahmen.

 

Wenn du Ein Arduino verwenden willst würde der Aufbau prinzipiell gleich aussehen, du müsstest dann irgendwie das Arduino mit dem RPI verbinden und auf am Laptop ein weiteres Arduino mit dem Laptop.

[Nic]

Aber auch ein normales Linux ist dafür nicht besser geeignet.

Also kein Linux.

Ich würde statt des Ardu ein Rasp-Pi nehmen.

Doch wieder Linux 

Was ist mit der Raspberry Pi Geschichte? Dafür ein Linux aufzusetzen ist echt nicht schwierig.

 

Um ev. Missverständnisse auszuräumen, wo ist der grav. Unterschied zw. Linux normal und Pi-Linux ?

[AuronX]

Alsoooo...

 

Linux auf dem Pi ist genauso gut oder schlecht geeignet wie nen normales Windows.

 

Du hast kein "berechenbares" Scheduling, es könnte immer irgendwas schlimmes passieren, das dazu führt, dass deine Antwortzeit mal höher geht (i.d.R. maximal wenige Millisekunden).

Es ist halt kein Echtzeitbetriebsystem, deswegen gibts auch keine Garantien in dem Sinne wie man es aus der Informatik gewohnt ist.

 

Rein praktisch: Ich vermute mal, dass sowohl Windows als auch Linux auf dem RaspPi "schnell genug" und "zuverlässig genug" sind. Auf jeden Fall um Welten zuverlässiger als ne drahtlose Verbindung. Aber ich würde damit nicht auf dem Mars ein autonomes Auto fahren lassen und auch keinen Passagierflieger.

 

Viele Grüße

Jan

 

edit: Also kurz: Mir ging es nur um die Aussage "Für so ein Echtzeitsystem [...]  würde mir ein Windows-OS da schon schlaflose Nächte bereiten."

[webster7567]

Danke für eure Tipps! Die Kamerabewegung ist ja überhaupt nicht so wichtig. Da ist die Trägheit der Moteren schon so groß das man einen kurzen Aussetzer wohl gar nicht merkt. Es geht mir um 2 Punkte:

 

1.) Sicherheit: Die Kamera soll und darf nicht ans Ende krachen etc.

2.) Komfort: Damit ich nicht dauernd den Joystick bedienen muss fürs hin und herfahren wünsch ich mir das der Schlitten automatisch "Soft" anfährt, bremst, wieder zurückfährt etc. und ich kann mich um die Kamera kümmern.

 

Aber ihr habt recht. In meiner Konfig wirds immer Rucker geben. Ein Raspberry PI wollte ich mir immer schon mal zulegen und darauf herumprobieren, jetzt ist dann wohl der Zeitpunkt gekommen. Auch wenns noch nicht fürs "Echtsystem" reichen wird...

 

Karl

[Nic]

Linux auf dem Pi ist genauso gut oder schlecht geeignet wie nen normales Windows.

Sorry, aber nach einer Philosphie-Std. über Echtzeitsysteme hatte ich nicht gefragt Es da schon etwas irritierend, im ersten Moment von Linux abzuraten, und wenig später dann doch wieder Linux und den PI ins Spiel zu bringen. In seinem Konzept gibt es m.E. mehrere Schwachpunkte und einer davon dürfte auch das OS sein, wenn es hier um zeitsensible Sachen geht.

 

Ich würde hier Linux und auch Win Echtzeitfähigkeiten nicht pauschal absprechen. Das gibt es zum einen Linux-RT oder für Hochsprachen spez. Realtime-Frameworks, die durchaus einer zuverlässigen Echtzeit nahe kommen. Wenn man also solche zeitkritischen Sachen schafft, wäre ein spezielleres OS oder API ev. eine sinnvolle Ergänzung.

 

Was hier überhaupt nicht berücksichtigt wurde, dass er schon viel Arbeit in die SW unter Win gesteckt hat. Wenn es zur Entkoppelung und zuverlässigerem Regeln geht, würde alternativ z.B. ein Nano/Pico-ITX mit x86-Kern ihm Zeit einsparen. D.h. eine ZBOX AD10 von Zotac (http://www.heise.de/preisvergleich/zotac-zbox-nano-ad10-zboxnano-ad10-e-a677171.html), incl. WIFI, auf den Schlitten montiert ein Leichtgewicht, kostet zwar ein paar Euros aber spart ne Menge Zeit ohne vollständige Neu-Programmierung. Sorry aber die ständigen Empfehlungen für den PI sind mir langsam zu penetrant.