STorM32 BGC: 3-Achsen STM32 Brushless Gimbal Controller

[r0sewhite]

Das kommt ganz darauf an, was man für einen Nutzen aus den Encodern zieht. Encoder verhelfen zu einer bekannten Motorposition, was eine effizientere und kraftvollere Ansteuerung der Motoren erlaubt. Das untenstehende Video wurde z.B. mit einem Dragon gedreht, auf dem ein Prototyp unserer Regelung mit Encodern arbeitet. Der Dragon hat keine nromalen GB4106 Motoren drauf, sondern auf Pitch und Roll nur winzige GB2208, die selbst mit einer Sony Systemkamera nicht einmal handwarm werden:

[video=vimeo;115545332]http://vimeo.com/115545332[/video]

Eine zweite IMU an der richtigen Stelle und richtig genutzt, wie Olli es macht, bringt schon deutliche Verbesserung, was die Pan-Achse betrifft aber sie löst nicht alle Probleme und kann Encoder nicht ersetzen. Zum einen fehlt dem Controller die Orientierung. Im Gegensatz zur Pitch- und Roll-Achse, die sich an der Horizontalen immer wieder orientieren knnen, fehlt der Pan-Achse solch eine Referenz. Die Sensoren können lediglich Drehungen und Abweichungen erkennen, wissen aber z.B. nicht, wo beim Copter vorne ist. Zum anderen kann die Pan-Achse immer noch driften, sei es durch schlechte Kalibrierung oder zu starke Störeinflüsse wie Vibrationen, solange die IMUs kein Magnetometer mit drauf haben.

Ob Alexmos32 oder STorM32 besser ist, muss jeder für sich selber herausfinden. Beide haben ihre Vor- und Nachteile und was dem einen wichtig ist, ist dem anderen vielleicht weniger wichtig.

Ich persönlich würde bei beiden Boards die Empfindlichkeit des I2C-Busses kritisieren. Da war das alte Alexmos 8bit noch deutlich unempfindlicher. Theoretisch hat I2C da auch gar nichts verloren, weil es gar nicht für lange Verbindungen, die dazu noch an Störquellen wie Motoren vorbeiführen, gedacht ist. Allerdings würde z.B. eine ordentliche CAN-Bus Verbindung Controller und IMU wiederum aufwändiger und teurer machen, was vielen Leuten nicht schmecken würde. Von daher kann man das den Entwicklern nicht zum Vorwurf machen.

Das Autotuning von Alexmos würde ich nur sehr bedingt als Vorteil werten, denn es arbeitet sehr einfach und bringt vielleicht brauchbare aber keine wirklich guten Ergebnisse. Wer ein Alexmos under STorM32 nutzen will, hat einfach PID-Tuning zu lernen. Ich sehe das auch nicht als wirkliches Problem. Wer sich ein Fahrrad kauft, lernt doch auch, sich mit einer Gangschaltung auseinanderzusetzen. Und wer es partout nicht will, dem bleibt noch der Griff zu einem DJI-Gimbal mit seinen beschränkten Funktionen. Oder aber man wartet, bis Phobotic sich noch etwas weiter entwickelt hat. Die Controller spielen schon in einer deutlich höheren Liga und die Software ist vielversprechend aber leider noch nicht ausgereift. Allerdings zahlt man für so einen Controller dann auch 450 Euro.

 

[Allan Sche Sar]

Wow, was für eine geile Zusammenfassung und was für ein noch geileres Video.
Für mich zum Beispiel ist der Storm32 die bessere Wahl, denn ich will im Sportbereich Videos und Fotos machen und dazu brauch ich einfach einen leichten Gimbal, den ich Schätzungsweise bei AM nicht so gut realisieren kann.

Das mit den I2C Fehlern ist mir auch schon aufgefallen und ich überlegen, wie ich das Problem in den Griff bekommen - wo ich doch das IMU Kabel bei der nächsten Gimbal Version durch zwei Motoren führen würde.

P.S.: Hier mal ein Beispielvideo - ich selber war natürlich auch während des filmens auf solchen Sprungstelzen unterwegs.
[video=youtube_share;vbSjhtRCL8s]http://youtu.be/vbSjhtRCL8s[/video]

 

