Brushless Gimbal Controller - SOFTWARE
- Themenstarter Lonestar78
- Beginndatum
- Status
@Spookymike
was mir so einfällt:
es könnte sein, daß Motor- bzw. Propellervibrationen drauf sind.
Einfach mit der Hand fühlen, ob feine Vibrationen am Rahmen spürbar sind und ob diese auf das Gimbal übertragen werden.
Falls Ja, Propeller auswuchten.
Die Aufhängung möglichst hart machen, das ist immer ein Kompromiss, aber je weniger Motorvibrationen umso härtere Gummis kann man verwenden. Auch ein weicher Rahmen könnte sich aufschwingen.
Beim schnellen Abstieg ist der Kopter üblicherwiese besonders unruhig, Probleme mit Schwerpunkt o.ä. treten dann leichter zutage.
Beim Gimbal:
Die Kamera sollte sich leicht bewegen können. Auf Zuleitungskabel zu Motor und Sensoren achten, die können leicht verhaken.
Schwerpunkt in den Drehachsen, die Kamera sollte nicht von selbst wegkippen.
PWM darf man ruhig kräftig aufdrehen, Grenze ist einmal die Leistung der Motoren, sie sollten nicht zu heiß werden.
Und die Schwingneigung wird dann auch kritischer.
Die Versorgung möglichst stabilisieren, ich verwende bei meinem GoPro Gimbal eine 8V Stabilisierung (Jeti BEC oder ähnl.).
zum RC:
die Geschwindigkeit kann man per Zeitkonstante im RC Tab verändern, allerding kommen mit niedrigen Zeitkonstanten eine leichte Unruhe hinzu, stört aber möglichweise nicht.
Bei Gier ist mir nur aufgefallen dass der Kopter doch relativ stark abweicht, vielleicht kann man das besser stabilisieren, oder Expo bei der Funke verwenden.
War jetzt viel auf einmal, vielleicht ist etwas brauchbares dabei
lg
Alois
was mir so einfällt:
es könnte sein, daß Motor- bzw. Propellervibrationen drauf sind.
Einfach mit der Hand fühlen, ob feine Vibrationen am Rahmen spürbar sind und ob diese auf das Gimbal übertragen werden.
Falls Ja, Propeller auswuchten.
Die Aufhängung möglichst hart machen, das ist immer ein Kompromiss, aber je weniger Motorvibrationen umso härtere Gummis kann man verwenden. Auch ein weicher Rahmen könnte sich aufschwingen.
Beim schnellen Abstieg ist der Kopter üblicherwiese besonders unruhig, Probleme mit Schwerpunkt o.ä. treten dann leichter zutage.
Beim Gimbal:
Die Kamera sollte sich leicht bewegen können. Auf Zuleitungskabel zu Motor und Sensoren achten, die können leicht verhaken.
Schwerpunkt in den Drehachsen, die Kamera sollte nicht von selbst wegkippen.
PWM darf man ruhig kräftig aufdrehen, Grenze ist einmal die Leistung der Motoren, sie sollten nicht zu heiß werden.
Und die Schwingneigung wird dann auch kritischer.
Die Versorgung möglichst stabilisieren, ich verwende bei meinem GoPro Gimbal eine 8V Stabilisierung (Jeti BEC oder ähnl.).
zum RC:
die Geschwindigkeit kann man per Zeitkonstante im RC Tab verändern, allerding kommen mit niedrigen Zeitkonstanten eine leichte Unruhe hinzu, stört aber möglichweise nicht.
Bei Gier ist mir nur aufgefallen dass der Kopter doch relativ stark abweicht, vielleicht kann man das besser stabilisieren, oder Expo bei der Funke verwenden.
War jetzt viel auf einmal, vielleicht ist etwas brauchbares dabei
lg
Alois
Probier einmal die r203a.
http://fpv-community.de/showthread....oller-SOFTWARE&p=511218&viewfull=1#post511218
Möglicherweise liegts an der Codegröße, bei manchen Boards lässt der Bootloader weniger Platz frei.
Die 203a ist etwas kleiner, sag ob sie funktioniert.
lg
Alois
http://fpv-community.de/showthread....oller-SOFTWARE&p=511218&viewfull=1#post511218
Möglicherweise liegts an der Codegröße, bei manchen Boards lässt der Bootloader weniger Platz frei.
Die 203a ist etwas kleiner, sag ob sie funktioniert.
lg
Alois
Hallo,
hier mit der 202 und dem original schwarzen board direkt von martinez und aufdruck by martinez
Binäre Sketchgröße: 30.340 Bytes (von einem Maximum von 32.256 Bytes)
avrdude: verification error, first mismatch at byte 0x7000
0x5f != 0xff
avrdude: verification error; content mismatch
Die 203a schaff ich gar nicht zu uploaden das folgende fehlter entstehen:
In file included from _BruGi.ino:58:
/BLcontroller.h: In function 'void __vector_13()':
BLcontroller.h:225: error: 'TIMER0_isr_emulation' was not declared in this scope
_BruGi.cpp.o: In function `checkRcTimeouts()':
/RCdecode.h:189: undefined reference to `microsT1()'
_BruGi.cpp.o: In function `PCintPort:Cint()':
/PinChangeInt.h:488: undefined reference to `microsT1()'
_BruGi.cpp.o: In function `accCalibration()':
/orientationRoutines.h:128: undefined reference to `delayT1(unsigned long)'
/orientationRoutines.h:146: undefined reference to `delayT1(unsigned long)'
_BruGi.cpp.o: In function `gyroOffsetCalibration()':
/orientationRoutines.h:51: undefined reference to `delayT1(unsigned long)'
/orientationRoutines.h:58: undefined reference to `delayT1(unsigned long)'
I2Cdev.cpp.o: In function `I2Cdev::readBytes(unsigned char, unsigned char, unsigned char, unsigned char*, unsigned int)':
C:\Users\Mike\AppData\Local\Temp\build2058374360963146366.tmp/I2Cdev.cpp:219: undefined reference to `millisT1()'
C:\Users\Mike\AppData\Local\Temp\build2058374360963146366.tmp/I2Cdev.cpp:284: undefined reference to `millisT1()'
C:\Users\Mike\AppData\Local\Temp\build2058374360963146366.tmp/I2Cdev.cpp:310: undefined reference to `millisT1()'
hier mit der 202 und dem original schwarzen board direkt von martinez und aufdruck by martinez
Binäre Sketchgröße: 30.340 Bytes (von einem Maximum von 32.256 Bytes)
avrdude: verification error, first mismatch at byte 0x7000
0x5f != 0xff
avrdude: verification error; content mismatch
Die 203a schaff ich gar nicht zu uploaden das folgende fehlter entstehen:
In file included from _BruGi.ino:58:
/BLcontroller.h: In function 'void __vector_13()':
BLcontroller.h:225: error: 'TIMER0_isr_emulation' was not declared in this scope
_BruGi.cpp.o: In function `checkRcTimeouts()':
/RCdecode.h:189: undefined reference to `microsT1()'
_BruGi.cpp.o: In function `PCintPort:
Cint()':/PinChangeInt.h:488: undefined reference to `microsT1()'
_BruGi.cpp.o: In function `accCalibration()':
/orientationRoutines.h:128: undefined reference to `delayT1(unsigned long)'
/orientationRoutines.h:146: undefined reference to `delayT1(unsigned long)'
_BruGi.cpp.o: In function `gyroOffsetCalibration()':
/orientationRoutines.h:51: undefined reference to `delayT1(unsigned long)'
/orientationRoutines.h:58: undefined reference to `delayT1(unsigned long)'
I2Cdev.cpp.o: In function `I2Cdev::readBytes(unsigned char, unsigned char, unsigned char, unsigned char*, unsigned int)':
C:\Users\Mike\AppData\Local\Temp\build2058374360963146366.tmp/I2Cdev.cpp:219: undefined reference to `millisT1()'
C:\Users\Mike\AppData\Local\Temp\build2058374360963146366.tmp/I2Cdev.cpp:284: undefined reference to `millisT1()'
C:\Users\Mike\AppData\Local\Temp\build2058374360963146366.tmp/I2Cdev.cpp:310: undefined reference to `millisT1()'
Sehr merkwürdig ;-)
zur r203a:
ich hab sie testweise heruntergeladen und in ein leeres Verzeichnis ausgepackt.
Compiliert problemlos, mit Arduino 1.5.4.
Schaut so aus als ob bei dir Dateien fehlen, eventuell nochmals runterladen und neu bauen.
zum eigentlichen Problem:
Ich verwende ebenfalls ein Martinez zum testen.
An der Codegröße kann es dann nicht liegen.
Deine Fehlermeldung deutet eher auf ein kaputtes Flash.
avrdude: verification error, first mismatch at byte 0x7000
0x5f != 0xff
avrdude: verification error; content mismatch
Die Adresse 0x7000 würde bedeuten, dass die maximale Codegröße 28672 bytes beträgt. Vermutlich steckt in den Boards ein anderer Bootloader als erwartet.
Welche Board Type ist bei dir eingestellt. Beim Martinez verwende ich "Arduiono UNO".
Ansonsten würde einmal ein anderes Exemplar verwenden, vielleicht hat dein Board einen Fehler ...
lg
Alois
zur r203a:
ich hab sie testweise heruntergeladen und in ein leeres Verzeichnis ausgepackt.
Compiliert problemlos, mit Arduino 1.5.4.
Schaut so aus als ob bei dir Dateien fehlen, eventuell nochmals runterladen und neu bauen.
zum eigentlichen Problem:
Ich verwende ebenfalls ein Martinez zum testen.
An der Codegröße kann es dann nicht liegen.
Deine Fehlermeldung deutet eher auf ein kaputtes Flash.
avrdude: verification error, first mismatch at byte 0x7000
0x5f != 0xff
avrdude: verification error; content mismatch
Die Adresse 0x7000 würde bedeuten, dass die maximale Codegröße 28672 bytes beträgt. Vermutlich steckt in den Boards ein anderer Bootloader als erwartet.
Welche Board Type ist bei dir eingestellt. Beim Martinez verwende ich "Arduiono UNO".
Ansonsten würde einmal ein anderes Exemplar verwenden, vielleicht hat dein Board einen Fehler ...
lg
Alois
Zuletzt bearbeitet:
Hi,
ich möchte auch mal meinen Senf dazu geben:
Habe mein neues Gimbal jetzt fertig gebaut und bekomme beim Flashen der r200 und r202 an zwei verschiedenen Martinez-Boards die Meldung:
Die r203a lässt sich auf beiden Boards wieder korrekt flashen, allerdings bekomme ich das Gimbal damit nicht eingestellt (dachte schon es liegt an der Hardware, Sensorleitung,..). Das GUI verbindet zwar erfolgreich und ein Verstellen der Parameter bewirkt auch was, nach 45min gezappel hab ich dann allerdings aufgegeben. Auch der Live View Monitor der Sensordaten spuckt nichts aus, bleibt einfach leer.
Mit der 049B_r161 konnte ich das Gimbal innerhalb weniger Minuten ruhig bekommen.
Viele Grüße,
Stephan
ich möchte auch mal meinen Senf dazu geben:
Habe mein neues Gimbal jetzt fertig gebaut und bekomme beim Flashen der r200 und r202 an zwei verschiedenen Martinez-Boards die Meldung:
Die r203a lässt sich auf beiden Boards wieder korrekt flashen, allerdings bekomme ich das Gimbal damit nicht eingestellt (dachte schon es liegt an der Hardware, Sensorleitung,..). Das GUI verbindet zwar erfolgreich und ein Verstellen der Parameter bewirkt auch was, nach 45min gezappel hab ich dann allerdings aufgegeben. Auch der Live View Monitor der Sensordaten spuckt nichts aus, bleibt einfach leer.
Mit der 049B_r161 konnte ich das Gimbal innerhalb weniger Minuten ruhig bekommen.
Viele Grüße,
Stephan
Hmmm schon komisch das wuiz auch die gleichen probleme hat somit glaube ich eher an einen software fehler naja .... wollte das board schon kübeln aber viell wart ich noch auf die nächste version ! event. sind die board mit unterschiedlichen komponenten ausgeliefert worden wo sich ein paar einfach nicht vertragen mit den neuen fw versionen ??
aber viell wart ich noch auf die nächste version ! event. sind die board mit unterschiedlichen komponenten ausgeliefert worden wo sich ein paar einfach nicht vertragen mit den neuen fw versionen ??Zuerst einmal der Reihe nach
avrdude verfication Fehlermeldung
Die avrdude verfication Fehlermeldung dürfte ziemlich eindeutig darauf hinweisen, dass bei euren Boards die Codegröße maximal 28672 bytes beträgt (hex 0x7000 = 28672 ).
avrdude: verification error, first mismatch at byte 0x7000
0x08 != 0xff
avrdude: verification error; content mismatch
Nach meiner Meinung ist in euren Boards ein anderer Bootloader geflasht.
Damit wäre auch klar warum die neueren Versionen nicht geladen werden können, nur r203a funktioniert wieder, da Codegröße kleiner 28672 bytes.
avrdude verfication Fehlermeldung
Die avrdude verfication Fehlermeldung dürfte ziemlich eindeutig darauf hinweisen, dass bei euren Boards die Codegröße maximal 28672 bytes beträgt (hex 0x7000 = 28672 ).
avrdude: verification error, first mismatch at byte 0x7000
0x08 != 0xff
avrdude: verification error; content mismatch
Nach meiner Meinung ist in euren Boards ein anderer Bootloader geflasht.
Damit wäre auch klar warum die neueren Versionen nicht geladen werden können, nur r203a funktioniert wieder, da Codegröße kleiner 28672 bytes.
Hallo Stephan,
zwischen r161 und r20x hat es sehr viele Änderungen gegeben. Ich bin davon ausgegangen dass die PID Regelung nicht betroffen wäre.
Einige Leute haben jedoch berichtet, dass sich die Motorlaufrichtung bzw. die Motorzuordnung geändert hätte.
Das Problem ist aufgetreten wenn jemand die Sensoreonstellung "Swap-XY" verwendet. Dieser Bug wurde nach r161 ausgebessert.
Falls du "Swap-XY" aktiv hättest, dann solltest auf jeden Fall die Motorzuordnungen und Laufrichungen erneut nachprüfen.
Du hast geschrieben, dass LivevView nichts anzeigt.
Du kannst verbinden ? Statuszeile ist grün (Brugi INFO: BruGi Calibartion OK usw....)?
Steht links die Version Nummer? Firmware: BruGi r50 r203a
Live View Button aktivieren
links im "Settings" Tab sollte I2C Errors auf grün wecheseln und auch sinnvolle Werte anzeigen (0 errors, 21 Grad ...)
Kommst du soweit ?
Das ist Minimum und muß immer funktionieren..
lg
Alois
zwischen r161 und r20x hat es sehr viele Änderungen gegeben. Ich bin davon ausgegangen dass die PID Regelung nicht betroffen wäre.
Einige Leute haben jedoch berichtet, dass sich die Motorlaufrichtung bzw. die Motorzuordnung geändert hätte.
Das Problem ist aufgetreten wenn jemand die Sensoreonstellung "Swap-XY" verwendet. Dieser Bug wurde nach r161 ausgebessert.
Falls du "Swap-XY" aktiv hättest, dann solltest auf jeden Fall die Motorzuordnungen und Laufrichungen erneut nachprüfen.
Du hast geschrieben, dass LivevView nichts anzeigt.
Du kannst verbinden ? Statuszeile ist grün (Brugi INFO: BruGi Calibartion OK usw....)?
Steht links die Version Nummer? Firmware: BruGi r50 r203a
Live View Button aktivieren
links im "Settings" Tab sollte I2C Errors auf grün wecheseln und auch sinnvolle Werte anzeigen (0 errors, 21 Grad ...)
Kommst du soweit ?
Das ist Minimum und muß immer funktionieren..
lg
Alois
Mahlzeit!
Danke für die Erläuterung, Alois. Tatsächlich bin ich nicht soweit gekommen, werde heute Abend aber nochmal alles überprüfen.
Ich hatte mich teilweise selbst schon gewundert denn:
- Das Gimbal verbindet, Statuszeile ist grün, Kalibriert, etc..
- Versionsnummer stand NICHT da
- Live View Button drücken bewirkt nur, dass der Button selbst grün wird. Sonst passiert nichts.
Ich werde heute Abend nochmal auf die 203a flashen, und exakt schreiben was bei welcher Aktion passiert. Meiner Erinnerung nach konnte ich mit der 203a die LiveView bei einer älteren GUI (r49) erfolgreich aktivieren, bei der r50 20X ist nichts passiert, aber dazu später nochmal mehr, dann werde ich nochmal die aktuellen Einstellungen, Sensorachsen, etc. übernehmen und ggf. modifizieren.
Viele Grüße,
Stephan
Danke für die Erläuterung, Alois. Tatsächlich bin ich nicht soweit gekommen, werde heute Abend aber nochmal alles überprüfen.
Ich hatte mich teilweise selbst schon gewundert denn:
- Das Gimbal verbindet, Statuszeile ist grün, Kalibriert, etc..
- Versionsnummer stand NICHT da
- Live View Button drücken bewirkt nur, dass der Button selbst grün wird. Sonst passiert nichts.
Ich werde heute Abend nochmal auf die 203a flashen, und exakt schreiben was bei welcher Aktion passiert. Meiner Erinnerung nach konnte ich mit der 203a die LiveView bei einer älteren GUI (r49) erfolgreich aktivieren, bei der r50 20X ist nichts passiert, aber dazu später nochmal mehr, dann werde ich nochmal die aktuellen Einstellungen, Sensorachsen, etc. übernehmen und ggf. modifizieren.
Viele Grüße,
Stephan
Hallo Stephan,
auch Mahlzeit
Nimm immer die zur jeweilgen Version mitgepackte GUI, damit GUI und Firmware zusammenpassen.
Wenn die Versionsnummer nicht kommt und Live View nicht funktioniert, dann könnte es ein Hinweis sein dass am Board immer noch eine alte Version läuft. Die Anzeige der Versionsbezeichnung und Live View sind erst später hinzugekommen. Zumindest bei r161 gabs das noch nicht.
lg
Alois
auch Mahlzeit
Nimm immer die zur jeweilgen Version mitgepackte GUI, damit GUI und Firmware zusammenpassen.
Wenn die Versionsnummer nicht kommt und Live View nicht funktioniert, dann könnte es ein Hinweis sein dass am Board immer noch eine alte Version läuft. Die Anzeige der Versionsbezeichnung und Live View sind erst später hinzugekommen. Zumindest bei r161 gabs das noch nicht.
lg
Alois
Hallo Alois,
so, wenn man's drauf anlegt kommt natürlich wieder alles anders als erwartet - in meinem Fall jetzt jedoch positiv. Habe die r203a nochmal geflasht und siehe da, das GUI funktioniert einwandfrei, Motoren und Sensororientierung noch vertauscht, alles kein Problem ;-) Seltsam.. Die einzige für mich plausible Erklärung für das Phänomen der letzten Tage liegt darin, dass ich heute nach dem Aufspielen der Software das Gimbal vom Strom getrennt und wieder angeschlossen habe, bevor ich es mit dem Tool verbunden habe.
Getreu nach dem Motto: http://www.youtube.com/watch?v=p85xwZ_OLX0
Aber erstmal Danke für die Hilfe, hat schon was geholfen Bin dann mal weiter experimentieren, und hoffentlich bald mal mit dem Gimbal fliegen..
Grüße, Stephan
so, wenn man's drauf anlegt kommt natürlich wieder alles anders als erwartet - in meinem Fall jetzt jedoch positiv. Habe die r203a nochmal geflasht und siehe da, das GUI funktioniert einwandfrei, Motoren und Sensororientierung noch vertauscht, alles kein Problem ;-) Seltsam.. Die einzige für mich plausible Erklärung für das Phänomen der letzten Tage liegt darin, dass ich heute nach dem Aufspielen der Software das Gimbal vom Strom getrennt und wieder angeschlossen habe, bevor ich es mit dem Tool verbunden habe.
Getreu nach dem Motto: http://www.youtube.com/watch?v=p85xwZ_OLX0
Aber erstmal Danke für die Hilfe, hat schon was geholfen
Bin dann mal weiter experimentieren, und hoffentlich bald mal mit dem Gimbal fliegen..Grüße, Stephan
Hi,
ich melde mich nochmal, da jetzt mein Gimbal endlich am Copter hängt und morgen auf seinen Erstflug wartet (wenn das Wetter mitspielt)
Ich habe heute noch den Spannungsteiler eingelötet, funktioniert soweit schonmal super. Der LiPo war auch schon am Ende seiner Kapazität, weshalb der auch gleich mal bei 9,6V gegriffen hat. Dabei hat allerdings kurz vor dem endgültigen Abschalten das Gimbal angefangen verrückt zu spielen, da die Spannung immer zwischen 9,59V und 9,60V geschwankt hat --> Entsprechend hat das Gimbal ein- und ausgeschaltet.
Lässt sich das evtl durch einen softwareseitigen Lowpassfilter o.ä. vermeiden, ähnlich wie beim RC-Signal? Oder alternativ, wenn es einmal unter die Schwellenspannung geht, dann dauerhaft deaktiviert wird bis zum nächsten Reboot=voller Akku..
Ist halt nicht so schön wenn die Kamera beim Zappeln mit dem Objektiv am Gimbal anschlägt.
Bin auf's Flugergebnis gespannt!
Viele Grüße,
Stephan
ich melde mich nochmal, da jetzt mein Gimbal endlich am Copter hängt und morgen auf seinen Erstflug wartet (wenn das Wetter mitspielt)
Ich habe heute noch den Spannungsteiler eingelötet, funktioniert soweit schonmal super. Der LiPo war auch schon am Ende seiner Kapazität, weshalb der auch gleich mal bei 9,6V gegriffen hat. Dabei hat allerdings kurz vor dem endgültigen Abschalten das Gimbal angefangen verrückt zu spielen, da die Spannung immer zwischen 9,59V und 9,60V geschwankt hat --> Entsprechend hat das Gimbal ein- und ausgeschaltet.
Lässt sich das evtl durch einen softwareseitigen Lowpassfilter o.ä. vermeiden, ähnlich wie beim RC-Signal? Oder alternativ, wenn es einmal unter die Schwellenspannung geht, dann dauerhaft deaktiviert wird bis zum nächsten Reboot=voller Akku..
Ist halt nicht so schön wenn die Kamera beim Zappeln mit dem Objektiv am Gimbal anschlägt.
Bin auf's Flugergebnis gespannt!
Viele Grüße,
Stephan
- Status
