endlich da :) KISS ESC 18A 2-4S & 12A 2-4S

Status
Nicht offen für weitere Antworten.

Brainstorm

Übung macht den Meister
und für alle die es noch nicht gesehen haben:
http://flyduino.net/Flyduino-Mini-Power-Distribution



150A Dauer? nicht schlecht :)
Dieses Mini PDB für die KISS Regler sieht toll aus! Hat's schon jemand gekauft und ausprobiert? Ich kann mir nicht so genau vorstellen wie das mit 4x KISS ESC bestückt und in einem Mini-Quad eingebaut aussehen soll. Da wären ein paar Fotos natürlich ideal.

Felix: Hättet ihr nicht per Zufall ein paar gute Produktfotos abgelichtet? Ihr habt doch sicherlich schon ein paar von den PDBs zum Testen bestückt. :)
 
Zuletzt bearbeitet:

aargau

Erfahrener Benutzer
Hi,

mach doch mal an eins der ESC's bei denen es reproduzierbar ist einen normalen empfänger drann. wenn das da immernoch auftritt, liegts wirklich am ESC oder an der verkabelung ums ESC. ich hab k.A. wie APM das signal generiert.. wenn das software PWM sein sollte, kann eshalt sein das die KISS das signal zittern deutlicher zeigen als andere ESC's weil sie eben sofort alles umsetzen... dann wäre aber mit empfänger direkt angeschlossen alles gut .. da empfänger eigentlich immer HW PWM machen ..


gruß

Felix
Ich hab jetzt das mal getestet. Zuerst nur ein Regler direkt am Empfänger angeschlossen - kein Problem. Da ich aber nicht 100% sicher bin ob es ev. wegen Spannungsproblemen oder so auftritt habe ich also noch ein zweiten Regler angelötet und nochmals getestet. Auch da, absolut keine Störung auch wenn ich am Gas spiele und schnelle Leistungswechsel "Simuliere".
Das würde für mich heissen es muss fast am APM liegen. Aber wieso?
Meine grossen Copter haben keine solche Probleme, da habe ich zwar keine KISS ESCs aber immerhin SimonK und BLHeli.
Ich meinte schon, dass der APM HW PWM macht, aber 100% sicher kann ich es nicht sagen.

Ich werde wohl nun mal auf ein CC3D Board Umlöten und schauen wie es da aussieht. Dann bin ich wenigstens 100% Sicher, obs am APM liegt oder nicht.
 

aargau

Erfahrener Benutzer
Jetzt ist es offiziell.. Mit dem CC3D und OpenPilot fliegt der Copter 1A ohne Störungen. Naja die PIDs passen nicht 100% aber keine Störungen zu sehen.
Es scheint also tatsächlich am APM zu liegen, da ich den selben PPM Empfänger nutze für den CC3D...

Werde wohl mal im ArduCopter Forum ein Thread eröffnen.
Ansonsten werde ich ev. eine Flip32 verbauen, da mir AltHold doch relativ wichtig ist und das CC3D Board ja leider kein Baro hat.
 

Novulon

Erfahrener Benutzer
Jetzt ist es offiziell.. Mit dem CC3D und OpenPilot fliegt der Copter 1A ohne Störungen. Naja die PIDs passen nicht 100% aber keine Störungen zu sehen.
Es scheint also tatsächlich am APM zu liegen, da ich den selben PPM Empfänger nutze für den CC3D...

Werde wohl mal im ArduCopter Forum ein Thread eröffnen.
Ansonsten werde ich ev. eine Flip32 verbauen, da mir AltHold doch relativ wichtig ist und das CC3D Board ja leider kein Baro hat.
Verdammt :D, ich möchte auch ein Pixhawk-Derivat zusammen mit den KISS benutzen. Hoffentlich lässt sich da was machen...
Ich halte mal ausschau nach deinem Thread. :)
 

olex

