ESC Flashen für Brushless Gimbal Motoren
- Themenstarter OlliW
- Beginndatum
- Status
Hallo Christoph,
nun zu dir.
Du hast es völlig richtig erkannt (und den entsprechenden Post irgendwo vorne richtig verstanden) das nicht nur die Pins passen müssen sondern auch die Schaltzeiten, d.h. die aktuelle Blueseries-Firmware ist NUR für die all N-Fet Blueseries ESC. Bei den P/N-FET Varianten würde ich, wie bei den anderen bisher getesten P/N-FET ESCs auch, signifikante Schaltzeiten erwarten, und mit der aktuellen Blueseries-Firmware eine große Gefahr eines Schadens an den FETs. Also, gut mitgedacht!
Hier sind einige Quirks versteckt. (1) Es gibt viele verschieden Bootloader, bzw. Bootloader ist nicht gleich Bootloader, d.h. man muss dazu sagen von welchem Bootloader man redet.
(2) Der Bootloader hat a priory nichts damit zu tun welche Firmware draufgespielt wird, d.h. welcher Bootloader auch immer verwendet wird, du kannst jede beliebige Firmware drauf spielen. ACHTUNG: es mag einzelne exotische Ausnahmen geben, wenn z.B. der Bootloader gewisse Bedingungen an die Firmware stellt.
Also, du meinst vermutlich den Bootloader der beim SimonK-Projekt üblicherweise verwendet wird. Er sollte eigentlich funktionieren, aber bei dem speziell kann es tatsächlich auch sein das er einer der "Exoten" ist... ich weis das nicht genau, aber ich habe nur mal irgendwo gesehen dass verschiedene"komische" Mechanismen eingebaut sind, und generell ist das ein sehr rudimentärer Bootloader. Mein persönlicher Favorit ist Hagen's Bootloader, weil der viele colle Möglichkeiten hat und dabei auch noch sehr klein ist (512b reichen). Mit dem kannst du auch noch das EEprom anzapfen. Übrigens: Das häufigste Problem mit Bootloadern ist, dass die Fuses nicht richtig gesetzt sind!
Eine Bemrkung zu deinen Tests. Bei den HK6a/Blueseries20A Firmwares ist Vmax (entspricht im wesentlichen dem PWMmax beim Brugi) auf 160 eingestellt, das Maximum ist 240, d.h. es wird nur 67% der Leistung durchgelassen (habe ich als Schutz so gemacht). Das kann man per serieller Kommunikation aber ändern.
Bei den Bemerkungen zur Stromaufnahme und Rasten war mir nicht ganz klar ob das im Vergleich zum Verhalten beim BruGi gemeint ist, oder unabhängig. Also, Frage bitte, scheint dir die Kraft beim CF2822 120 Wicklungen im Vergleich zu dem was du beim BruGi beobachtest geringer, und genauso scheint dir das Rasten im Vergleich zum Betrieb mit dem BruGi stärker?
(ein Vergleich macht nur Sinn wenn Vmax/maxPWM ähnlich sind)
Cheers,
Olli
nun zu dir.
Du hast es völlig richtig erkannt (und den entsprechenden Post irgendwo vorne richtig verstanden) das nicht nur die Pins passen müssen sondern auch die Schaltzeiten, d.h. die aktuelle Blueseries-Firmware ist NUR für die all N-Fet Blueseries ESC. Bei den P/N-FET Varianten würde ich, wie bei den anderen bisher getesten P/N-FET ESCs auch, signifikante Schaltzeiten erwarten, und mit der aktuellen Blueseries-Firmware eine große Gefahr eines Schadens an den FETs. Also, gut mitgedacht!
Hier sind einige Quirks versteckt. (1) Es gibt viele verschieden Bootloader, bzw. Bootloader ist nicht gleich Bootloader, d.h. man muss dazu sagen von welchem Bootloader man redet.
(2) Der Bootloader hat a priory nichts damit zu tun welche Firmware draufgespielt wird, d.h. welcher Bootloader auch immer verwendet wird, du kannst jede beliebige Firmware drauf spielen. ACHTUNG: es mag einzelne exotische Ausnahmen geben, wenn z.B. der Bootloader gewisse Bedingungen an die Firmware stellt.
Also, du meinst vermutlich den Bootloader der beim SimonK-Projekt üblicherweise verwendet wird. Er sollte eigentlich funktionieren, aber bei dem speziell kann es tatsächlich auch sein das er einer der "Exoten" ist... ich weis das nicht genau, aber ich habe nur mal irgendwo gesehen dass verschiedene"komische" Mechanismen eingebaut sind, und generell ist das ein sehr rudimentärer Bootloader. Mein persönlicher Favorit ist Hagen's Bootloader, weil der viele colle Möglichkeiten hat und dabei auch noch sehr klein ist (512b reichen). Mit dem kannst du auch noch das EEprom anzapfen. Übrigens: Das häufigste Problem mit Bootloadern ist, dass die Fuses nicht richtig gesetzt sind!
Eine Bemrkung zu deinen Tests. Bei den HK6a/Blueseries20A Firmwares ist Vmax (entspricht im wesentlichen dem PWMmax beim Brugi) auf 160 eingestellt, das Maximum ist 240, d.h. es wird nur 67% der Leistung durchgelassen (habe ich als Schutz so gemacht). Das kann man per serieller Kommunikation aber ändern.
Bei den Bemerkungen zur Stromaufnahme und Rasten war mir nicht ganz klar ob das im Vergleich zum Verhalten beim BruGi gemeint ist, oder unabhängig. Also, Frage bitte, scheint dir die Kraft beim CF2822 120 Wicklungen im Vergleich zu dem was du beim BruGi beobachtest geringer, und genauso scheint dir das Rasten im Vergleich zum Betrieb mit dem BruGi stärker?
(ein Vergleich macht nur Sinn wenn Vmax/maxPWM ähnlich sind)
Cheers,
Olli
Hallo Olli,
leider kann ich zu dem Projekt nichts produktives beitragen, denn meine Programmierkenntnisse reichen nur für Basic. Diese reichen aber aus, um die Problematik beim programmieren zu verstehen.
Zuerst zum Bootloader, ich kenne jetzt nur den, der bei SimonK mitgeflasht wird und er funktioniert auch. Da dachte ich einfach, machste den mit dem ESCLight mit drauf und kann den Regler dann einfach immer wieder umflashen. Hat leider nicht funktioniert-> Zielsystem antwortet nicht. Da der Bootloader ja nur beim Booten aktiv ist muß ja irgendwie ein Reset ausgelöst werden. Ich gehe mal davon aus, daß diese Routine in der eigentlichen Firmware drin ist.
Nun zum Rastmoment. Das war eine allgemeine Feststellung. Ich selber habe kein BruGi, habe aber einem Bekannten geholfen seines in Betrieb zu nehmen. Er hat da recht große, fertig gewickelte Motoren gekauft die ein ähnliches Rastmoment haben. Dort ist es genauso. Man spürt ein deutliches Vibrieren beim Laufen, entsprechend der Rasterung. Vielleicht ist das ja normal, nur stelle ich mir vor, daß sich das auch auf die Kamera auswirkt. Ich habe da folgendes Video im Hinterkopf:
http://fpv-community.de/showthread.php?24620-Offizieller-Thread-Brushless-Gimbal-Controller-f%FCr-3-Achsen&p=329761&viewfull=1#post329761
Viele Grüße
Christoph
leider kann ich zu dem Projekt nichts produktives beitragen, denn meine Programmierkenntnisse reichen nur für Basic. Diese reichen aber aus, um die Problematik beim programmieren zu verstehen.
Zuerst zum Bootloader, ich kenne jetzt nur den, der bei SimonK mitgeflasht wird und er funktioniert auch. Da dachte ich einfach, machste den mit dem ESCLight mit drauf und kann den Regler dann einfach immer wieder umflashen. Hat leider nicht funktioniert-> Zielsystem antwortet nicht. Da der Bootloader ja nur beim Booten aktiv ist muß ja irgendwie ein Reset ausgelöst werden. Ich gehe mal davon aus, daß diese Routine in der eigentlichen Firmware drin ist.
Nun zum Rastmoment. Das war eine allgemeine Feststellung. Ich selber habe kein BruGi, habe aber einem Bekannten geholfen seines in Betrieb zu nehmen. Er hat da recht große, fertig gewickelte Motoren gekauft die ein ähnliches Rastmoment haben. Dort ist es genauso. Man spürt ein deutliches Vibrieren beim Laufen, entsprechend der Rasterung. Vielleicht ist das ja normal, nur stelle ich mir vor, daß sich das auch auf die Kamera auswirkt. Ich habe da folgendes Video im Hinterkopf:
http://fpv-community.de/showthread.php?24620-Offizieller-Thread-Brushless-Gimbal-Controller-f%FCr-3-Achsen&p=329761&viewfull=1#post329761
Viele Grüße
Christoph
richtig, ich meine zu wissen das die SimonK Firmware erkennt wenn ein "falsches" PWM Signal anliegt und dann in den Bootloader springt
die Reset-Problematik hat man aber bei jedem Bootloader, und normalerweise wird das so gelöst dass es ein gewisses Zeitfenster gibt... d.h. man startet das (PC-) Program mit welchem die Hex geflasht wird (ist denke beim SimonK-Bootloader ist das avrdude), und schaltet dann die ESC an (und beim anschaltet hat man dann den gewünschten Reset)... würde mich sehr wundern wenn das beim SimonK Bootloader nicht auch geht (aber wissen tu ich's natürlich nicht)
ah, OK (dann bin ich ja erleichtert LOL). Das mit dem Rasten macht mir im Moment auch am Meisten sorgen... leider gibt es gar keine vernünftigen Infos dazu wie das bei den "normalen" (z.B. GoPro tauglichen) BLG Motoren ist, vernünftig in dem Sinn dass man es "objektiv" einschätzen könnte... müsste ich mir eigentlich mal einen kaufen... bin ich aber zu geizig zu...
die Reset-Problematik hat man aber bei jedem Bootloader, und normalerweise wird das so gelöst dass es ein gewisses Zeitfenster gibt... d.h. man startet das (PC-) Program mit welchem die Hex geflasht wird (ist denke beim SimonK-Bootloader ist das avrdude), und schaltet dann die ESC an (und beim anschaltet hat man dann den gewünschten Reset)... würde mich sehr wundern wenn das beim SimonK Bootloader nicht auch geht (aber wissen tu ich's natürlich nicht)
ah, OK (dann bin ich ja erleichtert LOL). Das mit dem Rasten macht mir im Moment auch am Meisten sorgen... leider gibt es gar keine vernünftigen Infos dazu wie das bei den "normalen" (z.B. GoPro tauglichen) BLG Motoren ist, vernünftig in dem Sinn dass man es "objektiv" einschätzen könnte... müsste ich mir eigentlich mal einen kaufen... bin ich aber zu geizig zu...
Gerade mal im SimonK Code geschaut, meine Assembler Kenntnisse sind aber leider nicht weit her....
Kann einer genau sagen was er da macht, dann könnt ich das evtl im ESCLight Code auch machen.
Denke er schaut ob der Input Pin lange genug High ist und resetet dann?
Code:
.equ BOOT_LOADER = 1 ; Include Turnigy USB linker STK500v2 boot loader on PWM input pin
.equ BOOT_JUMP = 1 ; Jump to any boot loader when PWM input stays high
.equ BOOT_START = THIRDBOOTSTART
;-----bko-----------------------------------------------------------------
.if BOOT_JUMP
boot_loader_test:
.if USE_ICP
sbis PINB, rcp_in ; Skip clear if ICP pin high
.elif USE_INT0 == 1
sbis PIND, rcp_in ; Skip clear if INT0 pin high
.else
sbic PIND, rcp_in ; Skip clear if INT0 pin low (inverted)
.endif
sts rct_boot, ZH ; Clear rct_count when low
lds temp1, rct_boot
sbrs temp1, 5 ; Wait 32 * 16 * 65536us (~2s) before jumping
boot_ret: ret
; Check for boot loader presence
ldi ZL, low(BOOT_START << 1)
cli ; Interrupts depend on ZH being 0
ldi ZH, high(BOOT_START << 1)
lpm temp1, Z+
lpm temp2, Z
ldi ZH, 0
sei
adiw temp1, 1 ; Check flash contents for 0xffff or 0x0000
sbiw temp1, 2
brcs boot_ret ; Return if boot loader area is empty
boot_loader_jump:
cli
out DDRB, ZH ; Tristate pins
out DDRC, ZH
out DDRD, ZH
ldi temp1, (1<<WDCE)+(1<<WDE)
out WDTCR, temp1
out WDTCR, ZH ; Disable watchdog
lds temp1, orig_osccal
out OSCCAL, temp1 ; Restore OSCCAL
rjmp BOOT_START ; Jump to boot loader
.endif
;-----bko-----------------------------------------------------------------Denke er schaut ob der Input Pin lange genug High ist und resetet dann?
ich denke der "Trick" steckt in der Firmware, nicht so sehr im Bootlader
EDIT: ich Id*ot, das ist ja ein Stück aus der Firmware... LOL... ich bin auch kein ASM Crack, werde mal versuchen das in C zu "übersetzten"...
nimm doch einfach einen der vielen anderen Bootloader, z.B. nen Arduino Bootloader (die neuen sind auch nur 512b wenn ich mich nicht täusche), oder denn von Hagen Re!
(hab ich nie kapiert warum alle in der MC Welt so "scharf" auf SimonK's BL sind... ist ne Krücke, Vorteil war mal dass man den USB-Linker nehmen konnte, der mal billig erschien, aber mittlerweile ist das anders, ein USB-Linker ist teurer als z.B. der FTDI den man für den Arduino o. Hagens BL braucht... und Viele werden eh schon einen FTDI rumliegen haben... warum bei Krücken bleiben).
EDITII:
- er schaut erst ob der RC-Input Pin (z.B. Int0) für 2s auf High bleibt, dazu wird ein Zähler (rct_boot) benutzt, falls in der Zeit der Eingang Null wird, wird rückgesprungen (irgendwo wird es evtl noch ne Timer-ISR geben die dazugehört)
- er überprüft dann (tricky!) ob die ersten zwei Bytes in der Bootloader-Sektion <> 0000 oder FFFF ist, wenn ja gehts zurück, wenn nein werden alle Pins auf Eingang geschaltet, der Watchdog beruhight, und der alte Wert von OSCCAL zurückgeschrieben (der wurde verändert um auch mit internen RC Oszi näher an 16MHz zu kommen), und dann gehts zum BL
EDIT: ich Id*ot, das ist ja ein Stück aus der Firmware... LOL... ich bin auch kein ASM Crack, werde mal versuchen das in C zu "übersetzten"...
nimm doch einfach einen der vielen anderen Bootloader, z.B. nen Arduino Bootloader (die neuen sind auch nur 512b wenn ich mich nicht täusche), oder denn von Hagen Re!
(hab ich nie kapiert warum alle in der MC Welt so "scharf" auf SimonK's BL sind... ist ne Krücke, Vorteil war mal dass man den USB-Linker nehmen konnte, der mal billig erschien, aber mittlerweile ist das anders, ein USB-Linker ist teurer als z.B. der FTDI den man für den Arduino o. Hagens BL braucht... und Viele werden eh schon einen FTDI rumliegen haben... warum bei Krücken bleiben).
EDITII:
- er schaut erst ob der RC-Input Pin (z.B. Int0) für 2s auf High bleibt, dazu wird ein Zähler (rct_boot) benutzt, falls in der Zeit der Eingang Null wird, wird rückgesprungen (irgendwo wird es evtl noch ne Timer-ISR geben die dazugehört)
- er überprüft dann (tricky!) ob die ersten zwei Bytes in der Bootloader-Sektion <> 0000 oder FFFF ist, wenn ja gehts zurück, wenn nein werden alle Pins auf Eingang geschaltet, der Watchdog beruhight, und der alte Wert von OSCCAL zurückgeschrieben (der wurde verändert um auch mit internen RC Oszi näher an 16MHz zu kommen), und dann gehts zum BL
Zuletzt bearbeitet:
Das schicke dran ist das der Bootloader eben einfach über Servokabel geht, ohne umlöten, zusätzliche Kabel oder ähnliches.
Statt dem USB-Linker kannst n Arduino mit entsprechendem Sketch nehmen.
Der Arduino Bootloader geht auch nicht sehr gut wenn du den Atmel nicht über den FTDI resetten kannst (wieder n extra Kabel), da der Timeout doch sehr kurz ist und die Regler ja auch keinen Reset Knopf haben, da wird das Fristgerechte anstöpseln zum Gedultspiel.
Der Obige Code ist aus der Simonk Firmware, nicht aus dem Bootloader, sollte also zeigen was in der Firmware zu tun ist.
Statt dem USB-Linker kannst n Arduino mit entsprechendem Sketch nehmen.
Der Arduino Bootloader geht auch nicht sehr gut wenn du den Atmel nicht über den FTDI resetten kannst (wieder n extra Kabel), da der Timeout doch sehr kurz ist und die Regler ja auch keinen Reset Knopf haben, da wird das Fristgerechte anstöpseln zum Gedultspiel.
Der Obige Code ist aus der Simonk Firmware, nicht aus dem Bootloader, sollte also zeigen was in der Firmware zu tun ist.
Zuletzt bearbeitet:
genau das geht auch mit Hagen's Bootloader... nennt sich dort 1-Wire... nimmt eigentlich jeder weil es eben so schick ist (LOL)... (schau dich mal auf meine Seite bei den GA250 Projekten um was da alles geht)
der Vorteil von Hagen's Bootloader ist - IMHO - das man auch über ihn aufs EEPROM zugreifen kann, perfekt um irgendwelche Konfigurationsbytes per PC_USB-Dongle oder PorgBox/ProgKarte einstellen zu können (bei deinem ESCLight könnte man so z.B. verschiede Blicnksequenzen, oder Zeitscheiben, etc. einstellen ohne neu Flaschen zu müssen, etc. pp)
der Nachteil von Hagen's BL ist das es halt nicht der SimonK BL ist und nicht über avrdude läuft, also halt etwas anderes/neues ist
aber ist am Ende immer alles auch Geschmacksfrage
der Vorteil von Hagen's Bootloader ist - IMHO - das man auch über ihn aufs EEPROM zugreifen kann, perfekt um irgendwelche Konfigurationsbytes per PC_USB-Dongle oder PorgBox/ProgKarte einstellen zu können (bei deinem ESCLight könnte man so z.B. verschiede Blicnksequenzen, oder Zeitscheiben, etc. einstellen ohne neu Flaschen zu müssen, etc. pp)
der Nachteil von Hagen's BL ist das es halt nicht der SimonK BL ist und nicht über avrdude läuft, also halt etwas anderes/neues ist
aber ist am Ende immer alles auch Geschmacksfrage
und da frage ich mich schon seit langem,
wenn man schon neue Software schreibt, warum steht man immer noch auf "welche typisch bei 1520us"
ist für mich, eine sinnlose Warterei?
wir sind doch schon seit Jahren nicht mehr an der Analogen-Servoelektronik gebunden.
allerdings für höchste Geschwindigkeiten, ist leider ist der unbenutzbare ICP wohl auch ein Handycap.
... (aber da könnte man ja notfalls zum Eingang brücken, ala QUAX)
das "1520us" heute nicht mehr akzeptabel sind, haben ja schon seit langem einige Servohersteller bemerkt,
und sind bei 720us angelangt.
... (und wie QUAX bewiesen hat, ist selbst für bilige ESC, eine Eingangs-PWM von 4KHz kein Problem)
was bringt mir ein Gimball beim Videoflug, wenn es eh immer mindestens "typisch bei 1520us" hinterher hinkt
Zuletzt bearbeitet:
ähm... wolltest du nur mal einen allgemeinen Rundschlag raushauen, oder willst du uns etwas sinnvolles sagen?
1) es wäre kein Problem auf 720us oder meinetwegen 360us zu gehen... wenn es einen sinnvollen Bedarf dafür geben würde (das "im Moment" im Zitat wolltest du wohl nicht mit lesen)
2) SimonK läuft auch "nur" auf 1520us... ich habe gehört das SimonK gaaanzz toll geht, und ich habe auch gehört dass es eine ganze Menge SimonK Benutzer gibt (LOL)... so richtig für was anderes scheint es wohl dann doch keinen Bedarf zu geben
3) die PWM Varianten gibt es deswegen weil bei manchen Umrüstungen man sich einen PWM-Servo-Siganl Konverter spaaren will, nicht wegen der 4Khz oder 8Khz
4) wenn es anders wäre wären alle (OS) FC schon bei etwas Anderem als 1520us
was bringt mir ein Gimbal das nicht in die Luft kommt weil der Computer um auf typisch 0.000001 us zu kommen zu schwer ist? Denn, wenn dann schon mindestens 0.000001 us, alles andere ist doch sinnlose Warterei...
=> nenne uns doch deinen konkreten Anwendungsfall bei dem du mit 1520us nicht auskommst und mehr brauchst, dann bekommst du die Firmware dazu von mir, und du zeigst uns dann dein Projekt hier in Wort und Video...
und ich wäre glücklich dir geholfen zu haben, du wärst glücklich weil endlich etwas was bisher nicht gut klappte nun klappt, und alle Anderen hier wären glücklich dein gelungenes Projekt bewundern zu dürfen...
1) es wäre kein Problem auf 720us oder meinetwegen 360us zu gehen... wenn es einen sinnvollen Bedarf dafür geben würde (das "im Moment" im Zitat wolltest du wohl nicht mit lesen)
2) SimonK läuft auch "nur" auf 1520us... ich habe gehört das SimonK gaaanzz toll geht, und ich habe auch gehört dass es eine ganze Menge SimonK Benutzer gibt (LOL)... so richtig für was anderes scheint es wohl dann doch keinen Bedarf zu geben
3) die PWM Varianten gibt es deswegen weil bei manchen Umrüstungen man sich einen PWM-Servo-Siganl Konverter spaaren will, nicht wegen der 4Khz oder 8Khz
4) wenn es anders wäre wären alle (OS) FC schon bei etwas Anderem als 1520us
was bringt mir ein Gimbal das nicht in die Luft kommt weil der Computer um auf typisch 0.000001 us zu kommen zu schwer ist? Denn, wenn dann schon mindestens 0.000001 us, alles andere ist doch sinnlose Warterei...
=> nenne uns doch deinen konkreten Anwendungsfall bei dem du mit 1520us nicht auskommst und mehr brauchst, dann bekommst du die Firmware dazu von mir, und du zeigst uns dann dein Projekt hier in Wort und Video...
und ich wäre glücklich dir geholfen zu haben, du wärst glücklich weil endlich etwas was bisher nicht gut klappte nun klappt, und alle Anderen hier wären glücklich dein gelungenes Projekt bewundern zu dürfen...
SimonK, ist wohl zu sehr bekannt.
und erlich, "OlliW" habe ich bisher auch nur immer übersehen.
Asche auf mein Haupt, das wird anders werden.
nun ja, das grösste Handycap ist wohl, es gibt nur diese Preiswert zu kaufen.
... es sei man verwendet I2C, auch vor allem der geringeren Verzögerung wegen.
und ev. besteht ja die Hoffnung, das die "UltraESC" den PWM-Umbruch einlenken.
und erlich, "OlliW" habe ich bisher auch nur immer übersehen.
Asche auf mein Haupt, das wird anders werden.
nun ja, das grösste Handycap ist wohl, es gibt nur diese Preiswert zu kaufen.
... es sei man verwendet I2C, auch vor allem der geringeren Verzögerung wegen.
und ev. besteht ja die Hoffnung, das die "UltraESC" den PWM-Umbruch einlenken.
I2C wird zwar viel genannt, bringt aber kaum was... Grund: man kann alles immer nur nacheinander ansprechen... Beispiel: eine einfache I2C bei 400kHz braucht, sagen wir mal, 125us, 4 Motoren = 4 ESC => 500us, 8 Motoren = 8 ESC => 1000 us, kommt noch ne 6 ODF IMU dazu, müssen nochmals ca. 500 us dazu gerechnet werden... kommt noch ein Magnetometer dazu... du siehst der Vorteil des Servo PWMs: Man kann es für ausreichend viele Motoren GLEICHZEITIG starten während man derweil mit der IMU redet, was rumrechnet...
ähnlich sieht's bei UART aus
wenn man ein serielles Protokoll nimmt, muss es -IMHO - schon ein schnelles sein damit sich's wirklich lohnt (SPI,...,...)
(oder ein Prozessor mit vielen Hardware I2C's, Uarts, etc.)
PWM ist für die Kommunikation mit den ESCs also - IMHO - gar nicht schlecht... und - IMHO - der Grund warum es noch immer lebt... man könnte natürlich mal von den 1500us wegkommen... wäre aber kein wirkliches Problem... und so richtig die Notwendigkeit scheint ja wie gesagt nicht da
und dies ergibt sich aus ganz grundlegenden Prinzipien, wie dass die typische Zeitskala von Gimbals, Multicoptern, Helicoptern, Modelfliegern, etc selten deutlich schneller als 10 Hz ist... da reicht 1ms zum Regeln halt meist einfach aus...
und wie gesagt
ähnlich sieht's bei UART aus
wenn man ein serielles Protokoll nimmt, muss es -IMHO - schon ein schnelles sein damit sich's wirklich lohnt (SPI,...,...)
(oder ein Prozessor mit vielen Hardware I2C's, Uarts, etc.)
PWM ist für die Kommunikation mit den ESCs also - IMHO - gar nicht schlecht... und - IMHO - der Grund warum es noch immer lebt... man könnte natürlich mal von den 1500us wegkommen... wäre aber kein wirkliches Problem... und so richtig die Notwendigkeit scheint ja wie gesagt nicht da
und dies ergibt sich aus ganz grundlegenden Prinzipien, wie dass die typische Zeitskala von Gimbals, Multicoptern, Helicoptern, Modelfliegern, etc selten deutlich schneller als 10 Hz ist... da reicht 1ms zum Regeln halt meist einfach aus...
und wie gesagt
Hallo Leute,
Ich baue zur Zeit einen 3 Achsen Brushless Gimbal, als Steuerung der 3en Achse habe ich an einen ESC gedacht, da ich diesen Thread hier kenne. Die reine ansteuerung über die Funke reicht mir im moment also ohne Automatischen ausgleich, das ganze Funktioniert soweit auch, Siehe Video.
http://www.youtube.com/watch?v=vLrBJK1ImhI
Einzige Problem: Der Gimbal Pendelt nach dem Drehen hin und her, siehe video ab ca ab 50 sekunden, da habe ich diesen effekt provoziert.
Nun ich habe mich mit OlliW schon etwas unterhalten wie man dieses nachpendeln unterdrücken könnte oder reduzieren
Ich baue zur Zeit einen 3 Achsen Brushless Gimbal, als Steuerung der 3en Achse habe ich an einen ESC gedacht, da ich diesen Thread hier kenne. Die reine ansteuerung über die Funke reicht mir im moment also ohne Automatischen ausgleich, das ganze Funktioniert soweit auch, Siehe Video.
http://www.youtube.com/watch?v=vLrBJK1ImhI
Einzige Problem: Der Gimbal Pendelt nach dem Drehen hin und her, siehe video ab ca ab 50 sekunden, da habe ich diesen effekt provoziert.
Nun ich habe mich mit OlliW schon etwas unterhalten wie man dieses nachpendeln unterdrücken könnte oder reduzieren
Hallo Zusammen,
wie Otti20vt schon sagte, wir hatten diesbzgl. bereits per PM einigen Austausch, sind jetzt aber hierher gegangen weil es vielleicht doch interessant ist LOL
ich hatte für Otti20vt's Zweck die Firmware angepasst, das Problem bei der "alten" Firmware war dass die Drehung viel zu schnell war, also musste die Drehgeschwindigkeit angepasst werden. Ich habe die Firmware dann gleich so umgestrickt dass sie - im Prinzip - für verschiedene Dinge konfigurierbar ist. Die Konfiguration ist im EEPROM gespeichert, d.h. sie kann "leicht" geändert werden indem man einfach andere Werte ins EEprom schreibt. Ist noch nicht die ganz ultimative Lösung, da man hierzu entweder den ISP-Programmieranschluss mit geeigneten ISP-Programmer benutzen muss oder einen Bootloader (z.B. Hagen's Avrootloader) aufspielt und über einen extra Adapter kommuniziert, und eine Art GUI gibt's halt auch nicht. Aber immerhin, es geht.
Das größere Problem ist aber tatsächlich das Pendeln... das ist nämlich beim direkt-drive-brushless Antrieb prinzip-bedingt, wie ich in diesem Artikel schon mal rausgefunden habe: http://www.olliw.eu/2013/brushless-gimbal-direct-drive/.
Noch habe ich keine gute Idee wie man das vermeiden könnte.
Man könnte natürlich eine Art Tiefpassfilter einbauen, dass das Anfahren und Stoppen so langsam macht das es zu keinem Pendeln kommt. Problem: Es wird erstens ziemlich langsam sein müssen, und zweitens wird ja dann das Stoppen auch sehr stark verzögert, d.h. ich frage mich ob es dann überhaupt noch gelingt eine gewünschte Position anzufahren (zumindest wenn man mit dem Stick die Drehrate und nicht die absolute Position steuert).
Ein anderer Ansatz wäre die aktuelle Position "irgendwie" (Poti, Positonsencoder, Gyro, usw) messbar zu machen und eine Regelung drumrumzubauen. Vorteil: wird gut klappen und man bekommt gleich noch alles was man sonst will (Pan?). Nachteil: nicht mehr so schön einfach.
Ein weitere Ansatz wäre durch irgendeine mechanische Vorrichtung für eine zusätzliche Dämpfung zu sorgen (= Rotationsdämpfer). Nur wie könnte man das selber/günstig machen?
EDIT: ein bischen gegoogelt http://de.rs-online.com/web/c/?sra=oss&r=t&searchTerm=rotationsdämpfer&x=0&y=0
Das war es dann aber auch schon was mir soweit einfällt...
Wie ist das denn eigentlich bei "richtigen" Lösungen? Ich meine, das Problem das bei einem abrupten Stoppen das Gimbal noch etwas nachlaufen muss müssen ja alle, auch Profisysteme haben.
Cheers,
Olli
wie Otti20vt schon sagte, wir hatten diesbzgl. bereits per PM einigen Austausch, sind jetzt aber hierher gegangen weil es vielleicht doch interessant ist LOL
ich hatte für Otti20vt's Zweck die Firmware angepasst, das Problem bei der "alten" Firmware war dass die Drehung viel zu schnell war, also musste die Drehgeschwindigkeit angepasst werden. Ich habe die Firmware dann gleich so umgestrickt dass sie - im Prinzip - für verschiedene Dinge konfigurierbar ist. Die Konfiguration ist im EEPROM gespeichert, d.h. sie kann "leicht" geändert werden indem man einfach andere Werte ins EEprom schreibt. Ist noch nicht die ganz ultimative Lösung, da man hierzu entweder den ISP-Programmieranschluss mit geeigneten ISP-Programmer benutzen muss oder einen Bootloader (z.B. Hagen's Avrootloader) aufspielt und über einen extra Adapter kommuniziert, und eine Art GUI gibt's halt auch nicht. Aber immerhin, es geht.
Das größere Problem ist aber tatsächlich das Pendeln... das ist nämlich beim direkt-drive-brushless Antrieb prinzip-bedingt, wie ich in diesem Artikel schon mal rausgefunden habe: http://www.olliw.eu/2013/brushless-gimbal-direct-drive/.
Noch habe ich keine gute Idee wie man das vermeiden könnte.
Man könnte natürlich eine Art Tiefpassfilter einbauen, dass das Anfahren und Stoppen so langsam macht das es zu keinem Pendeln kommt. Problem: Es wird erstens ziemlich langsam sein müssen, und zweitens wird ja dann das Stoppen auch sehr stark verzögert, d.h. ich frage mich ob es dann überhaupt noch gelingt eine gewünschte Position anzufahren (zumindest wenn man mit dem Stick die Drehrate und nicht die absolute Position steuert).
Ein anderer Ansatz wäre die aktuelle Position "irgendwie" (Poti, Positonsencoder, Gyro, usw) messbar zu machen und eine Regelung drumrumzubauen. Vorteil: wird gut klappen und man bekommt gleich noch alles was man sonst will (Pan?). Nachteil: nicht mehr so schön einfach.
Ein weitere Ansatz wäre durch irgendeine mechanische Vorrichtung für eine zusätzliche Dämpfung zu sorgen (= Rotationsdämpfer). Nur wie könnte man das selber/günstig machen?
EDIT: ein bischen gegoogelt http://de.rs-online.com/web/c/?sra=oss&r=t&searchTerm=rotationsdämpfer&x=0&y=0
Das war es dann aber auch schon was mir soweit einfällt...
Wie ist das denn eigentlich bei "richtigen" Lösungen? Ich meine, das Problem das bei einem abrupten Stoppen das Gimbal noch etwas nachlaufen muss müssen ja alle, auch Profisysteme haben.
Cheers,
Olli
Zuletzt bearbeitet:
- Status
