Brushless Gimbal Controller - SOFTWARE
- Themenstarter Lonestar78
- Beginndatum
- Status
eine Info zu den beobachten Abstürzen bei Softwareversionen nach v49 r161
Ich konnte ein bestimmtes Problem nachvollziehen.
Wenn die RC Eingänge stark gestört sind, kann die dadurch verursachet Interrupt Aktivität zum Absturz der Controller Software führen. Insbesondere Störungen von der Motorsteuerung sind böse, da sie mit 32kHz auftreten.
In dieser Version v50 r200 ist dieses Problem behoben.
http://code.google.com/p/brushless-gimbal/downloads/detail?name=BruGi_050_r200.zip&can=2
Das Problem konnte ich eindeutig nachvollziehen. Allerdings mußte ich dafür extrem starke Störungen erzeugen.
Ob es in der Praxis so starke Störungen gibt, kann ich nicht sagen.
Am schlechtesten sind offene RC Kabel oder nicht parallel geführte RC Kabel, also wenn Leitungen einzeln geführt werden.
Die stärkste Störquelle ist direkt am Motorgehäuse.
Am stärksten sind die Motorstörungen bei höheren Spannungen.
Somit könnte es eure boabachten Abstürze erkären.
Probiert die neue Version aus, und sagt mir ob die Probleme behoben sind.
Probleme mit gestörten I2C Signalen konnte ich nicht beobachten. Allerdings hat mein Sensor bereits 1k Pullups.
lg
Alois
Und jetzt gehts ab zum Punsch trinken
Ich konnte ein bestimmtes Problem nachvollziehen.
Wenn die RC Eingänge stark gestört sind, kann die dadurch verursachet Interrupt Aktivität zum Absturz der Controller Software führen. Insbesondere Störungen von der Motorsteuerung sind böse, da sie mit 32kHz auftreten.
In dieser Version v50 r200 ist dieses Problem behoben.
http://code.google.com/p/brushless-gimbal/downloads/detail?name=BruGi_050_r200.zip&can=2
Das Problem konnte ich eindeutig nachvollziehen. Allerdings mußte ich dafür extrem starke Störungen erzeugen.
Ob es in der Praxis so starke Störungen gibt, kann ich nicht sagen.
Am schlechtesten sind offene RC Kabel oder nicht parallel geführte RC Kabel, also wenn Leitungen einzeln geführt werden.
Die stärkste Störquelle ist direkt am Motorgehäuse.
Am stärksten sind die Motorstörungen bei höheren Spannungen.
Somit könnte es eure boabachten Abstürze erkären.
Probiert die neue Version aus, und sagt mir ob die Probleme behoben sind.
Probleme mit gestörten I2C Signalen konnte ich nicht beobachten. Allerdings hat mein Sensor bereits 1k Pullups.
lg
Alois
Und jetzt gehts ab zum Punsch trinken
Ja, die Codegröße ist leider am Anschlag.
Die nutzbare Codegröße ist vom jeweiligen Bootloader abhängig. Bei Martinez uns meinem RC Timer Board geht es sich noch aus.
Ich denke wir hatten das Thema schon einmal im Juni.
Wie knapp ist es bei dir?
Auf die schnelle könnte man einigw print im trace.ino auskommentieren.
Die nutzbare Codegröße ist vom jeweiligen Bootloader abhängig. Bei Martinez uns meinem RC Timer Board geht es sich noch aus.
Ich denke wir hatten das Thema schon einmal im Juni.
Wie knapp ist es bei dir?
Auf die schnelle könnte man einigw print im trace.ino auskommentieren.
@emerich
ich hab aus dem trace.ino ein paar (derzeit) nicht benutzte Trace Optionen herausgenommen.
Der Code ist damit um 720 bytes kleiner geworden, die Funktionalität ist unverändert.
Probier es einmal aus und sag mir ob es passt, dann gebe ich diese Version gleich auf den offiziellen Download Bereich.
https://www.dropbox.com/s/syyh8fern3bpvbh/BruGi_050_r203.zip
Welche Board Type verwendest du bzw. welches Board ist im Arduino eingestellt ?
lg
Alois
P.S.: hat es euch schon verschneit in Südtirol
ich hab aus dem trace.ino ein paar (derzeit) nicht benutzte Trace Optionen herausgenommen.
Der Code ist damit um 720 bytes kleiner geworden, die Funktionalität ist unverändert.
Probier es einmal aus und sag mir ob es passt, dann gebe ich diese Version gleich auf den offiziellen Download Bereich.
https://www.dropbox.com/s/syyh8fern3bpvbh/BruGi_050_r203.zip
Welche Board Type verwendest du bzw. welches Board ist im Arduino eingestellt ?
lg
Alois
P.S.: hat es euch schon verschneit in Südtirol
hallo Alois
r203 gibt bei mir immer noch den gleichen fehler
"avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64"
"avrdude: stk500_cmd(): programmer is out of sync"
benütze HW: martinez V3 Clone aus Asien mit ATMEGA328p
Board: Arduino UNO (funktioniert nur so)
p.s. hier 70cm Neuschnee, Strassen u. Stromversorgung wieder hergerichtet
r203 gibt bei mir immer noch den gleichen fehler
"avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x64"
"avrdude: stk500_cmd(): programmer is out of sync"
benütze HW: martinez V3 Clone aus Asien mit ATMEGA328p
Board: Arduino UNO (funktioniert nur so)
p.s. hier 70cm Neuschnee, Strassen u. Stromversorgung wieder hergerichtet
Hallo Emerich,
könnte es sein, dass es nicht an der Codegröße liegt, sondern dass es sich um ein anderes Problem handelt ?
Aber wenn r171 funktioniert, dann liegts ziemlich sicher an der Codegröße.
Ich verwende derzeit Arduino 1.5.4, diese schreibt die verfügbare Speichergröße raus, z.B.:
Sketch uses 29,512 bytes (96%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,319 bytes (64%) of dynamic memory, leaving 729 bytes for local variables. Maximum is 2,048 bytes.
Mit welcher Einstellung (Board/Prozessor) hast du die r171 geladen? bzw. kannst mir sagen, welche maximale Größe dort angebeben wird.
Es wäre wichtig zu wissen wo die Grenze liegt.
Es geistern anscheinend verschiedene Bootloader herum
Ich kann mich leider nicht mehr genau erinneren, es gab hier schon einen Post zu den genauen Bootloadergrössen der diversen Boards.
Alois
P.S.: da hats euch kräftig erwischt, hier im Osten, derzeit bin ich im Walviertel N.Ö. auf 900m, sind nur mehr Schneereste vorhanden ..
könnte es sein, dass es nicht an der Codegröße liegt, sondern dass es sich um ein anderes Problem handelt ?
Aber wenn r171 funktioniert, dann liegts ziemlich sicher an der Codegröße.
Ich verwende derzeit Arduino 1.5.4, diese schreibt die verfügbare Speichergröße raus, z.B.:
Sketch uses 29,512 bytes (96%) of program storage space. Maximum is 30,720 bytes.
Global variables use 1,319 bytes (64%) of dynamic memory, leaving 729 bytes for local variables. Maximum is 2,048 bytes.
Mit welcher Einstellung (Board/Prozessor) hast du die r171 geladen? bzw. kannst mir sagen, welche maximale Größe dort angebeben wird.
Es wäre wichtig zu wissen wo die Grenze liegt.
Es geistern anscheinend verschiedene Bootloader herum
Ich kann mich leider nicht mehr genau erinneren, es gab hier schon einen Post zu den genauen Bootloadergrössen der diversen Boards.
Alois
P.S.: da hats euch kräftig erwischt, hier im Osten, derzeit bin ich im Walviertel N.Ö. auf 900m, sind nur mehr Schneereste vorhanden ..
Ja, es war bereits im Juni.
OlliW hat hier dankenswerterweise einen Hinweis gepostet.
http://fpv-community.de/showthread....oller-SOFTWARE&p=373646&viewfull=1#post373646
Arduino Bootloaders
https://github.com/arduino/Arduino/blob/master/hardware/arduino/boards.txt
So am ersten Blick ist die verfügbare Codegröße, je nach Bootloader
bei Arduino Uno: 32256 bytes
bei Arduino Pro or Pro Mini: 30720 bytes
bei Arduino Mini w/ ATmega328: 28672 bytes.
Möglichweise hat dein Board nur 28672 bytes verfügbar.
d.h. man müsste unter diesen Wert kommen.
Ich sehe Mal was sich machen lässt. Mühsam ernährt sich das Eichhörnchen
lg
Alois
uno.name=Arduino Uno
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.speed=115200
pro328.name=Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328
pro328.upload.protocol=arduino
pro328.upload.maximum_size=30720
pro328.upload.speed=57600
mini328.name=Arduino Mini w/ ATmega328
mini328.upload.protocol=arduino
mini328.upload.maximum_size=28672
mini328.upload.speed=115200
bt328.name=Arduino BT w/ ATmega328
bt328.upload.protocol=arduino
bt328.upload.maximum_size=28672
OlliW hat hier dankenswerterweise einen Hinweis gepostet.
http://fpv-community.de/showthread....oller-SOFTWARE&p=373646&viewfull=1#post373646
Arduino Bootloaders
https://github.com/arduino/Arduino/blob/master/hardware/arduino/boards.txt
So am ersten Blick ist die verfügbare Codegröße, je nach Bootloader
bei Arduino Uno: 32256 bytes
bei Arduino Pro or Pro Mini: 30720 bytes
bei Arduino Mini w/ ATmega328: 28672 bytes.
Möglichweise hat dein Board nur 28672 bytes verfügbar.
d.h. man müsste unter diesen Wert kommen.
Ich sehe Mal was sich machen lässt. Mühsam ernährt sich das Eichhörnchen
lg
Alois
uno.name=Arduino Uno
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.speed=115200
pro328.name=Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ ATmega328
pro328.upload.protocol=arduino
pro328.upload.maximum_size=30720
pro328.upload.speed=57600
mini328.name=Arduino Mini w/ ATmega328
mini328.upload.protocol=arduino
mini328.upload.maximum_size=28672
mini328.upload.speed=115200
bt328.name=Arduino BT w/ ATmega328
bt328.upload.protocol=arduino
bt328.upload.maximum_size=28672
@Emerich
probier es mit dieser Version
https://www.dropbox.com/s/1trem41yqb82z86/BruGi_050_r203a.zip
mit 28,576 bytes sollte sie auch in Arduino Mini w/ ATmega328 & Co mit 28672 bytes Platz finden.
Sketch uses 28,576 bytes (88%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,297 bytes (63%) of dynamic memory, leaving 751 bytes for local variables. Maximum is 2,048 bytes.
lg
Alois
probier es mit dieser Version
https://www.dropbox.com/s/1trem41yqb82z86/BruGi_050_r203a.zip
mit 28,576 bytes sollte sie auch in Arduino Mini w/ ATmega328 & Co mit 28672 bytes Platz finden.
Sketch uses 28,576 bytes (88%) of program storage space. Maximum is 32,256 bytes.
Global variables use 1,297 bytes (63%) of dynamic memory, leaving 751 bytes for local variables. Maximum is 2,048 bytes.
lg
Alois
Hi zusammen!
Wie Funktioniert das mit der Externen Ansteuerung? Bin eigentlich schon froh mein Gimbal nach etlichen nächten des Rumspielen mit den PID Werten zum Laufen gebracht zu haben.
Jetzt möchte ich aber gernen über einen Freien Kanal das Gimbal in der Rollachse per Funke nach unten Schwenkbar machen.
Habe das vorher als mein Gimbal noch herkömmlich mit Servos war über meine FC gemacht ein Plejad Merope Board.
Da ja das BL Gimbal nicht mehr direkt vom Board angesteuert wird weiss ich nicht wie das geht. Muss ich vom Empfänger direkt
ein Kabel an den Controller legen oder kann ich das weiterhin über meine FC Bewerkstelligen? Wenn ja, genügt es die Signalleitung zu nehmen oder muss ich ein komplettes Servokabel benutzen? Über die FC wäre mir das persönlich lieber weil ich sonst am Sumsiboard beim Emfpänger was verändern müsste und die FC schon eingestellt ist für das Schwenken?
Wie Funktioniert das mit der Externen Ansteuerung? Bin eigentlich schon froh mein Gimbal nach etlichen nächten des Rumspielen mit den PID Werten zum Laufen gebracht zu haben.
Jetzt möchte ich aber gernen über einen Freien Kanal das Gimbal in der Rollachse per Funke nach unten Schwenkbar machen.
Habe das vorher als mein Gimbal noch herkömmlich mit Servos war über meine FC gemacht ein Plejad Merope Board.
Da ja das BL Gimbal nicht mehr direkt vom Board angesteuert wird weiss ich nicht wie das geht. Muss ich vom Empfänger direkt
ein Kabel an den Controller legen oder kann ich das weiterhin über meine FC Bewerkstelligen? Wenn ja, genügt es die Signalleitung zu nehmen oder muss ich ein komplettes Servokabel benutzen? Über die FC wäre mir das persönlich lieber weil ich sonst am Sumsiboard beim Emfpänger was verändern müsste und die FC schon eingestellt ist für das Schwenken?
Hallo Spookymike
Solange du beides (FC und BGC) über einen LiPo versorgst, also GND bei beiden gleich ist, reicht es wenn du das PWM Signal (Orange) des Servoausgangs zum dem BGC führst.
Wie bekommt man es den in den Griff, dass der Winkel des Gimbals der Stellung meines Potis am Sender 1zu1 folgt?
Egal welche Eistellung ich wähle, irgendwie folgt der Gimbal den Analogwert nie direkt.
@ahahn
habe bis jetzt mit arduino 1.0.5 geladen, r171 hatte 24.876 bytes (immer arduino uno)
heute habe ich r203a mit arduino 1.5.5beta geladen und es ging, (r202 und r203) waren auch damit zu gross,
das gimbal habe ich noch nicht ganz mit r203a zum gehen gebracht, viele abstuerze der software bei falschen pids und Einstellungen.
Probiere aber noch weiter und berichte Dir dann.
Hoffe es hilft weiter zu programmieren, das ist ein schoenes Projekt
lg emerich
habe bis jetzt mit arduino 1.0.5 geladen, r171 hatte 24.876 bytes (immer arduino uno)
heute habe ich r203a mit arduino 1.5.5beta geladen und es ging, (r202 und r203) waren auch damit zu gross,
das gimbal habe ich noch nicht ganz mit r203a zum gehen gebracht, viele abstuerze der software bei falschen pids und Einstellungen.
Probiere aber noch weiter und berichte Dir dann.
Hoffe es hilft weiter zu programmieren, das ist ein schoenes Projekt
lg emerich
Ich bekomme das mit der Externen Ansteuerung von "Pitch" nicht hin :-(
Habe an der 3-Pin Stiftleiste für Extern Pitch auf meinem Board ein 2-Adriges Servokabel angesteckt. Signal und Ground!
Dort habe ich einen Gebundenen Externen Emfpänger angesteckt mit dem ich versuche das Gimbal zu schwenken!
Aber da Schwenkt nichts. Wäre ja schon froh, wenn die Falsche Achse Schwenken würde aber es tut sich nichts.
Ich habe auf dem Board die BruGi_049B_r161 Firmware drauf. Das Board ist folgendes
--> http://www.ebay.de/itm/271244578610?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
Da dieses Gebiet für mich absolutes Neuland ist und ich mich auch mit dem Arduino Software Zeugs nicht so super auskenne
stehe ich auf dem Schlauch.
Habe mal in der Definitions.h nachgeschaut und finde dort den Punkt
// RC Pins
nicht von dem etliche Beiträge weiter oben die Rede ist!
Kann es sein, daß dieser "Befehl" in der Verwendeten FW 049 fälschlicherweise vergessen wurde?
Oder heisst der in der 049 nur anders?
Habe mal die 046.INO geöffnet. Da ist der "Befehl" vorhanden.
Habe an der 3-Pin Stiftleiste für Extern Pitch auf meinem Board ein 2-Adriges Servokabel angesteckt. Signal und Ground!
Dort habe ich einen Gebundenen Externen Emfpänger angesteckt mit dem ich versuche das Gimbal zu schwenken!
Aber da Schwenkt nichts. Wäre ja schon froh, wenn die Falsche Achse Schwenken würde aber es tut sich nichts.
Ich habe auf dem Board die BruGi_049B_r161 Firmware drauf. Das Board ist folgendes
--> http://www.ebay.de/itm/271244578610?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
Da dieses Gebiet für mich absolutes Neuland ist und ich mich auch mit dem Arduino Software Zeugs nicht so super auskenne
stehe ich auf dem Schlauch.
Habe mal in der Definitions.h nachgeschaut und finde dort den Punkt
// RC Pins
nicht von dem etliche Beiträge weiter oben die Rede ist!
Kann es sein, daß dieser "Befehl" in der Verwendeten FW 049 fälschlicherweise vergessen wurde?
Oder heisst der in der 049 nur anders?
Habe mal die 046.INO geöffnet. Da ist der "Befehl" vorhanden.
Gegenüber 46 hat sich schon sehr viel geändert.
Normalerweise solltest du alles in der GUI einstellen können, Änderungen in der definitions.h sind kaum notwendig.
Die Auswahl des RC Kanals erfolgt im Pitch bzw. Roll Tab. Dort gibt es das Feld "RC Channel", damit kannst den PWM Eingang für die RC Steuerung festlegen, 1, 2 oder 3 (Eingänge A2, A1, A0). Bei einem Martinez Board sollte entweder 1 oder 2 richtig sein.
lg
Alois
Normalerweise solltest du alles in der GUI einstellen können, Änderungen in der definitions.h sind kaum notwendig.
Die Auswahl des RC Kanals erfolgt im Pitch bzw. Roll Tab. Dort gibt es das Feld "RC Channel", damit kannst den PWM Eingang für die RC Steuerung festlegen, 1, 2 oder 3 (Eingänge A2, A1, A0). Bei einem Martinez Board sollte entweder 1 oder 2 richtig sein.
lg
Alois
Yo Supi! THX ahan!
Bei mir war es die Einstellung "3".
Jetzt funktiniert es. Habe allerdings das gleiche "Problem" wie "Fat Tony" weiter oben. Egal was ich drehe, das Gimbal
folgt dem Poti der Funke nur extrem langsam!
BTW. Ich bin echt froh daß ich das Gimbal soweit zum Funktionieren gebracht habe allerdings bin ich noch nicht 100% damit zufrieden.
Komme mit den PID/PWM Einstellungen nicht so ganz klar!
Ich habe eine niedrige PWM und etwas höhere PID Werte eingestellt und das Gimbal hält soweit. Allerdings bricht es noch hin
und wieder weg.
Ausserdem habe ich das Gefühl daß es im Flug nicht so ganz exakt seine Ausrichtung behält.
In Folgendem Video von Heute sind diverse "Wackler" oder "Schwingungen" zu sehen. Ich kann nicht sagen ob es von
der Gimbal Kontrolle oder von der "Gummidämpfung" her rührt. Vieleicht hat ja einer mit Mehr Einstellerfahrung einen
Geistesblitz wo ich da ansetzen kann:
[video=youtube;LEs7RtB2Y2w]http://www.youtube.com/watch?v=LEs7RtB2Y2w&feature=youtu.be[/video]
Einige Beiträge weiter oben habe ich gesehen, daß es leute gibt, die Relativ hohe PWM und relativ Niedrige PID Werte
eingestellt haben und nun frage ich mich was wohl besser ist.
Hatte beim Einstellen der Gimbalwerte vorher schon einiges an Zeit gebraucht bis ich es so wie es jetzt ist halbwegs hinbekommen
habe.
Bei mir war es die Einstellung "3".
Jetzt funktiniert es. Habe allerdings das gleiche "Problem" wie "Fat Tony" weiter oben. Egal was ich drehe, das Gimbal
folgt dem Poti der Funke nur extrem langsam!
BTW. Ich bin echt froh daß ich das Gimbal soweit zum Funktionieren gebracht habe allerdings bin ich noch nicht 100% damit zufrieden.
Komme mit den PID/PWM Einstellungen nicht so ganz klar!
Ich habe eine niedrige PWM und etwas höhere PID Werte eingestellt und das Gimbal hält soweit. Allerdings bricht es noch hin
und wieder weg.
Ausserdem habe ich das Gefühl daß es im Flug nicht so ganz exakt seine Ausrichtung behält.
In Folgendem Video von Heute sind diverse "Wackler" oder "Schwingungen" zu sehen. Ich kann nicht sagen ob es von
der Gimbal Kontrolle oder von der "Gummidämpfung" her rührt. Vieleicht hat ja einer mit Mehr Einstellerfahrung einen
Geistesblitz wo ich da ansetzen kann:
[video=youtube;LEs7RtB2Y2w]http://www.youtube.com/watch?v=LEs7RtB2Y2w&feature=youtu.be[/video]
Einige Beiträge weiter oben habe ich gesehen, daß es leute gibt, die Relativ hohe PWM und relativ Niedrige PID Werte
eingestellt haben und nun frage ich mich was wohl besser ist.
Hatte beim Einstellen der Gimbalwerte vorher schon einiges an Zeit gebraucht bis ich es so wie es jetzt ist halbwegs hinbekommen
habe.
Hallo emerich,
Ok, mit der Codegröße haben wir richtig vermutet, da dürfte tatsächlich ein anderer Bootloader drinnen sein.
bezgl Abstürze: Ist da der Prozessor komplett tot und du kommst nur mit Neustart raus?
Egal, was in der GUI eingestellt ist, ein Absturz sollte nicht vorkommen.
Es gibt anscheinend immer wieder Probleme damit.
Passieren die Abstüze auch ohne angesteckte Motore ?
Verwendest du ein kleines GoPro Gimbal oder etwas größeres ?
Softwaretechnisch sehe ich keine plausible Ursache, die RC Eingänge sollten keine Probleme mehr machen.
Versuchweise kann man ja alle 3 Eingänge im Aux Tab einmal deaktivieren.
I2C Fehler, also Einstreuungen der Motoren auf die Signalleitungen kommen eventuell in Frage.
I2C Fehler sollte man mit Live View sehen können.
Ansonsten habe ich noch einen weiteren Verdacht.
Nach meinen Beobachtungen häufen sich der Abstürze bei Martinez Boards und Nachbauten.
Immer mit angesteckten Motoren und höheren Spannungen (3S/4S)
Mit meinem RC-Timer Board hatte ich noch nie Probleme dieser Art.
Wäre interessant, ob die Problem bei bestimmten Boards gehäuft auftreten ?
bzw. ob das Problem mit größeren Gimbals (nicht GoPro .o.ä.) häufiger vorkommt ?
lg
Alois
Ok, mit der Codegröße haben wir richtig vermutet, da dürfte tatsächlich ein anderer Bootloader drinnen sein.
bezgl Abstürze: Ist da der Prozessor komplett tot und du kommst nur mit Neustart raus?
Egal, was in der GUI eingestellt ist, ein Absturz sollte nicht vorkommen.
Es gibt anscheinend immer wieder Probleme damit.
Passieren die Abstüze auch ohne angesteckte Motore ?
Verwendest du ein kleines GoPro Gimbal oder etwas größeres ?
Softwaretechnisch sehe ich keine plausible Ursache, die RC Eingänge sollten keine Probleme mehr machen.
Versuchweise kann man ja alle 3 Eingänge im Aux Tab einmal deaktivieren.
I2C Fehler, also Einstreuungen der Motoren auf die Signalleitungen kommen eventuell in Frage.
I2C Fehler sollte man mit Live View sehen können.
Ansonsten habe ich noch einen weiteren Verdacht.
Nach meinen Beobachtungen häufen sich der Abstürze bei Martinez Boards und Nachbauten.
Immer mit angesteckten Motoren und höheren Spannungen (3S/4S)
Mit meinem RC-Timer Board hatte ich noch nie Probleme dieser Art.
Wäre interessant, ob die Problem bei bestimmten Boards gehäuft auftreten ?
bzw. ob das Problem mit größeren Gimbals (nicht GoPro .o.ä.) häufiger vorkommt ?
lg
Alois
Zuletzt bearbeitet:
Hallo Alois,
das mit der Spannung war der richtige Tip, vielen Dank
speise jetzt den Board durch mein variables Spannungsregler mit 9.0V ein (Motorenleistung ein bisschen erhöht), und es funktioniert tadellos, kein Abstürze mehr; 12.1V waren zu viel.
Habe ein grösseres Carbon Gimbal mit einer Pentax S1, Arduino IR Shutter und Pich Schwänkung über ppm (parallel zum MWii Board), durch Ausfilterung vom Kanal 7.
Kann nur an alle raten mit der Einspeisespannung runter zu gehen.
P.S. ACC Calibrierung gibt mir auf der GUI failed an; ansonsten funktioniert R203a von mir aus gut
Ein Danke schön an ahahn
Emerich
das mit der Spannung war der richtige Tip, vielen Dank
speise jetzt den Board durch mein variables Spannungsregler mit 9.0V ein (Motorenleistung ein bisschen erhöht), und es funktioniert tadellos, kein Abstürze mehr; 12.1V waren zu viel.
Habe ein grösseres Carbon Gimbal mit einer Pentax S1, Arduino IR Shutter und Pich Schwänkung über ppm (parallel zum MWii Board), durch Ausfilterung vom Kanal 7.
Kann nur an alle raten mit der Einspeisespannung runter zu gehen.
P.S. ACC Calibrierung gibt mir auf der GUI failed an; ansonsten funktioniert R203a von mir aus gut
Ein Danke schön an ahahn
Emerich
- Status