Der Testpilot
Das CC3D hat aber eine per SPI angebundene MPU und erlaubt Dir eine Looptime von 1kHz (1000µs) was gerade bei kleinen Kraftpaketen in Verbindung mit OneShot viel Sinn macht.
OK, Argument - das war mir nicht bewusst. Für OneShot ist die Hardware also tatsächlich vorzuziehen.
 

franko_

Erfahrener Benutzer
Also m.E. ist es nur ein Drähtchen was angelötet wird. siehe auch die Threads Naze32 mit Taulabs Firmware.

Leider gibt es die Links nicht mehr im RCGroups, aber das war damals der SPI STM32f103 zum MPU6050.
Das war auch nur bei dem Naze32 Rev3 so, die sollten den SPI connect haben, oder?

Das habe ich damals mit meinem Naze32 gemacht und lief auch danach ganz normal mit Cleanflight/Harakiri.
 
Zuletzt bearbeitet:

ernieift

Erfahrener Benutzer
Jetzt ist es offiziell.. Mit dem CC3D und OpenPilot fliegt der Copter 1A ohne Störungen. Naja die PIDs passen nicht 100% aber keine Störungen zu sehen.
Es scheint also tatsächlich am APM zu liegen, da ich den selben PPM Empfänger nutze für den CC3D...

Werde wohl mal im ArduCopter Forum ein Thread eröffnen.
Ansonsten werde ich ev. eine Flip32 verbauen, da mir AltHold doch relativ wichtig ist und das CC3D Board ja leider kein Baro hat.
Wenn es Dir um GPS etc. geht, dann kannst Du auch ein Sparky oder Quanton nehmen.
 

ronco

Erfahrener Benutzer
Ich hab jetzt das mal getestet. Zuerst nur ein Regler direkt am Empfänger angeschlossen - kein Problem. Da ich aber nicht 100% sicher bin ob es ev. wegen Spannungsproblemen oder so auftritt habe ich also noch ein zweiten Regler angelötet und nochmals getestet. Auch da, absolut keine Störung auch wenn ich am Gas spiele und schnelle Leistungswechsel "Simuliere".
Das würde für mich heissen es muss fast am APM liegen. Aber wieso?
Meine grossen Copter haben keine solche Probleme, da habe ich zwar keine KISS ESCs aber immerhin SimonK und BLHeli.
Ich meinte schon, dass der APM HW PWM macht, aber 100% sicher kann ich es nicht sagen.

Ich werde wohl nun mal auf ein CC3D Board Umlöten und schauen wie es da aussieht. Dann bin ich wenigstens 100% Sicher, obs am APM liegt oder nicht.
kann ich dir nicht genau sagen. habe kein APM .. meine aber das es schon leute gibt die diese kombi ohne probleme fliegen. vllt im zweifel einfach nochmal neu verkabeln.. nur um einen fehler da auszuschliessen.. die verkabelung und die ESC's können ja auch die APM stören.

Das CC3D hat aber eine per SPI angebundene MPU und erlaubt Dir eine Looptime von 1kHz (1000µs) was gerade bei kleinen Kraftpaketen in Verbindung mit OneShot viel Sinn macht.
OK, Argument - das war mir nicht bewusst. Für OneShot ist die Hardware also tatsächlich vorzuziehen.
looptimes von 1khz und weniger gehen auch problemlos mit i2c und der MPU6050. hab ich selbst schon geflogen (mit ner eigenen test FW) es wird erst knapp, wenn man noch viele andere sensoren in der gleichen i2c leitung hängen hatt.


gruß

Felix
 
...looptimes von 1khz und weniger gehen auch problemlos mit i2c und der MPU6050. hab ich selbst schon geflogen (mit ner eigenen test FW) es wird erst knapp, wenn man noch viele andere sensoren in der gleichen i2c leitung hängen hatt.
Leider ist nicht jeder in der Lage sich seine eigene Firmware zu schreiben oder sich die unnützen Teile aus vorhandener zu entfernen.
Erstaunlich ist schon das Base und Cleanflight immer wieder 20-50% Ausreißer in der kürzest möglichen Looptime ( = 0 ) bei I2C FC´s haben wie AcroNaze oder MW32. Bei CC3D oder Paris Sirius Air Hero32 ( 6500er MPU ) die Abweichungen vom Mittelwert bei 5-10% liegen.
 