[OlliW]

Eine zweite IMU an der richtigen Stelle und richtig genutzt, wie Olli es macht, bringt schon deutliche Verbesserung, was die Pan-Achse betrifft aber sie löst nicht alle Probleme und kann Encoder nicht ersetzen. Zum einen fehlt dem Controller die Orientierung. Im Gegensatz zur Pitch- und Roll-Achse, die sich an der Horizontalen immer wieder orientieren knnen, fehlt der Pan-Achse solch eine Referenz. Die Sensoren können lediglich Drehungen und Abweichungen erkennen, wissen aber z.B. nicht, wo beim Copter vorne ist. Zum anderen kann die Pan-Achse immer noch driften, sei es durch schlechte Kalibrierung oder zu starke Störeinflüsse wie Vibrationen, solange die IMUs kein Magnetometer mit drauf haben.

diese Ausführungen sind nicht ganz richtig ... in dem Kontext um den es hier geht sind Encoder und 2te IMU praktisch gleichwertig

Orientierung: ein Unterschied ergibt sich zwischen (absoluten) Encodern und 2ter IMU nur beim Einschalten. Mit einen absoluten Encoder weis man natürlich beim Einschalten die Motorposition und daher auch wo vorne ist. Mit ner 2ten IMU ist das nicht so, sondern man muss händisch dafür sorgen dass die Kamera in etwa (es reicht wirklich in etwa!!) nach vorne zeigt. Sobald das Einschalten geschafft ist wissen sowohl Encoder also auch 2te IMU IMMER genau wie alle Motoren stehen, ab da gibt es also keinen Unterschied. D.h. mit absoluten Encodern hat man einen winz Vorteil beim Einschalten, sonst nicht. Das gilt übrigens nur für absolute Encoder. Näme man relative Encoder, wäre auch dieser winz Vorteil futsch. Zudem könnte man diesen winz Vorteil auch andersweitig vergleichsweise einfach hinzugewinnen.

Yaw Drift: Die Pan Achse driftet sowohl mit Encoder als auch mit 2ter IMU exakt gleich, die Encoder bringen hier genau gar keinen Vorteil, njente, nada, Null. Das dem anders wäre ist ein weit verbreiteter Irrglauben, der nicht dadurch richtiger wird das er weit verbreitet ist.

Das kommt ganz darauf an, was man für einen Nutzen aus den Encodern zieht. Encoder verhelfen zu einer bekannten Motorposition, was eine effizientere und kraftvollere Ansteuerung der Motoren erlaubt.

Über die genaue Motorposition hinaus, die wie eben geschildert bis auf den Einschaltvorgang nichts besser machen als eine 2te IMU, bringen Encoder tatsächlich den Vorteil kraftvollerer Motoren. Aber: Auch hier gilt, dazu braucht man nicht unbedingt Encoder. Das kann man weitgehend genauso gut einfacher über den Strom realisieren (Beispiel CP).

D.h. Encoder bringen natürlich große Vorteile, aber man kann diese auch andersweitig erreichen. Muss jetzt jeder selber entscheiden ob er in Encoder investieren will, oder nur nen Knopf drücken um ne neue Firmware zu flaschen die die 2te IMU anständig ausnutzt (so hätte das AM im Prinzip ja auch anbieten können).

Was in der ganzen Diskussion völlig vergessen wird, ist zu fragen was man den eigentlich verliert wenn man nur Encoder benutzt. Ja, tatsächlich, man verliert was! Und zwar den Vorteil dass man mit 2ter IMU die Regelung erheblich durch sogenanntes Feedforward verbessern kann! Ich für mein Teil bin jedenfalls immer wieder beeindruckt wie gut das funktioniert wenn man man beim STorM32 die 2te IMU einschaltet. Einfach beeindruckend. Ohne 2te IMU kann ich nicht erkennen wie man vergleichbare gut Regelpräzision hinbekommen sollte. Nachdem nun alle immer nur das Beste wollen, sollten daher alle eigentlich auch eine 2te IMU wollen. Aber wenn eh schon ne 2te IMU dran kommt, ... (darf sich jeder selber ausmalen)

