STorM32 BGC: 3-Achsen STM32 Brushless Gimbal Controller

[r0sewhite]

Fragen von meiner Seite, was soll daran so schlimm sein? Das wollte ich bei meiner nächsten Konstruktion auch machen.

Es KANN zu I2C-Fehlern führen, muss aber nicht. Einfach ausprobieren, dann siehst Du es schon. Entgegenwirken kannst Du mit Verdrillen des Kabels und/oder Ferritringen. Allerdings scheint mir das Board weitaus unanfälliger dafür zu sein, als ein Basecam 32 bit.

Hast du die Platine/IMU in deinem CFK Rohr gut isoliert ????
Vielleicht "leitet" da ja irgendwas.....

Das ist eigentlich gut isoliert: Auf einen langen Streifen GFK geklebt und mit Schaumstoff umwickelt in das Rohr geschoben. Dummerweise kann ich so auch schlecht erkennen, ob im Fall eines IMU-Ausstiegs die LED darauf noch leuchtet.

Ich hatte immer das Problem, dass nach einigen Sekunden ohne jegliche I2C Fehler plötzlich der BUS abstürzt und die Fehler hochzählen bis das Board rückgesetzt wird. Das hört sich doch genauso wie bei dir an, außer das du statt nur einigen Sekunden das ganze etwas länger betreiben kannst.

Zusammen mit Digaus haben wir das Problem gelößt, indem wir statt der GY521 IMU die kleine von Witespy eingesetzt haben und die Eingangsspannung auf 12 Volt reduziert haben. Ab 14Volt stürzt der BUS immer ab. Mit der großen GY521 IMU funktioniert es auch bei kleineren Spannungswerten nicht.

Probier es doch einfach mal mit einem Labornetzteil mit 12V Ausgangsspannung statt dem 4S Lipo aus - der Kopter muss ja nicht fliegen.

Stimmt, das hört sich in der Tat gleich an. Allerdings ist mein Board von Whitespy und hat dementsprechend schon die kleine IMU. Ich werde den Controller mal an 12V betreiben und schauen, was passiert.

EDIT: Kannst Du Dich erinnern, was die rote Heartbeat-LED in dem Fall gemacht hat?

 

[Fry3199]

Die rote LED ist dann im schnellen Wechsel an/aus geschalten worden. So 2 oder 3 Mal pro Sekunde

 

[r0sewhite]

Ok, das würde laut Wiki auch auf fehlende IMU deuten. Meine blinkt im Fehlerfall allerdings langsamer und nicht schneller.

 

[Fry3199]

Genau kann ich es dir leider nicht mehr sagen wie die Frequenz war. Vielleicht kann Digaus etwas dazu sagen wenn er hier mitliest. Er hat den Effekt auch beobachtet.

Berichte mal, was beim Betrieb mit 12V rauskommt!

 

[digaus]

Ich habe mir die Frequenz der LEDs leider nicht angeguckt, ich habe immer das Datadisplay am Laufen gehabt. Das ist wirklich sehr hilfreich bei sowas. Es muss aber nicht zwingend zu I2C Fehlern kommen, wenn man die Kabel durch die Motoren führt, das hängt auch von den Motoren ab. Ich habe für den Yaw Motor einen größeren als für Roll und Nick gewählt und dieser verursacht keine Fehler. Und je größer die Spannung desto größer natürlich die Störungen. Mit einem Labornetzteil konnte ich nur bis auf 14V gehen, bis es zu I2C Fehlern kam.

Was ich aber seltsam finde, der Controller steigt sofort aus auch wenn es nur einen einzigen I2C Fehler gibt. Selbst wenn ich die Motoren wieder deaktiviere, zählen die I2C Fehler weiter hoch. Dabei dürfte es dann doch keine mehr geben?!
Ich hatte auch mal den evvgc im Einsatz und da hatte ich sehr oft I2C Fehler. Da lief das Gimbal aber noch wunderbar mit mehreren Fehlern pro Sekunde.