PotRacer

Kamikazebuschpilot
sind die KISS 18A V1.1 jetzt vorverzinnt ?
Also +-und Signal sowie die 3 Lötpads auf der anderen Seite zum Motor hin??

eben 2 solche erhalten, die alten waren anders.. auch 18a v1.1
Gruß
 

wildflyer

wildflieger :-)
looptimes von 1khz und weniger gehen auch problemlos mit i2c und der MPU6050. hab ich selbst schon geflogen (mit ner eigenen test FW) es wird erst knapp, wenn man noch viele andere sensoren in der gleichen i2c leitung hängen hatt.
gruß

Felix
ob 1000us und weniger "gehen", heisst das jetzt, das der gyro und der rest der hardware schnell genug dafür ist? es wurde auch schon weniger "getestet", aber man merkt das doch im flug nicht unbedingt ob dann die looptime auch wirklich mit diesem wert läuft, oder ? wie testest du das, ob die looptime wirklich ausreicht um alles zu berechnen usw ?

grüsse

joachim
 
wildflyer, die minimal mögliche Looptime siehst Du wenn Du set looptime = 0 / save eingibst und dann wieder aus der CLI rausgehst.
NAZE32/MW32 usw mit Cleanflight 1200 +/- 150 und Ausreißer bis über 1700
AcroNaze 1100 +/- 150 Ausreißer bis 1500
CC3D 650 +/- 50 mit CF Ausreißer über 700
Paris AirHero32 540 +/-20 mit BF
Halt nur über die App beobachtet. Wenn Du es genau machen möchtest OneShot aktivieren, geht halt nicht in BF, und Oszi oder Logiliese auf den/die Ausgänge.
 

wildflyer

wildflieger :-)
wildflyer, die minimal mögliche Looptime siehst Du wenn Du set looptime = 0 / save eingibst und dann wieder aus der CLI rausgehst.
NAZE32/MW32 usw mit Cleanflight 1200 +/- 150 und Ausreißer bis über 1700
AcroNaze 1100 +/- 150 Ausreißer bis 1500
CC3D 650 +/- 50 mit CF Ausreißer über 700
Paris AirHero32 540 +/-20 mit BF
Halt nur über die App beobachtet. Wenn Du es genau machen möchtest OneShot aktivieren, geht halt nicht in BF, und Oszi oder Logiliese auf den/die Ausgänge.
ja genau solche daten brauche ich :)

wenn du sagst "ausreisser bis über 1700" kann man dann die looptime auf die 1200 stellen, was genau passiert dann bei so einem "ausreisser" und wie äussert sich der im flug, wenn überhaupt ?

und der gyro selber, da hat es bei rcg mal geheissen, das der gar nicht schnell genug daten liefern könnte um die niedrigen looptime einstellungen richtig nutzen zu können, stimmt das ?

grüsse

joachim
 

ronco

Erfahrener Benutzer
ja genau solche daten brauche ich :)

wenn du sagst "ausreisser bis über 1700" kann man dann die looptime auf die 1200 stellen, was genau passiert dann bei so einem "ausreisser" und wie äussert sich der im flug, wenn überhaupt ?

und der gyro selber, da hat es bei rcg mal geheissen, das der gar nicht schnell genug daten liefern könnte um die niedrigen looptime einstellungen richtig nutzen zu können, stimmt das ?

grüsse

joachim

