ub_marco

Hallo Markus, ich habe selbst in JAVA eine Ansteuerung eines Steppes implementiert. Insofern du keine Schritte durch zu hohe Lasten verlierst, kennt der Stepper Brick die Position genau und sollte sich zeitlich deterministisch verhalten. Jetzt brauchst du ein physikalisch-mathematisches Modell für die 3 Phasen "Beschleunigung bis zur Ziel-Geschwindigkeit", "Verfahren mit konstanter Geschwindigkeit" und Abbremsen mit der negativen Beschleunigung auf 0. Zu berücksichtigen ist noch der Fall, dass der Stepper die Max-Geschwindigkeit nicht erreicht. Aus diesem Modell kannst du die Dauer berechnen. Die Geschwindigkeitsangaben sind in Schritten pro Sekunde und die Beschleunigungsangaben in Schritten/Sekunde². Die Schrittweite sollte in der Spezifikation deines Motors stehen. Für den Nema 17 von TF sind es z.B. 1.8° pro Schritt. Wenn du Hilfe bei der Formelbildung brauchst, sag Bescheid. Grüße Marco

Hallo zusammen, weiß jemand, ob man beim RED Brick die blaue LED deaktivieren kann? Beim Stepper geht das z.B. sehr schön per API. Beim RED Brick habe ich nichts in der Art gesehen. Ich nutze den Stack in einer dunklen Umgebung und die helle LED stört. Danke Marco

Hallo Bastian, vielen Dank für die schnelle Reaktion und das Update der Firmware. Klappt wunderbar, der Brick funktioniert nun perfekt. Grüße Marco

Hallo Bastian, nach 10 Minuten "Enable Stepper Motor" und Driving Forward/Backward wird der Stepper Brick nicht warm. Der Passivkühlkörper hat Raumtemperatur. Wenn ich die Spannung von der Step-Down-Power-Supply abziehe und nur noch der RED Brick am USB hängt, habe ich eine Stack Voltage von 0.6V und die External Voltage am Stepper Brick zeigt meist 0,1V mehr an. Schließe ich eine 9V Batterie an die externe Eingang des Steppers an, dreht der Schrittmotor einwandfrei. Ich sehe 2 Möglichkeiten: - Brücken der externen Spannungsversorung des Stepper Brick, so dass keine Potentialdifferenz entstehen kann - Aktualisierung der Firmware auf #define STEPPER_VOLTAGE_EPSILON 2000 Was meint ihr? Gruß marco

Hallo nochmal, ich habe mir die Firmware angeschaut. In stepper.h finde ich: #define STEPPER_VOLTAGE_EPSILON 1000 Der Code in stepper.c (ab Zeile 264) sagt, dass bei einer externen Spannung über 1V die externe Spannungsquelle am Stepper verwendet wird. Wenn diese nun aber kleiner als die stepper_minimum_voltage ist, welche bei mir auf dem Defaultwert von 8V steht, dann geht die rote LED an (ab Zeile 135). In meinem Screenshot sehe ich da 1V als externe Spannung; sie hatte gependelt zwischen 0,9V und 1,2V. Ich hatte allerdings keine externe Spannungsversorgung am Stepper Brick dran. Woher kommt also das eine externe Volt? Ist das ein EMV Problem? Am Vortag, als es noch funktionierte, hatte ich zwischen dem RED Brick und dem Stepper Brick noch einen Servo Brick. Danke & Grüße marco

Hallo, ich habe eine Frage zum Stepper Brick. Mein Stack besteht aus Step-Down-Power-Supply, RED-Brick und Stepper Brick. An der Step-Down-Power-Supply hängt ein 12V Netzteil. Wenn ich im Brick Viewer den Stepper Brick aktiviere, leuchtet die rote LED auf dem Stepper Brick und der Motor (euer Nema17) zuckt nur ganz leicht. Das schaut mir so aus als ob der Brick nicht auf die Stack-Versorgung schaltet. Im Anhang ein Screenshot. Gestern hat es noch funktioniert... Danke marco

Hallo borg, danke für die schnelle Antwort & die Nachtschicht Dein Beitrag hat mich der Lösung näher gebracht. Ich werde bei Gelegenheit testen, die erste Sollposition mit maximaler Geschwindigkeit/Beschleunigung zu fahren. Ich habe bemerkt, dass es eigentlich 2 getrennte Probleme sind: [*]Der Servo fährt zu Beginn mit maximaler Geschwindigkeit [*]Der Servo fährt zu Beginn erst auf 0 und dann meine Sollposition an Zu 1: Mir ist klar, dass ein Servo (wenn er nicht modifiziert ist) keine Positionsrückmeldung liefert. Nachdem die Geschwindigkeits- bzw. Beschleunigungswerte der API die Änderungsgeschwindigkeit der Pulsweite beeinflussen, muss für eine korrekte Funktion davon ausgegangen werden, dass erstens der Servo der Bewegung folgen kann und zweitens dass die in der Firmware gespeicherte Position stimmt. Ansonsten wird natürlich der Servo zu Beginn gleich mit Vollgas in die Position fahren, die der Start-Pulsweite der TF API Bewegung entspricht. Die einzige Option wäre, der API mitzuteilen, wo sich der Servo initial befindet. In meinem Fall weiß ich das, es ist die Position, an der ich beim letzten Shutdown stehen geblieben bin. Der Servo verdreht sich bei mir nicht von selbst. Soweit ich die API durchgesehen habe, ist das nicht möglich. Wäre es nicht hiflreich, dem User die optionale Möglichkeit zu geben, die Initialposition selbst festzulegen? Zu 2: Ich habe etwas die Servo Brick Firmware durchgesehen und dabei ist mir in servo.h die Initialisierung aufgefallen: #define SERVO_POSITION_ORIG 0 #define SERVO_VELOCITY_ORIG 0xFFFF #define SERVO_ACCELERATION_ORIG 0xFFFF Die Variablen werden hier mit möglichst sinnvollen Startwerten initialisiert. Ich würde aber von der API erwarten, dass, wenn ich eine Ziel-Position setze und zugleich Geschwindigkeits-/Beschleunigungswerte kleiner als 0xFFFF wähle, der Servo dann nicht erst auf 0 fährt und dann auf die Zielposition. Die Firmware könnte z.B. ein Initialisierungs-Flag setzen, so dass bei der ersten Bewegung automatisch ohne Transition direkt die Ziel-Pulsweite angefahren wird. Bei allen weiteren Bewegungen ist die Zielposition dann bekannt. Gut, dass alles OpenSource, dann übersetze ich mal meine eigene Firmware Ich habe noch ein weiteres Anliegen: Mein Servo schafft wie gesagt +-2.5 Umdrehungen, was +-900° entspricht. Die Position wird lt. API in °/100 angegeben. Das würde bei mir bedeuten, dass ich -90000 .. 90000 wählen müsste, was nicht in einen Java Short Datentyp passt. Vermutlich wurde die Firmware so designed, dass ein Kompromiss aus Speicherplatz und Auflösung für normale Servos (max. +-180°) entsteht. Als Lösung habe ich Min/Max Winkel als +-900 angegeben und finde mich damit ab, dass die Geschwindigkeit und Beschleunigung zwar die Bewegung beeinflussen, aber keine physikalisch sinnvollen Werte mehr sind. Das ist soweit ok, ich wollte es nur als Hinweis loswerden. Grüße marco

Hallo zusammen, ich habe eine Frage zum Servo Brick. Und zwar hängt ein digitaler Servo mit +-2,5 Umdrehungen am Brick. (Es ist der Modelcraft RS-D22YMB) Zu Beginn ist der Servo Brick komplett stromlos. Nun schließe ich den USB sowie die externe Stromversorgung an den StepDownPowerSupply. Ich öffne den Brick Viewer und wähle den Servo Brick aus. Nun stelle ich meine passende Geschwindigkeit, Beschleunigung und die PWM Werte ein. Dann setze ich einen Ziel-Winkel UNGLEICH 0. Sobald ich auf Enable drücke, fährt der Servo mit voller Geschwindigkeit und Beschleunigung in die 0-Position (vermutlich 1.5ms Pulslänge) und danach mit der von mir ausgewählten Geschw. / Beschl. an den eingestellten Ziel-Winkel. Das stört meine Applikation leider empfindlich, da der Servo nach dem Aufwachen das erste Signal gleich übernehmen muss und nicht erst mit hoher Geschwindigkeit in die Startposition fahren soll. Interessant ist, dass das Verhalten nicht auftritt, wenn ich den USB danach abstecke und wieder anstecke. Wenn ich dann die Werte wieder einstelle und auf Enable drücke, dann tut der Servo sofort, was ich möchte. Der Stack wird nach dem Abstecken des USB natürlich noch über die StepDownPowerSupply versorgt. Meine Applikation sieht vor, dass der Stack zu Beginn stromlos ist. Hat das etwas mit meinem Digital-Servo zu tun oder steckt da ein Feature / definiertes Verhalten in der API drin? Entweder der Servo Brick macht eine Art Initialisierung auf 0 Grad oder der Digital-Servo zeigt das Verhalten. Ein Oszi habe ich grad leider nicht da... Danke für eine Rückmeldung dazu! Grüße marco

