endlich da :) KISS ESC 18A 2-4S & 12A 2-4S
- Themenstarter ronco
- Beginndatum
- Status
Wirklich beeindruckend,
Wie machst du das, mit dem über Kopf fliegen?
Einfach Motoren mit minimaler Drehzahl drehen lassen oder?
ich muss auch mal auf OneShot umstellen.
Erstmal order ich mir ein paar 18A KISS Regler, die 12A scheinen auf dauer ein wenig zu schwach für meine Motoren zu sein.
Hoffentlich kommen bald die Ersatzmotoren an, kann es kaum erwarten, das Ding fliegen zu lassen.
mfg
Olaf
Wie machst du das, mit dem über Kopf fliegen?
Einfach Motoren mit minimaler Drehzahl drehen lassen oder?
ich muss auch mal auf OneShot umstellen.
Erstmal order ich mir ein paar 18A KISS Regler, die 12A scheinen auf dauer ein wenig zu schwach für meine Motoren zu sein.
Hoffentlich kommen bald die Ersatzmotoren an, kann es kaum erwarten, das Ding fliegen zu lassen.
mfg
Olaf
ich hab auch ein erstes video mit den kiss reglern gemacht, die mobius kann allerdings mit der hero4 black(120frames, zeitlupen usw) nicht mithalten und ein bisschen mehr übung mit dem racing brauchen wir auch noch ... , aber lustig wars trotzdem 
https://www.youtube.com/watch?v=m_cCFbeA5gI
grüsse
joachim
https://www.youtube.com/watch?v=m_cCFbeA5gI
grüsse
joachim
@joergrohde: Eigentlich wollte ich ja mit dem HoTT-OSD weitermachen. Nun sitze ich hier und löte einen Robbe 2824-26 an meinen Reserve-KiSS18A. Mal sehen wie weit ich komme. Zunächst mache ich einfach ein PWM mit 125..250µs daraus. Dann drehe ich Testweise die Auflösung wieder hoch. Schliesslich schaue ich mal, ob ich noch OneShot in TauLabs reinkriege. Nur Fliegen werde ich nicht schaffen... Meine Familie wird mich hassen .
Etwas Später...
Nun habe ich einen Versuchsaufbau auf dem Tisch. Quanton+KiSS+Motor+2S LiPo. Fürs erste nur den JP1 gelistet und noch nichts programmiert. MIN=125, MAX=250µs gesetzt und mit der Updatefrequenz bei 2000Hz angefangen. Macht zwar nur eine Auflösung von 125 aber egal.
- Regler im OneShotmode mit 125/250µs angelernt... OK.
- Mit der GCS getestet...OK
Scheint schon schneller zu reagieren, als vorher mit 400Hz.
Da ja 250µs 4000Hz Periode entsprechen, habe ich mal probiert die Frequenz höher zu nehmen. Das funktioniert schonmal. Bei voller Ausnutzung der 250µs komme ich bei meinem Regler auf eine maximale Updatefrequenz von 3937Hz. Wenn ich 3938Hz nehme, dann geht mein KiSS bei 250µs in failsafe. Ich kann die Frequenz aber auch auf z.B. 6000Hz nehmen und der Motor geht trotzdem bis zu einer gewissen Grenze.
Nun frage ich mich ob es sinnvoll ist, OneShot so zu implementieren wie es gedacht ist. Also Timer anhalten, Startwert auf 0 und nach schreiben der Werte alle gleichzeitig loslaufen zu lassen. These: Was passiert, wenn mit noch schnelleren CPUs die PID-Schleife den Oneshot überholt? Fürs Erste würde ich es so machen: Wenn die Updatefrequenz >1000Hz ist, den Grundtakt für den Timer nicht wie bisher auf 1MHz sondern 8MHz setzen. Der Prescaler würde wie bisher errechnet, so dass die µs-Werte wieder passen. Für OneShot wäre der ChannelType dann nicht PWM sondern PWM8 und die ausgerechneten µs-Werte würden direkt (ohne Prescaler) in die Reloadwerte geschrieben. Damit also ohne Auflösungsverlust durch 8 geteilt. Als Updatefrequenz würde ich mit 3900Hz anfangen.
Jetzt müsste nur mal jemand mit einem TauLabs-Kopter ein bisschen fliegen gehen. Ich muss sagen, dass nicht mit den Fingern auf der Tastatur mehr drauf habe als mit den Sticks an der Funke.
@Felix: Kommt der KiSS eventuell aus dem Tritt, wenn ich das Update so hoch nehme?
.Etwas Später...
Nun habe ich einen Versuchsaufbau auf dem Tisch. Quanton+KiSS+Motor+2S LiPo. Fürs erste nur den JP1 gelistet und noch nichts programmiert. MIN=125, MAX=250µs gesetzt und mit der Updatefrequenz bei 2000Hz angefangen. Macht zwar nur eine Auflösung von 125 aber egal.
- Regler im OneShotmode mit 125/250µs angelernt... OK.
- Mit der GCS getestet...OK
Scheint schon schneller zu reagieren, als vorher mit 400Hz.
Da ja 250µs 4000Hz Periode entsprechen, habe ich mal probiert die Frequenz höher zu nehmen. Das funktioniert schonmal. Bei voller Ausnutzung der 250µs komme ich bei meinem Regler auf eine maximale Updatefrequenz von 3937Hz. Wenn ich 3938Hz nehme, dann geht mein KiSS bei 250µs in failsafe. Ich kann die Frequenz aber auch auf z.B. 6000Hz nehmen und der Motor geht trotzdem bis zu einer gewissen Grenze.
Nun frage ich mich ob es sinnvoll ist, OneShot so zu implementieren wie es gedacht ist. Also Timer anhalten, Startwert auf 0 und nach schreiben der Werte alle gleichzeitig loslaufen zu lassen. These: Was passiert, wenn mit noch schnelleren CPUs die PID-Schleife den Oneshot überholt? Fürs Erste würde ich es so machen: Wenn die Updatefrequenz >1000Hz ist, den Grundtakt für den Timer nicht wie bisher auf 1MHz sondern 8MHz setzen. Der Prescaler würde wie bisher errechnet, so dass die µs-Werte wieder passen. Für OneShot wäre der ChannelType dann nicht PWM sondern PWM8 und die ausgerechneten µs-Werte würden direkt (ohne Prescaler) in die Reloadwerte geschrieben. Damit also ohne Auflösungsverlust durch 8 geteilt. Als Updatefrequenz würde ich mit 3900Hz anfangen.
Jetzt müsste nur mal jemand mit einem TauLabs-Kopter ein bisschen fliegen gehen. Ich muss sagen, dass nicht mit den Fingern auf der Tastatur mehr drauf habe als mit den Sticks an der Funke
.@Felix: Kommt der KiSS eventuell aus dem Tritt, wenn ich das Update so hoch nehme?
Zuletzt bearbeitet:
@joergrohde: Eigentlich wollte ich ja mit dem HoTT-OSD weitermachen. Nun sitze ich hier und löte einen Robbe 2824-26 an meinen Reserve-KiSS18A. Mal sehen wie weit ich komme. Zunächst mache ich einfach ein PWM mit 125..250µs daraus. Dann drehe ich Testweise die Auflösung wieder hoch. Schliesslich schaue ich mal, ob ich noch OneShot in TauLabs reinkriege. Nur Fliegen werde ich nicht schaffen... Meine Familie wird mich hassen .
Etwas Später...
Nun habe ich einen Versuchsaufbau auf dem Tisch. Quanton+KiSS+Motor+2S LiPo. Fürs erste nur den JP1 gelistet und noch nichts programmiert. MIN=125, MAX=250µs gesetzt und mit der Updatefrequenz bei 2000Hz angefangen. Macht zwar nur eine Auflösung von 125 aber egal.
- Regler im OneShotmode mit 125/250µs angelernt... OK.
- Mit der GCS getestet...OK
Scheint schon schneller zu reagieren, als vorher mit 400Hz.
Da ja 250µs 4000Hz Periode entsprechen, habe ich mal probiert die Frequenz höher zu nehmen. Das funktioniert schonmal. Bei voller Ausnutzung der 250µs komme ich bei meinem Regler auf eine maximale Updatefrequenz von 3937Hz. Wenn ich 3938Hz nehme, dann geht mein KiSS bei 250µs in failsafe. Ich kann die Frequenz aber auch auf z.B. 6000Hz nehmen und der Motor geht trotzdem bis zu einer gewissen Grenze.
Nun frage ich mich ob es sinnvoll ist, OneShot so zu implementieren wie es gedacht ist. Also Timer anhalten, Startwert auf 0 und nach schreiben der Werte alle gleichzeitig loslaufen zu lassen. These: Was passiert, wenn mit noch schnelleren CPUs die PID-Schleife den Oneshot überholt? Fürs Erste würde ich es so machen: Wenn die Updatefrequenz >1000Hz ist, den Grundtakt für den Timer nicht wie bisher auf 1MHz sondern 8MHz setzen. Der Prescaler würde wie bisher errechnet, so dass die µs-Werte wieder passen. Für OneShot wäre der ChannelType dann nicht PWM sondern PWM8 und die ausgerechneten µs-Werte würden direkt (ohne Prescaler) in die Reloadwerte geschrieben. Damit also ohne Auflösungsverlust durch 8 geteilt. Als Updatefrequenz würde ich mit 3900Hz anfangen.
Jetzt müsste nur mal jemand mit einem TauLabs-Kopter ein bisschen fliegen gehen. Ich muss sagen, dass nicht mit den Fingern auf der Tastatur mehr drauf habe als mit den Sticks an der Funke.
@Felix: Kommt der KiSS eventuell aus dem Tritt, wenn ich das Update so hoch nehme?
.Etwas Später...
Nun habe ich einen Versuchsaufbau auf dem Tisch. Quanton+KiSS+Motor+2S LiPo. Fürs erste nur den JP1 gelistet und noch nichts programmiert. MIN=125, MAX=250µs gesetzt und mit der Updatefrequenz bei 2000Hz angefangen. Macht zwar nur eine Auflösung von 125 aber egal.
- Regler im OneShotmode mit 125/250µs angelernt... OK.
- Mit der GCS getestet...OK
Scheint schon schneller zu reagieren, als vorher mit 400Hz.
Da ja 250µs 4000Hz Periode entsprechen, habe ich mal probiert die Frequenz höher zu nehmen. Das funktioniert schonmal. Bei voller Ausnutzung der 250µs komme ich bei meinem Regler auf eine maximale Updatefrequenz von 3937Hz. Wenn ich 3938Hz nehme, dann geht mein KiSS bei 250µs in failsafe. Ich kann die Frequenz aber auch auf z.B. 6000Hz nehmen und der Motor geht trotzdem bis zu einer gewissen Grenze.
Nun frage ich mich ob es sinnvoll ist, OneShot so zu implementieren wie es gedacht ist. Also Timer anhalten, Startwert auf 0 und nach schreiben der Werte alle gleichzeitig loslaufen zu lassen. These: Was passiert, wenn mit noch schnelleren CPUs die PID-Schleife den Oneshot überholt? Fürs Erste würde ich es so machen: Wenn die Updatefrequenz >1000Hz ist, den Grundtakt für den Timer nicht wie bisher auf 1MHz sondern 8MHz setzen. Der Prescaler würde wie bisher errechnet, so dass die µs-Werte wieder passen. Für OneShot wäre der ChannelType dann nicht PWM sondern PWM8 und die ausgerechneten µs-Werte würden direkt (ohne Prescaler) in die Reloadwerte geschrieben. Damit also ohne Auflösungsverlust durch 8 geteilt. Als Updatefrequenz würde ich mit 3900Hz anfangen.
Jetzt müsste nur mal jemand mit einem TauLabs-Kopter ein bisschen fliegen gehen. Ich muss sagen, dass nicht mit den Fingern auf der Tastatur mehr drauf habe als mit den Sticks an der Funke
.@Felix: Kommt der KiSS eventuell aus dem Tritt, wenn ich das Update so hoch nehme?
Hi,
und ja ich würde max. 2khz wiederohlrate nehmen. da sonnst halt sehr viele interrupts beim ESC aufkommen, und diese ja auch jedes mal verarbeitet werden müssen .. und so schnell das kiss auch ist, es ist nur ein 8bit tiny der da werkelt
es ist immer ein verhältniss zur drehzahl .. hohe drehzahl = hohe mcu lasst wenn jetzt noch ~4khz PWM signal interrupts dazwischen kommmen, wirds halt irgentwann zuviel. grade wenn man vollgas + knappen timer max hat, hat man ja ende und anfang der periode sehr nah beieinander und das sind halt 2 interrupts die beide sofort verarbeitet werden wollen.dehalb, lieber richtiges oneshot
gruß
Felix
Hi,
ich habe einfach mal drauflos probiert. Jetzt habe ich 8MHz Basisfrequenz und 3,9kHz Updatefrequenz. Der KiSS läuft stabil. Ich verstehe Deine Bedenken. Aber was, wenn der PID-Zyklus ist Zukunft schneller wird? Ich bin beim Quanton derzeit bei 1,45ms UpdateTime. Wenn ST nächstes Jahr neue CPUs/Sensoren rausbringt, wird es vielleicht noch schneller. Und wenn ich dann richtiges OneShot einbaue, dann stimmen später die Werte nicht oder die Pause zwischen 2 Werten wird auch wieder zu knapp. Plan B wäre dann nicht 8 sondern 16MHz und andere ESCs zu nehmen. Ich weiss, dass der ATTiny viel zu tun hat. Meinst Du, dass sich unter Lastverhältnissen das Timing im ATTiny verschiebt? Du hast ihn ja programmiert.
gruss
jörg
ich habe einfach mal drauflos probiert. Jetzt habe ich 8MHz Basisfrequenz und 3,9kHz Updatefrequenz. Der KiSS läuft stabil. Ich verstehe Deine Bedenken. Aber was, wenn der PID-Zyklus ist Zukunft schneller wird? Ich bin beim Quanton derzeit bei 1,45ms UpdateTime. Wenn ST nächstes Jahr neue CPUs/Sensoren rausbringt, wird es vielleicht noch schneller. Und wenn ich dann richtiges OneShot einbaue, dann stimmen später die Werte nicht oder die Pause zwischen 2 Werten wird auch wieder zu knapp. Plan B wäre dann nicht 8 sondern 16MHz und andere ESCs zu nehmen. Ich weiss, dass der ATTiny viel zu tun hat. Meinst Du, dass sich unter Lastverhältnissen das Timing im ATTiny verschiebt? Du hast ihn ja programmiert
.gruss
jörg
Hi,
ich habe einfach mal drauflos probiert. Jetzt habe ich 8MHz Basisfrequenz und 3,9kHz Updatefrequenz. Der KiSS läuft stabil. Ich verstehe Deine Bedenken. Aber was, wenn der PID-Zyklus ist Zukunft schneller wird? Ich bin beim Quanton derzeit bei 1,45ms UpdateTime. Wenn ST nächstes Jahr neue CPUs/Sensoren rausbringt, wird es vielleicht noch schneller. Und wenn ich dann richtiges OneShot einbaue, dann stimmen später die Werte nicht oder die Pause zwischen 2 Werten wird auch wieder zu knapp. Plan B wäre dann nicht 8 sondern 16MHz und andere ESCs zu nehmen. Ich weiss, dass der ATTiny viel zu tun hat. Meinst Du, dass sich unter Lastverhältnissen das Timing im ATTiny verschiebt? Du hast ihn ja programmiert.
gruss
jörg
ich habe einfach mal drauflos probiert. Jetzt habe ich 8MHz Basisfrequenz und 3,9kHz Updatefrequenz. Der KiSS läuft stabil. Ich verstehe Deine Bedenken. Aber was, wenn der PID-Zyklus ist Zukunft schneller wird? Ich bin beim Quanton derzeit bei 1,45ms UpdateTime. Wenn ST nächstes Jahr neue CPUs/Sensoren rausbringt, wird es vielleicht noch schneller. Und wenn ich dann richtiges OneShot einbaue, dann stimmen später die Werte nicht oder die Pause zwischen 2 Werten wird auch wieder zu knapp. Plan B wäre dann nicht 8 sondern 16MHz und andere ESCs zu nehmen. Ich weiss, dass der ATTiny viel zu tun hat. Meinst Du, dass sich unter Lastverhältnissen das Timing im ATTiny verschiebt? Du hast ihn ja programmiert
.gruss
jörg
wenn die FC's eine loop zeit von unter 500µS haben, mach ich echt nen oneshot 62.5
oder gleich 31.25.. aber irgend wann wird sogar TC's argument greifen .... dann wird auch der kleinste motor physisch zu träge.gruß
Felix
also wenn ich jetzt keinen mist gerechnet hab muesstest du 3 mal schneller den regler rechnen koennen damit du ueberhaupt ueber die 2khz grenze kommst
das waere schon eine sehr deutliche verbesserung
btw ronco kommen die kiss damit zurecht wenn die zeitspanne zwischen oneshot signalen stark schwankt? wenn ja wueder ich mal probieren dass sich die fc den letzten wert den sie an den esc geschickt hat speichert und nur dann ein neues oneshot signal erzeugt und raussendet wenn der auch tatsaechlich anders ist
das waere schon eine sehr deutliche verbesserung
btw ronco kommen die kiss damit zurecht wenn die zeitspanne zwischen oneshot signalen stark schwankt? wenn ja wueder ich mal probieren dass sich die fc den letzten wert den sie an den esc geschickt hat speichert und nur dann ein neues oneshot signal erzeugt und raussendet wenn der auch tatsaechlich anders ist
Die Servo-Werte werden bei mir im 1,4ms Zyklus geschrieben. Da aber normalerweise nur 400Hz PWM-Frequenz vorgesehen sind, fehlt die Ausgabe der Werte. Ohne Softwareänderung kann man schon jetzt den PWM-Frequenz auf z.B. 3900Hz setzen und die MIN/MAX auf 125/250µs legen. Damit geht die Funktion schonmal aber die Auflösung liegt dann bei 1µs .
Jedenfalls merke ich schon den Unterschied im Ansprechverhalten des Motors auf dem Tisch. Bei 3900Hz hast Du also maximal 257µs bis der neue Wert am KiSS ankommt.
.Jedenfalls merke ich schon den Unterschied im Ansprechverhalten des Motors auf dem Tisch. Bei 3900Hz hast Du also maximal 257µs bis der neue Wert am KiSS ankommt.
das failsave der kiss springt ab 0.2 sekunden ohne gültiges signal an (disarmt) solange die signale schneller kommen ist das erstmal kein problem. ich hab auch nicht genau gemessen ab wann die eingangs PWM interrupts probleme machen .. ich kann nur mit sicherheit sagen das abei 320k feldrehzahlen der MCU nahe zu 100% ausgelasstet ist und deshalb jede weitere lasst eben stören wird. (320000 frpm sind 45700rpm beim 14 poler).
aber warum stellst du die timer denn net einfach auf 8 mhz? die meissten stm32's haben doch timer genug
hier mal ein schnipsel wie ich oneshot und normales PWM bei nem stm32f051 gemacht hatte:
das am ende des main loops...
der timer läuft natülich mit 8mhz.
gruß
Feix
Die Servo-Werte werden bei mir im 1,4ms Zyklus geschrieben. Da aber normalerweise nur 400Hz PWM-Frequenz vorgesehen sind, fehlt die Ausgabe der Werte. Ohne Softwareänderung kann man schon jetzt den PWM-Frequenz auf z.B. 3900Hz setzen und die MIN/MAX auf 125/250µs legen. Damit geht die Funktion schonmal aber die Auflösung liegt dann bei 1µs .
Jedenfalls merke ich schon den Unterschied im Ansprechverhalten des Motors auf dem Tisch. Bei 3900Hz hast Du also maximal 257µs bis der neue Wert am KiSS ankommt.
.Jedenfalls merke ich schon den Unterschied im Ansprechverhalten des Motors auf dem Tisch. Bei 3900Hz hast Du also maximal 257µs bis der neue Wert am KiSS ankommt.
hier mal ein schnipsel wie ich oneshot und normales PWM bei nem stm32f051 gemacht hatte:
Code:
if(RXcommands[5] < 150){ // normal PWM 1-2ms
if(ModeWas != 0){ // change the timers to run with normal PWM
TIM1->ARR = 16100; // to have it at 497Hz 500 may give errors at full throttle
ModeWas = 0;
}
TIM1->CCR4 = MotorValue<<3; //value*8 so 8000-16000
}else{ // oneshot 125
if(ModeWas != 1){ // change the timers to run with oneshot125
TIM1->ARR = 0xFFFF; // full 16-bit
ModeWas = 1;
}
TIM1->CR1 &= (uint16_t)(~((uint16_t)TIM_CR1_CEN)); // 1. disable Tim 1
TIM1->CNT = 0; // 2. reset tim1 counter to 0
TIM1->CCR4 = MotorValue; // 3. load the new Value
TIM1->CR1 |= TIM_CR1_CEN; // 4. start Tim1 // it will repeat the old value if the loop takes longer then ~8ms
}der timer läuft natülich mit 8mhz.
gruß
Feix
Zuletzt bearbeitet:
Bei 8MHz gibt es leider ein Problem. Die ersten 4 PWM-Kanäle am Quanton laufen am TIM3 mit 168/2=84MHz Grundtakt. Die kriege ich nicht auf 8MHz über einen Perscaler. Ich könnte die auf 12MHz laufen lassen und die PWM-Werte hochrechnen um die Auflösung nicht zu verlieren. Dann brauche ich noch eine elegante Möglichkeit den entsprechenden Timer von nochmalen PWM und OneShot zu trennen wenn ich den wirklich über TIM_TimeBaseInit() forcen will. Da das protierbar bleiben soll, kann ich nicht einfach in die Timerregister schreiben.
Daher gefällt mir die Variante mit der erhöhten Updatefrequenz besser.
Daher gefällt mir die Variante mit der erhöhten Updatefrequenz besser.
Zuletzt bearbeitet:
@Liriel: Ich denke mal, dass die FETs sau schnell schalten und der RDSon superklein ist. Damit minimiert sich die Verlustleistung erheblich. Also hast Du kaum Abwärme.
@Felix: Bin schon etwas weiter mit OneShot. Leider funktionieren die Timer im STM32F4 nicht ganz so wie Du es auf dem F0 programmiert hast. Beim F4 musst Du ein Event auslösen, damit der Timer die neuen Werte übernimmt. Geht aber schonmal. Auf dem Oszi habe ich jetzt die programmierte Pulsbreite und irgendwas um 665Hz Updatefrequenz. Nun noch die Timerauflösung für OneShot entsprechend hochnehmen, einen Namen dafür ausdenken, damit das in TL auch parametrierbar wird. Mal sehen, vielleicht wird es noch was vor Silvester...
gruss
jörg
@Felix: Bin schon etwas weiter mit OneShot. Leider funktionieren die Timer im STM32F4 nicht ganz so wie Du es auf dem F0 programmiert hast. Beim F4 musst Du ein Event auslösen, damit der Timer die neuen Werte übernimmt. Geht aber schonmal. Auf dem Oszi habe ich jetzt die programmierte Pulsbreite und irgendwas um 665Hz Updatefrequenz. Nun noch die Timerauflösung für OneShot entsprechend hochnehmen, einen Namen dafür ausdenken, damit das in TL auch parametrierbar wird. Mal sehen, vielleicht wird es noch was vor Silvester...
gruss
jörg
- Status