Natürlich muss man auch nach den Nachteilen einer 2ten IMU fragen. Klar, die gibt es auch. Der ein oder andere mag die Kalibrierung nennen. Wobei mir nicht wirklich klar ist was an ner 1-Punkt Kalibrierung wild sein sollte (die absoluten Encoder müssen übrigens auch kalibriert werden, also erstmal bitte nachlesen was da alles zu tun ist!). Der größte Nachteil ist vermutlich, dass die Geschichte mit der 2ten IMU immer schwieriger wird, je hochpoliger die Motoren sind. 12 und 14 Pol sind absolut unkritisch, 22 Pol ist schon schwieriger, aber dann ... bei hochpoligen Motoren würde ich nen klaren Vorteil bei Encodern sehen.

 

[Klempnertommy]

Danke, das mit den Motoren hab ich jetzt nicht verstanden, wieso sollen, bzw. sind hochpolige Motoren den schlecht?
Ist das nur beim Storm32 so? Wenn ja, warum?

 

[r0sewhite]

Yaw Drift: Die Pan Achse driftet sowohl mit Encoder als auch mit 2ter IMU exakt gleich, die Encoder bringen hier genau gar keinen Vorteil, njente, nada, Null. Das dem anders wäre ist ein weit verbreiteter Irrglauben, der nicht dadurch richtiger wird das er weit verbreitet ist.

Nee Olli, da muss ich Dir widersprechen. Unsere Controller können auf Tilt und Roll driften, da sie ihre Referenz aus der Sensor Fusion nehmen aber nicht Pan. Hier ist als absolute Referenz nur der Magnet Encoder.

Über die genaue Motorposition hinaus, die wie eben geschildert bis auf den Einschaltvorgang nichts besser machen als eine 2te IMU, bringen Encoder tatsächlich den Vorteil kraftvollerer Motoren. Aber: Auch hier gilt, dazu braucht man nicht unbedingt Encoder. Das kann man weitgehend genauso gut einfacher über den Strom realisieren (Beispiel CP).

Da ich kein Fachmann auf dem Gebiet bin, weiß ich nicht, ob es möglich ist, auch auf anderen Wegen als mit Encodern eine feldorientierte Regelung der Motoren zu erreichen aber genau darin sehe ich den Vorteil. Es wird bei einem BL-Gimbal im Flug immer mal wieder Störgrößen geben, die zuviel des Guten sind. Die Vektorregelung juckt das nicht wirklich. Selbst Objektivwechsel ohne Neujustage des Gimbals haben wir trotz der kleinen GB2208 erfolgreich getestet, was bei AM oder STorm ene kapitulierende Tilt-Achse zur Folge hätte.

Gerade das ist beim CP noch eine extreme Schwachstelle. Ich habe eine dunkle Ahnung, was sich Roee bei dem Recovery Mode gedacht hat aber in der Praxis ist das noch viel schlimmer, als ein einfacher Kommutierungsverlust, also mit anderen Worten genau der gegenteilige Effekt, den wir mit der feldorientierten Regelung haben.

Ich lass mich aber noch überraschen, was da mit dem CP passiert. Leider ist es seit der Ankündigung, dass man an einer v1331 arbeitet, verdächtig ruhig geworden. Es sind echt tolle Ansätze in der Firmware, wie z.B. das Messen der Resonanzfrequenz einer Achse. Lassen wir das Autotuning mal außer acht, würde ich aktuell dennoch aufgrund der Nachteile durch den Recovery Mode ein STorM32 oder AM32 vorziehen.

Was in der ganzen Diskussion völlig vergessen wird, ist zu fragen was man den eigentlich verliert wenn man nur Encoder benutzt. Ja, tatsächlich, man verliert was! Und zwar den Vorteil dass man mit 2ter IMU die Regelung erheblich durch sogenanntes Feedforward verbessern kann! Ich für mein Teil bin jedenfalls immer wieder beeindruckt wie gut das funktioniert wenn man man beim STorM32 die 2te IMU einschaltet. Einfach beeindruckend. Ohne 2te IMU kann ich nicht erkennen wie man vergleichbare gut Regelpräzision hinbekommen sollte. Nachdem nun alle immer nur das Beste wollen, sollten daher alle eigentlich auch eine 2te IMU wollen. Aber wenn eh schon ne 2te IMU dran kommt, ... (darf sich jeder selber ausmalen)

Feedforward ist natürlich ein schlagendes Argument, da muss ich Dir zustimmen. Aber für mich als Laien: Ließen sich die Vorteile eines hochauflösenden Encoders nicht mit den Vorteilen einer zweiten IMU kombinieren oder gibt es eine Alternative dazu? Wäre z.B. ein gut kalibrierter Magnetometer geeignet, einen Encoder zu ersetzen?

 

[OlliW]

Nee Olli, da muss ich Dir widersprechen. Unsere Controller können auf Tilt und Roll driften, da sie ihre Referenz aus der Sensor Fusion nehmen aber nicht Pan. Hier ist als absolute Referenz nur der Magnet Encoder.

Also, ich will hier jetzt kein großes Streitgespräch starten, daher nur ein letzter Versuch:

Zum anderen kann die Pan-Achse immer noch driften, sei es durch schlechte Kalibrierung oder zu starke Störeinflüsse wie Vibrationen, solange die IMUs kein Magnetometer mit drauf haben.

dies Aussage ist so wie sie da steht falsch.
Der Gyro driftet auf allen drei Achsen. Die Drift auf Pitch und Roll lässt sich dank der Bechleunigungsmesser in den Griff bekommen, die der Yaw Achse nicht.
Ich denke man darf davon ausgehen dass du mit "Pan-Achse ... driften" dieses Problem meinst. Wenn nein, dann hätten wir unser Missverständnis, und ich würde dich bitten genauer zu erklären was du meinst. Wenn ja, dann gilt meine Aussage, dass sich hier mit Encodern NICHTS verbessern lässt.

Diesen eventuell wichtigen Hinweis noch, da hier ein Missverständnis vorliegen kann: Gegen die Yaw Drift lässt sich (ausser mit Magnetometer oder GPS oder ... aber keinesfalls Encoder) nichts machen. Wenn nun das Gimbal im Hold Modus ist, schlägt das auch voll durch und man kann das leicht sehen, einfach mal das Gimbal mit Yaw in Hold 15 Min stehen lassen. Im Pan = Follow Modus jedoch lässt sich das verhindern, so dass das Gimbal auch nach unendlicher Zeit immer noch nach vorne sieht (die IMU driftet, aber die Kamera nicht). Dazu kann man die Encoder nehmen, aber das geht auch viel einfacher! Jedenfalls kann dass das STorM32 auch ohne Encoder. Dazu einfach mal das Gimbal mit Yaw in Pan für 2 Tage stehen stehen lassen (braucht ne dicke Battery, ihr könnt Euch natürlich auch mit 2 h zufrieden geben), rum bewegen wie Ihr wollt, die Kamera wird immer wieder exakt nach vorne zurück-panen. Das geht nur im Pan/Follow Modus. D.h. z.B., dass wenn im Pan/Follow Mode ein Deadband aktiviert ist, der die Kamera in nem kleinen Winkelbereich im Hold Modus hält, dann wird, wenn ihr das Gimbal stehen lasst, die Kamera an die Deadband-Grenze driften (sie ist ja solange im Hold Modus = keine Chance gegen Yaw Drift) und erst da zum stehen kommen. Also, umd das alles klar zu sehen Deadband z.B. auf Null setzen.

Kurzum, bei dem "Pan-Achse ... driften" kommt es auf den Modus an. Im Hold Modus kann man - mit oder ohne Encoder - nichts dagegen machen, im Pan/Follow Modus kann man - mit oder ohne Encoder - das Gleiche dagegen machen.

Euer Encoder System wird sich darin in keiner Weise unterscheiden, d.h. mit oder ohne Encoder ergibt sich da genau kein Unterschied, was meine Aussagen war.

Wenn du immer noch dazu neigst dem zu widersprechen bzw meinst das Euer Encoder System da was besser kann, dann würde ich dich bitten vorher die obigen Texte deinen Entwicklern zu zeigen und dich bei Ihnen rückversichern. Wenn ihr dann immer noch widersprecht, dann würde ich mir eine "Beweis" wünschen, z.B. ein Video in dem Ihr zeigt dass das Gimbal im Yaw Hold Modus ist, das Gimbal ständig (auch gerne langsam) hin-und-her bewegt wird, und die Kamera trotzdem nach 30 Min nicht um Yaw gedriftet ist (erlaubt sind natürlich nur 6DOF IMU und Encoder)

@KT:
Der Ursprung der ganzen Problematik ist ja, dass die elektrische Motorn Position "kleiner" als die mechanischen 360° sind, und es so keine eindeutige Zuordnung zwischen elektrischem Winkel und mechanischen Winkel gibt. Bei einem 12 Pol Motor sind das 60° bzw. +-30°, d.h. man kann bei gleichem el. Winkel den Motor jeweils um 30° weiterdrehen und ab da wird er in die 60° Position einschnappen. Bei 14 Pol sind's schon nur noch +-26°, bei 22 Pol +-16° und bei 48 Pol +-7°. Die Messungen der zwei IMUs müssen nun so gut übereinstimmen, dass die Fehler kleiner als diese Grenzen sind. +-26° ist ziemlich einfach zu erreichen, auch mit schlechter oder gar gar keinen IMU Kalibrierungen. +-7° weis ich nicht, klingt aber eben schwierig ...

 

[r0sewhite]

Weia! Sorry Olli, ich hab echt nicht richtig nachgedacht. Natürlich kann es im Hold Mode nur driftfrei sein, wenn ein Mag zur Orientierung drauf ist, weil der Copter selber keine Referenz mehr darstellt. Um den Unterschied zwischen Hold und Follow hab ich mir gar keine Gedanken gemacht. Ich sollte wohl besser nicht so spät Nachts mehr posten.

 

[OlliW]

null Problemo

dann ist nur noch zu klären dass der Pan/Follow Modus auch ohne Encoder drift-frei zu bekommen ist ... das können aber alle STorM32 Nutzer an meiner statt demonstrieren

zum FOC usw., da möchte ich mich nicht zu weit rauslehnen, denn so gut verstehe ich das FOC nicht, d.h. ich glaube dir gerne dass ihr mit FOC verblüffend viel "Kraft" rausholen konntet, und vielleicht mehr als über den Strom (wobei ich ja glaube dass das FOC von dem immer geredet wird gar kein echtes FOC ist, sondern ein nettes Buzzword, aber der Effekt bleibt natürlich). Ich wollte nur andeuten dass man auch über den Strom IMHO sehr weit kommen kann ... wie immer: wenn man's gut macht ... auch ne FOC kann man verhunzen, oder ne 2te IMU, und der Bezug zum CP sollte nichts weiter implizieren als das es diese Möglichkeit gibt, und nicht ob's da gut oder schlecht gemacht ist ...

 

[r0sewhite]

Wie willst Du einen Follow Mode mit IMUs driftfrei kriegen? Mit zwei IMUs driftet ja nicht nur der Gimbal, sondern auch noch die Referenz, was sich addieren kann. Nicht, dass ich das anzweifele aber es leuchtet mir nicht ein.

 

[OlliW]

Wie willst Du einen Follow Mode mit IMUs driftfrei kriegen?

hihi ... genauso wie mit Encoder, das man die Motoren als Referenz benutzt ... funktioniert seit Version v0.0 einwandfrei, probiers mal

Mit zwei IMUs driftet ja nicht nur der Gimbal, sondern auch noch die Referenz, was sich addieren kann.

jo ... und deswegen geht auch beim AM die 2te IMU über Yaw nicht gut ... aber ... man kann was dagegen machen, und das STorM32 macht das, und deswegen kommt es mit 2ter IMU über Yaw zurecht, und kann die ganzen Vorteile davon nutzen

 

[j-man]

Was genau macht denn das STorm32 so anders, dass es mit einer 2. IMU über YAW zurecht kommt?

 

[AndreasL90]

STorM32 und Pixhawk...
Das dürfte den Ein- oder Anderen sehr interessieren, da es völlig neue Möglichkeiten eröffnet:

We've been working with OlliW and have added a SToRM32 gimbal library into master (so it will go out with AC3.3) this will mean you can plug the SToRM32 gimbal into the Pixhawk's serial port. So far we only have the do-mount-control messages working which means we're only using mavlink to send the target angles to the gimbal but it opens the door to a lot more communication that we couldn't do via PWM. Things like easing the set-up for the user and passing down acceleration corrections so the gimbal angles remain accurate even during more aggressive maneuvers.

 

[Allan Sche Sar]

Hallo ihr,

ich habe zwei Fragen und ich glaube ihr könnt mir weiter helfen

1. Ich bin bei der Planung meines zweiten Gimbal. Bei dieser Version sollen die Kabel sehr schön verlegt werden (jetzt sind sie nur frei hängend an der Seite). Ich stelle mir jedoch die Frage, wie das IMU Kabel verlegt werden soll. Meine Kamera (eine Mobius oder GoPro) ist so leicht, dass ich keine zweite Lagerung des Pitch Arms brauche. Aber wenn ich das IMU Kabel direkt bei den Motorkabeln verlege, bekomme ich doch Störungen rein. Außerdem soll das IMU Kabel durch den Yaw und Roll Motor gelegt werden - genauso wie die Stromkabel der Motoren selber. Wie stelle ich dies nun am besten an?
2. Die zweite Frage geht in Richtung der Möglichkeiten des Boards. Ist es möglich anstatt einer Drehbewegung auch Linearmotoren anzutreiben? Also das der Storm keine Drehbewegungen ausgleicht, sondern Translationsbewegungen.

 

[digaus]

Hallo ihr,

ich habe zwei Fragen und ich glaube ihr könnt mir weiter helfen

1. Ich bin bei der Planung meines zweiten Gimbal. Bei dieser Version sollen die Kabel sehr schön verlegt werden (jetzt sind sie nur frei hängend an der Seite). Ich stelle mir jedoch die Frage, wie das IMU Kabel verlegt werden soll. Meine Kamera (eine Mobius oder GoPro) ist so leicht, dass ich keine zweite Lagerung des Pitch Arms brauche. Aber wenn ich das IMU Kabel direkt bei den Motorkabeln verlege, bekomme ich doch Störungen rein. Außerdem soll das IMU Kabel durch den Yaw und Roll Motor gelegt werden - genauso wie die Stromkabel der Motoren selber. Wie stelle ich dies nun am besten an?
2. Die zweite Frage geht in Richtung der Möglichkeiten des Boards. Ist es möglich anstatt einer Drehbewegung auch Linearmotoren anzutreiben? Also das der Storm keine Drehbewegungen ausgleicht, sondern Translationsbewegungen.

Schau mal hier: http://fpv-community.de/showthread.php?t=50913

Zur Not musst du einen kleineren Pullup Widerstand einlöten.

 

[Allan Sche Sar]

Ich habe in deinem Thread einmal nachgelesen, so ganz ist es mir noch nicht klar, daher habe ich dort eine Frage hinterlassen ^^
Kannst du mir auch etwas zu meiner zweiten Fragen (Translationsbewegung) sagen?

 

[Flieger-DT]

Hi -

ich beschäftige mich eher mit der 'Drachenluftbildfotografie', bin aber mit einem F450 in's 'Modellfliegen' eingestiegen.

Ich habe hier lange mitgelesen und mir jetzt ein STorm32 BGC Board v1.30 mit der v0.56 Firmware gekauft ;-)

Gestern Abend habe ich es dann verkabelt und die ersten Schritte vorgenommen, um das Board zunächst als zwei Achsen (Pitch und Roll) Gimbal zu konfigurieren.
Hat auch soweit gut geklappt, Kamera IMU und Motoren wurden erkannt, anschließend habe ich noch die Bluetooth Schnittstelle aktiviert und schließlich einen 3S LiPo angeschlossen und die Motoren gestartet.

Ein erster Fehler hatte sich eingeschlichen, ich hatte Pitch und Roll vertauscht. Also noch einmal neu, beide Motoren liefen und in meiner Bluetooth Umgebung war das 'Dev B auf STorm32-BGC' COM6 zu sehen ... Die 'Dienste' wurden allerdings nicht gefunden.

Heute Nachmittag habe ich die 'fliegende Anordnung' provisorisch montiert und versucht, per Bluetooth eine Verbindung herzustellen, ohne Erfolg - immer wenn ich versuche über COM6 auf das Board zuzugreifen, erhalte ich die Meldung 'READ ABORTED' ...
Anschließend habe ich mir dann noch auf's iPhone die 'GimbalControll app von Rebotnix' geladen, aber die 'findet' das STorm32 Board offenbar auch nicht ...

Eine weitere 'böse Überraschung' war dann, die Motoren lassen sich nicht mehr starten. Auf Kurzschluss hatte ich sie vor dem Anschließen gemessen, das war o.K..

Die Widerstandswerte hatte ich nicht gemessen, habe ich heute nachgeholt, liegen alle bei 5,8 Ohm.
Ich hoffe nicht, das ist zu wenig und ich habe gestern bei den wenigen kurzen Startversuchen die Motortreiber (?) gegrillt 😳

Sooo - es ist ein ellenlanger Text geworden und vielleicht hat jemand einen Tip für mich (ach ja, ich habe heute dieWerte noch einmal auf Default gesetzt und alles noch einmal durchgespielt - ohne Erfolg)

 

[wolfes1126]

Anschließend habe ich mir dann noch auf's iPhone die 'GimbalControll app von Rebotnix' geladen, aber die 'findet' das STorm32 Board offenbar auch nicht ...

Die App ist ja auch nur für BAsecam (Alexmos) Kontroller in Verbindung mit einem Rebotnix BT Modul.

 

[digaus]

Die Widerstandswerte hatte ich nicht gemessen, habe ich heute nachgeholt, liegen alle bei 5,8 Ohm.
Ich hoffe nicht, das ist zu wenig und ich habe gestern bei den wenigen kurzen Startversuchen die Motortreiber (?) gegrillt ��

5,8 Ohm sind eindeutig zu wenig! Ist denn der Widerstand zwischen jeder Phase 5,8 Ohm? Der Motor sollte mindestens einen Widerstand von 10 Ohm haben.

 

[Flieger-DT]

5,8 Ohm sind eindeutig zu wenig! Ist denn der Widerstand zwischen jeder Phase 5,8 Ohm? Der Motor sollte mindestens einen Widerstand von 10 Ohm haben.

Hmm -

also könnte im im schlimmsten Fall die Motorentreiber 'gegrillt' haben ...?

Ich könnte ja noch einmal den Motor2 Anschluss testen - daran hatte ich bisher noch nichts angeschlossen ...

Könnte die 'Bluetoothproblematik' damit zusammenhängen, daß ich noch WIN XP nutze? Über die USB Schnittstelle kann ich problemlos auf das Board zugreifen, nachdem ich die passenden WIN7 Treiber installiert habe.
In meiner Bluetooth Umgebung wird der Kontroller als 'DEV B auf STorm32-BGC' unter COM6 ja gefunden?

Die iPhone app soll lt. OlliW auch mit dem STorm32 BGC laufen, siehe https://vimeo.com/112961399 ...

 

[Flieger-DT]

... also könnte im im schlimmsten Fall die Motorentreiber 'gegrillt' haben ...?
...
Die iPhone app soll lt. OlliW auch mit dem STorm32 BGC laufen, siehe https://vimeo.com/112961399 ...

hi -

eine gute Nachricht ...

Ich habe heute alles wieder 'rück gebaut' - Controller raus, Kabel ab, ...

Neuer Versuch mit einem anderen Motor und siehe da (Glück gehabt ?), Motor läuft - also doch nicht gegrillt

Weiter besteht jedoch das 'Bluetooth Problem' - jetzt die aktuelle Variante, wenn ich das Bluetooth Configure Tool starte, beginnt ein Scan der unterschiedlichen baud Raten und es kommt jeweils die Meldung 'no BT Module at this baud Rate' und somit schließlich als Ergebnis 'CHECK FAILED, something went wrong'

Habe es noch einmal mit einem Controller reset versucht, aber bisher kein Erfolg. Ich geb's erst einmal auf ...