@Fry3199
Ich habe mir die große IMU nochmal etwas genauer angeguckt und da ist mir aufgefallen, dass zwei Bauteile an einer Seite Kontakt haben:


Es könnte evtl daran liegen, dass die IMU schon früher aussteigt.

 

[yang]

Es gibt zwei Arten von I2C Fehlern. Bei manchen kann man den Bus resetten, bei anderen bleibt einfach der Pegel stehen und keine weitere Kommunikation ist möglich. Als Anwender sieht man also entweder I2C Fehler hochzählen oder keine Kommunikation mehr.

Ich hatte dieses Thema schon mal mit Olli besprochen und wir sind zu dem Schluss gekommen dass alles gemacht wird um nach einem I2C Fehler den Bus wieder in Gang zu bringen.
Am besten wäre es den I2C Bus zu monitoren, um vielleicht doch einen Zustand zu finden, in dem noch nicht alles gemacht wird.

 

[Fry3199]

@digaus: die beiden Bauteile sind eh an der stelle durch eine Leiterbahn verbunden, deswegen hab ich dies nicht korrigiert. Daran liegt es nicht, ich hab außerdem noch eine zweite Gy521 mit dem gleichen Fehlerbild getestet.

Ich gehe davon aus, das es sich wirklich um einen Konfigurationsfehler in der Firmware handelt. Statt einmalig einen i2c Fehler hochzuzählen und danach weiter zu kommunizieren, wird der Bus komplett deaktiviert.

Das es nicht an der IMU liegt, zeigt ja auch das die Witespy IMU bei höherer Spannung ebenfalls ausfällt.

@yang:
Wir haben hier aber den dritten Fall: die Kommunikation ist noch da, sobald der erste I2C Fehler eingetragen wird, wird der Zähler schnell inkrementiert!

 

[yang]

Vielleicht solltet ihr Olli nochmals zu diesem Thema anschreiben?

Und etwas wie hier könnte die Lösung für die Firmware sein? (External_Slave_Device_Hanging_the_Bus_by_Holding_SDA_Low)
http://processors.wiki.ti.com/index...ave_Device_Hanging_the_Bus_by_Holding_SDA_Low

 

[Fry3199]

Ich habe das Problem im RCGroups Forum versucht zu beschreiben

 

[Klempnertommy]

Anhang anzeigen 113896

Es könnte evtl daran liegen, dass die IMU schon früher aussteigt.

Du hast auf dem Breakout auch noch 4.7K Pullups, wieso sich das nochnicht rum gesprochen hat, weis ich auch nicht, aber,
da der I2C Bus, lass mich lügen, 400Hz, also schnell eben und aber nur mit 3.3V läuft ist das zu viel, mach dort 1K drauf und Die Fehler sind Vergangenheit.
Das sind höchstwahrscheinlich die beiden Krümel rechts neben Deinem grünen Kringel.

 

[Fry3199]

4.7 k pullups auf der Gy521?
Olliw hat gestern von 2.2k gesprochen.

Woher hast du die Info?

 

[Klempnertommy]

Sorry, bin von MPU6050 ausgegangen.
Wie das beim GY ist weis ich nicht, prinzipiell aber ähnlich, ist ja das gleiche Bus System.
Wie hoch die Pulls sein müssen hängt davon ab, was die Chips intern schon haben, wie hoch die Datenrate ist und wie lang man die Kabel auslegt und ob man Busstreiber verwendet und was die so verlangen
Das kann man aber auch alles im Datenblatt nachlesen.
Im Grenzfall dann lieber ein klein wenig kleiner wählen als zu hoch.
Beim MPU6050 haben sich 1k bei mir bewährt (original sind immer 2.2k oder 4.7k).
Ich ändere die mittlerweile grundsätzlich IMMER auf 1K oder packe einen zweiten 2.2k einfach nochmal drüber und habe seitdem weder mit Gimbals noch mit FC´s Probleme gehabt.
Beispiel: Mit den original Bestückung an der ersten IMU und 1K an der zweiten (alexmos) kann ich sogar problemlos das Kabel durch alle Motorwellen ziehen und habe keine Fehler mehr.
Die Signal Flanken des Signales sehen auch viel besser aus, aber vielleicht schaut sich das mal jemand an, der ein besseres oszi hat als ich, und kann das vielleicht sogar bestätigen.

 

[r0sewhite]

Guter Hinweis. Abgesehen von der Betriebsspannung sind die Pullups auch noch etwas, das man kontrollieren kann. Wobei ich mich schon frage, warum sich die Betriebsspannung auf die I2C-Kommunikation auswirkt, denn der Bus sollte eigentlich mit einer stabilen geregelten Spannung laufen. Allerdings bin ich diese Woche beim Skifahren und komme erst nächste Woche dazu, mich weiter damit zu beschäftigen.

 

[Fry3199]

Die DC-Spannung beeinflusst ja nicht den I2C Bus, sondern die Phasenspannung der Motoren. Da diese bei erhöhter Spannung auch erhöhte Störfelder erzeugen, erhöht sich auch die Gefahr von I2C Fehlern.

 

[Klempnertommy]

nein, so einfach ist das nicht, das Problem sind ja nicht nur die äußeren Störeinflüsse, die kommen ja noch obendrein.
Das Problem gibt es ja generell bei den ganzen onewire Highspeed Bussystemen...
Fragt mal den DSL Mann, wieso ihr kein schnelles DSL bekommt, der Nachbar aber schon
Je schneller der Bus ist und je länger die Kabel, desto schlechter wird das Signal (flankensteilheit)
Wenn der Sensor nur eine langsame Bussgeschwindigkeit fährt (das kann der Programmierer ja bestimmen) Dann sind sogar 4.7K in Ordnung... nur die meisten lesen die Sensoren heute ja so schnell wie nur irgend möglich aus...
Also erst klären, wie schnell die Applikation mit dem Bus arbeitet, dann welche Pegel verwendet werden, dann Datenblatt schauen und dann die Pulls auswählen... Und nicht einfach aus irgendwelchen anderen openhardware Projekten blind die *.sch abkupfern.

 

[digaus]

Es ging dabei ja nur um die Frage, warum eine höhere Betriebsspannung einen Einfluss auf den I2C Bus hat und ich denke das hat fry3199 richtig erklärt. Natürlich spielen andere Faktoren, wie die Pullups, auch eine entscheidende Rolle.

 

[Klempnertommy]

sorry, hab wohl schon wieder zu weit ausgeholt

Was ich eigentlich mit all dem sagen wollte ist, wenn alleine ein höheres Motor/Kabel Störfeld den Bus zum abstürzen bringt, dann waren die Signale wahrscheinlich vorher schon grenzwertig und mann sollte sich diese mal genauer anschauen.

 

[r0sewhite]

Ok, an die Motoren hatte ich gar nicht gedacht, sondern bin gedanklich beim I2C -Bus hängen gebliebenen. Schon klasse, wie zwei Tage an der frischen Luft den Kopf leeren können

 

[r0sewhite]

So, ich bin wieder zurück und hab mal einen 3S Lipo drangehängt: Bei unveränderter Konfiguration keine Probleme. Dann werden wir der I2C-Leitung mal an den Hals gehen. Eventuell reicht ja ein geschirmtes Kabel und die Pullups kann ich mir ja auch noch genauer anschauen.

 

[Alveran]

So, ich bin wieder zurück und hab mal einen 3S Lipo drangehängt: Bei unveränderter Konfiguration keine Probleme. Dann werden wir der I2C-Leitung mal an den Hals gehen. Eventuell reicht ja ein geschirmtes Kabel und die Pullups kann ich mir ja auch noch genauer anschauen.

Also kann man sagen ... ein 12V BEC zwischen Akku und Controller hängen und die "Sache ist so gut wie Gegessen"??