ja es gibt da tatsächlich experten die verbreiten das wenn die MPU6050 mit z.b einem LPF von 42Hz leuft, es keinen sinn mache sie schneller als mit 42Hz aus zu lesen. die haben einfach net begriffen wie ein LPF geht. wenn ich mich recht erinnere wertet die MPU6050 die analogen gyrodaten intern mit 8khz aus (steht da irgentwo im datenblatt). daraus werden dann die gefilterten daten geliefert. ich habe mal logs gemacht und sie mit 1khz ausgelesen.. und welch überraschung, selbst bei einem LPF von 5Hz liefert sie alle 1000µs (schneller hab ich net getestet) brav neue daten.

der vorteil von SPI ist halt das das daten abfragen nicht solange dauert. mit 400khz I2c dauerts meine ich so ~400µS (für 3x16bit gyro und 3x16bit acc daten) von anfrage bis antwort. es ist halt FW abhängig ob man in der zeit wartet, oder eben schonmal sachen wie RX daten auswerten oder so macht.


ohne es jetzt genau zu wissen, würde ich sagen das die looptime spikes bei BF und CF entweder von i2c hängern (die stm32f1 hatte da komische sachen) oder von aufgaben die mit langsamerer frequenz .. also net jeden loop ausgeführt werden.


wie testest du das, ob die looptime wirklich ausreicht um alles zu berechnen usw ?
meine FW macht alles 1x pro loop. sachen wie RX daten auswerten müsste man zwar nur machen wenn neue daten da sind, aber ums zu sehen macht der immer alles. so weiss ich genau wie lange er braucht. und da ich unter 1000µs bin wartet der loop dann immer bis es 1000µs sind.


in pseudo code zusammengefasst:

Code:
loop{
 MPU6050 daten anfragen (antwort kommt per interrupt)
 RX daten auswerten
 auf MPU6050 daten warten
 MPU6050 daten auswerten
 PID controller 
 oneshot senden
 warten bis 1000µS voll sind
}
gruß

Felix
 

ernieift

Erfahrener Benutzer
Bei TL gibt es dafür einen Hardwaretreiber. Die MPU triggert je nach eingestellter MPU-Rate einen Interrupt (ähnlich einem USART), wenn sie neue Daten hat. Der Treiber holt die Daten meist per SPI (I2C geht auch) dann ab und gibt dem übergeordnetem Layer Bescheid. Damit rechnet der PID mit den aktuellen Daten und der vergangenen Zeit die neuen Sollwerte aus. Mit aktiviertem OneShot wird daraus eine komplett runde Sache.
Wenn Du nun immer nur so schnell du kannst die Sensordaten liest und damit rechnest, dann hast Du die gleichen Timingprobleme wie bei normaler PWM-Ausgabe (Jitter).
 

ronco

Erfahrener Benutzer
Bei TL gibt es dafür einen Hardwaretreiber. Die MPU triggert je nach eingestellter MPU-Rate einen Interrupt (ähnlich einem USART), wenn sie neue Daten hat. Der Treiber holt die Daten meist per SPI (I2C geht auch) dann ab und gibt dem übergeordnetem Layer Bescheid. Damit rechnet der PID mit den aktuellen Daten und der vergangenen Zeit die neuen Sollwerte aus. Mit aktiviertem OneShot wird daraus eine komplett runde Sache.
Wenn Du nun immer nur so schnell du kannst die Sensordaten liest und damit rechnest, dann hast Du die gleichen Timingprobleme wie bei normaler PWM-Ausgabe (Jitter).
dafür wartet ich ja bis 1000µS voll sind.. so hab ich kaum looptime jitter.. wenn TL das mit dem int pin macht, heisst das ja das ihr den DMP von der MPU nutzt.. läuft der nicht max mit 250Hz? wenn ja hat der für rohe gyro daten ja nur nachteile.. der lohnt sich dann erst ab level mode..


gruß

Felix
 

ernieift

Erfahrener Benutzer
Der MPU-Filter ist standardmäßig auf 256Hz. Also aus, da TL einen eigenen Filter benutzt. Kann man ändern, erzeugt aber bestimmt ein PT2-Glied. Timejitter gibt's bei TL auch nicht, da mit der vergangenen Zeit gerechnet wird.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten