mchott

Es hat fast funktioniert (sorry für das lange warten) nur musste ich 777 setzen, damit er schreiben durfte, also: chmod 0777 /home/tf/programs/<program-id>/bin Damit ging es dann.

Jap..das Binding funktioniert tadellos samt der Verwendung eines Schlüssels. Kompliment für die schnelle Reaktion.

Also bei mir steht folgendes: this.BrickletTilt = require('./BrickletTilt'); this.BrickletVoltage = require('./BrickletVoltage'); this.BrickletVoltageCurrent = require('./BrickletVoltageCurrent'); } global[b][color=red].window[/color][/b].Tinkerforge = new Tinkerforge();}).call(this,typeof self !== "undefined" ? self : typeof window !== "undefined" ? window : {}) },{"./BrickDC":1,"./BrickIMU":2,"./BrickMaster":3,"./BrickRED":4,"./BrickServo":5,"./BrickStepper":6,"./BrickletAmbientLight":7,"./BrickletAnalogIn":8,"./BrickletAnalogOut":9,"./BrickletBarometer":10,"./ Was ich aber mittlerweile feststelle ist, dass nicht alles geht, wenn man das Binding verwendet. Für das Handling mit dem Secret wird ebenfalls das window verwendet und damit gehen nur Verbindungen ohne vergebenes Secret.

Das Binding hat in der Zeile 12810 ein ".window" zu viel und ohne dem lässt sich das Binding dann auch im WebWorker verwenden. Ich brauche die WebWorker - und dafür sind sie grundsätzlich gedacht - um Aufgaben parallel sowie von der Bedienung entkoppelt ablaufen zu lassen. Wenn eine Aktion in Summe 1s dauert und dabei >6 Servos möglichst simultan angesteuert werden sollen. Dann aber die Bewegung berechnet werden muss, weil in der nächsten 1s die sich ändert, dann schaffe ich das nicht im SingleThread Ablauf. So übergebe ich jedem WebWorker eine Steuerungsaufgabe je Servo und teile dem WebWorker´n nur noch die neue Aufgabe mit. Derzeit macht es bei mir den Eindruck, dass es genau mein Leistungsproblem löst. Früher habe ich z.B. aufwendigere Operationen ausgelagert, wie beispielsweise Daten abrufen und "aufhübschen" oder Grafiken berechnen und dergleichen. Ein simples Auslesen von Zuständen und diese dann anzeigen, wäre meiner Meinung nach auch so zu lösen, wobei ein permanentes (fast Echtzeit) Anzeigen ist vielleicht schon ganz sinnig, wenn man das im Browser machen möchte und gleichzeitig die GUI aber stabil stehen soll.

Gute Frage..es ist in meinen Quellen immer von JavaScript die Rede, aber immer mit dem Fokus auf clientseitig. Aber ich denke, dass node.js das auch implementiert hat. Leider beherrsche ich kein node.js (bin da ausgestiegen, weil mir einiges zu kompliziert erschien und ich nur Kleinkram brauche). Hier wird beschrieben, dass es das wohl geht: http://webkrauts.de/artikel/2011/serverseitiges-javascript-mit-nodejs Ausprobieren und vielleicht hier kurz eine Rückmeldung über den Erfolg. Die WebWorker sind ja recht leicht implementiert und getestet. Ich muss derzeit nur meine Anwendung umbauen, weil die WebWorker ja doch im Ablauf einiges verändern.

Erster kleiner Test..ohne Deceleration geht es kaum. Der Grund die sind "langen" Arme im Verhältnis zu den Servoarmen, obgleich diese durch Kugellage extern geführt werden. Aber das harte Ende der Bewegung lässt den Arm etwas wackeln und das geht für meinen Anwendungsfall nicht. Dank der WebWorker könnte ich eventuell einen Deceleration parallelisieren, aber natürlich wäre mir eine Implementierung direkter lieber. Gesetzt den Fall, dass sehen noch mehr so: Wie lange würde eine solche Implementierung in der Firmware dauern?

Danke..das hatte ich am Sonntag Abend noch herausgefunden und bisher noch keine Zeit es hier zu posten. Damit funktioniert es wunderbar, lediglich das Handling der WebWorker braucht etwas mehr Aufmerksamkeit, weil diese neue Parallelisierung auch noch "gelernt" werden möchte. Wird das Binding in Zukunft entsprechend angepasst?

Im brickv kann man, wenn man ein neues Programm anlegt und dort wegen der Verwendung "WebInterface" auswählt keinen weiteren Parameter einstellen. Andernfalls steht "." als Verzeichnis in den Parametern. Das Skript lässt sich dann unter "http://IP-Addredd/programs/Programmname/bin/index.php" aufrufen.

Da hab ich noch etwas dazu gelesen: http://html5rocks.appspot.com/de/tutorials/workers/basics/ Aus dieser Quelle: Für Worker verfügbare Funktionen Aufgrund ihres Multithread-Verhaltens können Web Worker nur auf einen Teil der Funktionen von JavaScript zugreifen: Das navigator-Objekt Das location-Objekt (schreibgeschützt) XMLHttpRequest setTimeout()/clearTimeout() und setInterval()/clearInterval() Den Anwendungscache Import externer Skripts mithilfe der importScripts()-Methode Erzeugen weiterer Web Worker Worker haben KEINEN Zugriff auf: Das DOM (nicht threadsicher) Das window-Objekt Das document-Objekt Das parent-Objekt

Soweit mein Verständnis derzeit reicht, sieht es so aus - bin da aber kein Experte - dass man ein separates Binding erstellen muss, was dann für WebWorker läuft. Grund der Annahme: Man kann wohl keine komplexen Objekte übergeben. Man kann nur Skripte verwenden, die keinen dom Bezug haben. Auswirkung: Würde man die Standard-Bindings verwenden, dann würde deren Verwendung ausserhalb vom Worker nicht mehr so komfortabel sein..wie ich es bis jetzt verstanden habe werden deswegen diese "global.window.Tinkerforge" Aufrufe verwendet.

Nicht das wir hier aneinander vorbeireden. Beim RED-Brick lädt man - in meinem Fall PHP - die PHP Dokumente hoch und hat dann sehr sehr wenige Parameter. Die Anwendung "richtet" hier gar nichts ein, sondern wird ausgeführt (entweder per BrowserCall oder per AutoRun). Es wäre der Hammer, wenn jetzt diese PHP-Anwendung einfach Berechtigungen manipulieren könnte, besonders von "Keine" auf "Alle". Das geht meines Wissens nach nicht und das sollte auch gut so sein. Die RED Brick .. so scheint mir .. ist so berechtigt, dass nur der brickv schreiben darf und eben wenn man per Shell drauf gehen würde. Meine Frage zielt also ganz konkret darauf ab, dass ich vom brickv aus für dieses Verzeichnis (nicht für mehr) die Berechtigungen öffnen kann. Mit einem Raspberry läuft es, aber den muss man halt selber verwalten. Allerdings fände ich es wesentlich charmanter mit dem REDbrick, allein wegen der baulichen Vorzüge.

Aber ohne den Kompass weiß man ja nicht, zu welcher Wand man gerade den Abstand misst?! Es bleibt ein spannendes Thema. Eventuell ist es auch mit einem Boden voller NFC-Aufkleber zu lösen, dann hätte man einige Referenzpunkte, die man überfährt und damit kann man seine Abweichungen häufiger korrigieren, ohne dabei ständig wieder zurück zur Homebase zu müssen. Oder man nutzt einen drehbar gelagerten Distanzmesser, der quasi wie ein klassisches Radar die Lage bestimmt, was aber dann schon ambitioniert sein dürfte.

Nur mal so..das IMU liefert doch einen Kompass..und mit Abstandssensoren könnte man doch die Entfernung zu den Wänden messen. Dann hätte man auch wieder einen Abgleich und wäre eventuell genauer?!

Das habe ich jetzt noch nicht ganz verstanden..:-) Es wäre (in meinem Fall ja so): INIT: var i = 0; var Worker = new Array(); while(i<7) { var Worker[i] = new Worker('SimpleServoWorker'); Worker[i].addEventListener('message', function (e) { ..was getan werden soll, wenn der Worker etwas ausgibt.. }, false); } POSITIONIERUNG (kann ständig aufgerufen werden und teilt dem Worker nur schnell mit, was er machen soll) Worker[i].postMessage({'Position':'0','ServoId':'5','TimeToRun':'5' ..und was der Worker sonst noch wissen muss..}); (TimeToRun .. wie lange er sich zeitlassen soll um die Position zu erreichen) DER SimpleServoWorker self.addEventListener('message', function(e) { importScripts('Tinkerforge.js'); var Act = ..per Tf eine Verbindung zu diesem Servo aufbauen..; var Request = e.data; var CurPos = ..per Tf ermitteln..; var PosDiff = CurPos - Request.Position; var Velocity = PosDiff / Request.TimeToRun; Act.setVelocity(0, Velocity); Act.setPosition(0, Request.Position); self.postMessage({'Infos an den Auslöser':'geben, die für den Callback gebraucht werden'}); }); So in der Art. Das hat den Vorteil, dass man im "Vordergrund" nur die neue Position mitteilt und im Hintergrund eine stehende Verbindung zum Brick besteht. Zudem könnte man damit dann "aufwendigere" Berechnungen durchführen, wie die von mir schon gepostete "Deceleration", die über das Frontend einfach zu langsam läuft. Ideal auch, weil die Ansteuerung vieler Servos nur noch durch die Zeit für die Mitteilung der neuen Position verzögert wird und nicht mehr durch die Ausrechnung und Ansteuerung je Servo nacheinander. Ich habe das exemplarisch schon aufgebaut und wollte die Bindings auch händisch anpassen, aber dafür kenne ich den Aufbau des Bindings dann doch zu wenig und bin selbst zu wenig Entwickler, um das performant umzusetzen.

Ich bin dabei eine auf JS basierende Anwendung zu erstellen und bin dabei auf ein Problem gestoßen. JS ist derzeit wegen der "Leichtigkeit" in der Verwendung, nicht weil es möglicherweise die für das Problem beste Sprache ist. Es gibt seit HTML5 das Prinzip der Worker, die eine Art Nebenläufigkeit ermöglichen. Nun dachte ich, es wäre vielleicht die ideale Lösung, um >6 Servo´s "gleichzeitig" (fast) anzusteuern, weil es mit rein serial geschriebenem Code etwas versetzt abläuft. Je schneller die Servos arbeiten, desto mehr kommt man in das Problem, dass das erste Servo schon an der neuen Position ist, aber das letzte noch nicht gestartet ist. Über verschiedene Wege kann mann das immer enger zusammenbringen. Ein noch besserer Weg wären möglicherweise die neuen Worker, aber das JS-Binding kann da nicht eingesetzt werden, weil die Worker kein document/window/..-Bezug erlauben, welcher aber im Binding enthalten ist. Vielleicht kann man darauf verzichten, wo das Binding, ja keinen Bezug zum Dom aufbaut. Eventuell baut man auch ein separates Binding mit reduziertem Umfang speziell für Worker?! Ist nur eine Anregung, weil performante HTML5 wie Pilze aus dem Boden schießen.

Das geht in Summe extrem gut und super einfach per JavaScript. Der große Vorteile: Du brauchst solange eigentlich kein Backend, wie Du nur die Daten von den Stacks verarbeitest. Erst wenn Du auch Einstellungen speichern möchtest oder es leistungsfähiger sein muss, brauchst Du ein einfaches Backend. (starte ersteinmal ohne) Der Ablauf ist eigentlich simpel und die Beispiele von Tinkerforge sind da fast alles was man braucht (neben Grundsätzlichem). Wie läuft es ab? In etwa so: 1) Du hast ein HTML Gerüst (meist mit CSS schön gemacht). 2) Du bindest ein geeignetes Framework ein, um es etwas leichter zu haben. (die Tf Skripte nutzen für DOM-Operationen direkt JS, was auch performanter ist) Typische Frameworks sind jQuery oder Angular. ..<head><script src="jquery.js"></script>.. 3) Du nimmst das JS Beispiel von Tf und liest die Werte aus und schreibst diese in das DOM. ..<div id="SensorWert"></div>..<script>..$('#SensorWert').html(DerErmittelteWert);..</script>.. 4) Wenn dann etwas getan werden soll entweder über einen Button ..<input id="Schalter" type="button" />..<script>$('#Schalter').on('click',function() { ..Hier das Schlaten wie im Tf Beispiel.. });..</script> oder direkt per Code, wenn ein Schwellwert erreicht wurde. Das wäre dann die Aktion in einem Callback, wie Du sie in den Tf Beispielen findest. Zu kurz um es verstanden zu haben, aber vielleicht ein wenig brauchbares dabei?!