Hallo TF-Gemeinde, ich habe ein paar Fragen zum Thema "Anwendung im Automobil-Bereich". Mein Anwendungsgebiet: Für Automobil-Anwendung werden desöfteren Prototypen entwickelt zur Demonstration neuer Funktionen bzw. neuer Lösungsansätze für bekannte Probleme. Dabei werden häufig Sensoren und Aktuatoren (DC Motoren, Servos) an ein Steuergerät angebunden und vernetzt. Die HW wird meist als Evalboard von einem Zulieferer bereitgestellt. Die Kosten und Inbetriebnahmezeit sind häufig enorm. Nun frage ich mich, ob sich ein Prototyp auch mit Tinkerforge Komponenten darstellen lassen könnte. Interessant finde ich die kurzen Inbetriebnahmezeiten, die geringen Kosten sowie die gute Auswahl an schon vorhandenen Komponenten. Für die Realisierung müsste jeder der folgenden Punkte geklärt werden: Echtzeitfähigkeit RED Brick Der RED Brick würde für eine Standalone Lösung benötigt. Die Antwortzeiten im sicherheitskritischem Umfeld müssen bekannt sein. Gibt es die Möglichkeit, den Kernel des aktuellen Debian Derivats um eine RT-Komponente für den Allwinner A10s zu erweitern? Ich dachte da z.B. an RTAI. Interessant wären auch Konfigurationsmöglichkeiten des Schedulings hinsichtlich preemptiv bzw. kooperativ mit Möglichkeiten für Interrupt-Locks und Scheduling Points. Im Automobil-Bereich wird häufig OSEK-OS verwendet, welches von der OSEK als Echtzeit-OS entworfen wurde. Wie verhält sich die Kommunikation zu anderen Bricks / Bricklets. Sind die maximalen Latenzzeiten zu anderen Bricks / Bricklets bekannt bzw. vorhersagbar? C-API Die Umsetzung würde wohl in C erfolgen. Hier sehe ich selbst keine Probleme. Ihr? Anbindung von Systembussen Hier wird häufig LIN, CAN und Flexray eingesetzt. Plant ihr, solche Bussysteme zu unterstützen bzw. Protokoll-Stacks bereitzustellen? Ich vermute, hier würde ein neuer Brick benötigt. Temperatur-Beständigkeit Meist haben wir es mit widrigen Umgebungsbedingungen zu tun. Die Temperaturen liegen zwischen -40°C und 125°C. Schaffen das die meisten Bricks / Bricklets? Gegen Ölspuren in der Luft könnten passende Gehäuse nach IPxx helfen. Generell geht es mir eher darum, eine generelle Einschätzung von den TF Entwicklern zu bekommen, ob mein Anliegen realisiert werden kann oder ob ihr Show-Stopper seht. Danke & Grüße Marco

Hallo photron, danke für die Rückmeldung. Der Servo Brick funktioniert ohne Probleme. Und zwar alleine am Mini-USB wie auch mit der Step Down Power Supply zusammen. Wenn ich den RED Brick alleine am Mini-USB anschließen, dann bootet dieser normal. Die Probleme gibt es nur sporadisch, wenn ich einen Stack baue. Ich habe soeben den Stack zerlegt und neu aufgebaut, zunächst ohne Verschraubung. Und siehe da, es funktioniert, der gesamte Stack bootet. Danach habe ich den Stack verschraubt und bemerkt, dass die Abstandshalter nicht die ideale Länge haben. Ich habe ein Bild angehängt. Zwischen Power Supply und RED Brick war der Abstand zu groß, also habe ich eine Unterlegscheibe verwendet. Dann verbleibt bei fester Verschraubung ein kleiner Spalt, ich hoffe man sieht es. Lasse ich die Scheibe weg, dann kann vermutlich bei der Verschraubung die mechanische Spannung im Bauteil zu hoch werden. Zwischen RED Brick und Servo ist nur eine kleine Distanz und ich lasse die Scheibe weg. Die Schrauben sind aber auch nicht komplett fest angezogen, aus dem oben genannten Grund. Wenn es etwas damit zu tun haben könnte: Wie wäre eure Aufbauempfehlung? Der verschraubte Stack funktioniert nun, ich werde es weiter testen und hoffen, dass ich keine Probleme mehr habe. Grüße Marco

Hallo zusammen, ich habe ein Problem mit dem Red Brick in einem Stack. Aufbau: Oben: Servo Brick Mitte: RED Brick Unten: Step Down Power Supply Das Problem ist, dass der RED Brick häufig nicht bootet. Die Step Down Power Supply ist aktuell unbestromt. Die LED-Sequenz sieht im Fehlerfall so aus: 1. Blaue, rote und grüne LED leuchten beim Einstecken des Mini USB in den RED Brick. 2. Nach etwa 6s geht die grüne LED langsam aus (dauert 3s) während die blaue und rote LED weiter leuchten. Im Brick Viewer wird der Stack nicht erkannt. Ich verwende das Fast-Image auf einer TF SD Karte. Die einzige Info, die ich dazu gefunden habe ist: Wenn die rote LED nicht ausgeht, wird das Image nicht erkannt. Ich habe den Eindruck, dass es am Stack liegt. Wenn ich den RED Brick ohne Stack anschließe, dann bootet dieser normal und wird vom Brick Viewer erkannt. Ich hatte auch schon den Fall, dass die blaue und rote LEDs zu Beginn leuchten, danach geht die rote aus, aber die grüne leuchtet gar nicht. Der Brick Viewer erkennt den RED Brick nicht. Den gesamten Stack hatte ich auch schon normal im Betrieb und im Brick Viewer wurden beide Bricks und die angeschlossenen Bricklets erkannt. Der Fehler tritt also nicht immer auf. Alle Pins und Bauteile sehen optisch unversehrt aus. Hat jemand eine Idee? Grüße Marco