Das Skript wird über den brickv hochgeladen und dort kann man doch gar keine User einstellen? Und wie würde ich über den brickv die Berechtigungen für das Verzeichnis ändern? Ich könnte das über die Shell, aber mir geht es ganz bewusst um einen konfigurativen Weg, weil das die Endanwender ja später selber machen müssen und die sind eben keine Informatiker.

Bei meinem aktuellen Projektchen würde ich gern die Daten meiner JS-Anwendung speichern. Dafür nutze ich eine einfache WebService Schnittstelle, wo ich JSON austausche. Diese würde ich gern auf dem RED zum Laufen bringen, aber wenn ich dort von PHP aus die JSON-Daten in eine Datei ablegen möchte, meckert er, dass er keine Berechtigungen hat. Ist das so und wenn ja wie/wo kann man das ändern? Ziel..neben den JSON-Daten würde ich gern auch bei Zeiten einen Updatemechanismus implementieren, der dann die PHP-Dateien überschreibt. Auch das geht derzeit nicht.

Das wäre super..letztlich geht es um Robotic, wo es das Servo zu stark belasten würde, wenn es abrupt stehen bleiben würde. Gehen würde es wahrscheinlich, aber ein sanfter Anlauf und Anhalt wären auf Dauer für den Roboterarm besser.

Hallo..bei meiner Steuerung wäre es von Vorteil, wenn man neben der Acceleration auch die Deceleration beim Servo einstellen kann. Dies muss ich sonst über eine Variable Velocity hinbekommen, was dann aber sehr viel Aufwand ist hinsichtlich Steuerungsaufgaben, zumal es bei sechs Servos möglichst gleichzeitig stattfinden soll. Wäre sowas denkbar oder gibt es einen guten Grund für das Fehlen des Parameters?

Hallo, ich habe den Fehler 13 CONNECT_FAILED erhalten und möchte kurz nachfragen, ob meine Voraussetzungen überhaupt gehen können. Das JS/HTML habe ich auf einem WebServer, der normal mittels HTTPS kommuniziert. Dann geht erwartungsgemäß nichts. Dann habe ich an meinem lokalen Rechner den BrickD und BrickV installiert und ein MasterBrick angeschlossen. Im BrichV ist alles in Ordnung. Nur wenn ich das Enumeration Beispiel im Browser (mit HTTP) aufrufe, dann kommt die Verbindung nicht zustande. Muss der BrickD auf dem WebServer laufen oder kann er lokal angeschlossen sein. Port und Host sind korrekt eingetragen.

Das werde ich mal testen, aber mir kam noch eine andere Idee die funktioniert. Das Programm lege ich einfach auf meinem NAS ab und verbinde den Stapel per IP-Adresse. Das klappt super und ich kann dort direkt dran arbeiten. Alles was ich beim Portieren ändern muss ist der Host und selbst das habe ich dann per Abfrage dynamisch gestaltet.

Was bedeutet, dass ich auf meinem Rechner in diesem Fall eine Laufzeitumgebung für PHP benötigen würde? JS wäre dann ja eine Lösung, da man dafür keine spezielle Umgebung braucht. Wobei es auf dem RED dann als NODE.js laufen müsste. Danke fürs erste...muss noch ein wenig spielen.

Ich stelle mich gerade etwas zu dumm an. Mein RED-Brick ist da und ich würde mich gern ein wenig rantasten. Aber wie komme ich dahin, dass ich schnell neues ausprobieren kann? Also IDE (in meinem Fall Sublimetext) öffnen. Datei (in meinem Fall php oder js) öffnen und etwas ändern. Speichern und fertig. Derzeit lade ich die Datei immer wieder hoch, aber so kann das ja nicht gedacht gewesen sein?!

Hallo, bei http://www.mikrocontroller.net/topic/353625#3941776 hatte ich die Frage schon formuliert. Ich möchte zwei PWM-Signale über eine Leitung schicken. Ein Vorschlag dort im Forum war die Erzeugung und Trennung eines (ich nenne es mal) "PWM-Summensignal". Dazu würde das PWM-Signal aber ich gleicher Frequenz auch seine Spannung ändern müssen. Das ServoBrick kann ja die Spannung je Kanal ändern, aber auch so "schnell"? Wäre es also denkbar zwei PWM-Signale zu "überlagern"?