ESC32 V3 - die nächste Generation an High End ESCs

kinderkram

kinderkram

Erfahrener Benutzer
#1
#1
ESC32 V3 - die nächste Generation High End ESCs

Es ist soweit:

Die neue Entwicklung von Bill Nesbitt (AutoQuad) und Felix Niessen (Flyduino, KISS & UltraESC) ist bei Viacopter und Flyduino verfügbar!




Feature Highlights:


  • Up to 10S and 1500 watts of power with good cooling has been acheived in bench tests.
  • A highly efficient design using very fast gate drivers and FETs, yields a significant increase in efficiency and reduces the need for cooling at low to medium power levels
  • Active freewheeling increases the response, stability and efficiency of your craft by actively braking the rotor during deceleration and converting the rotors kinetic energy to electricity.
  • Real time current limiting eliminates the need for current limiter calibration and provides a user settable safeguard against overload.
  • Improved starting procedure makes it plug and play with most motors. Start voltages and currents can be tweaked to improve starting further.
  • A new drive method secures ultra fast speed transitions without loosing sync, both during acceleration under power and during deceleration under active freewheeling.
  • Improved failsafe support on AutoQuad with CAN; if a motor is disarmed or stopped in flight, the controller will try to rearm and restart the motor.
  • Live telemetry is available over CAN in AutoQuad Systems – Displays for instance Power, RPM and Temperature in the ground control.
  • Improved Buck converter supply circuit for the logic means that its safe to supply the logic side from the main battery.
  • Direct USB support makes it easy to connect, setup, test and diagnose the ESC32 V3 with the new ESC32 configuation Utility (ECU) included with each ESC32 V3

[video=youtube;ABTS13ZF4hQ]https://www.youtube.com/watch?v=ABTS13ZF4hQ[/video]

Specifications

* PCB size: 34 x 25.6mm
* PCB weight : 5.7 grams
* Interfaces: USB, Serial, PWM, CAN
* Input voltage range 6 to 42 volts (2-10S lipo)
* Nominal max power 750 Watts continous, 1000W peak
* Absolute max power 1500 watts
* Nominal max current 40A
* Absolute max current 50A

Features

* Active freewheeling
* Live telemetry over CAN, USB or Serial
* Real time current limiter
* User configurable current limit
* Control via CAN, PWM, USB or Serial
* Closed loop RPM mode
* Servo mode (experimental)
* Closed loop thrust mode (experimental)
* 8 to 64 KHZ switching rates
* Improved error handling with AutoQuad flight controllers using CAN control
* Improved logic side supply eliminates the need for external 5V supply
* Speaker function


Ab sofort verfügbar:

Flyduino: http://flyduino.net/Autoquad-ESC32-V3
Viacopter: https://viacopter.eu/multirotor-shop/escs-speedcontrollers/esc32-v3-multicopter-store


Links:

AutoQuad ESC32 Configuration Utility (ECU)
http://autoquad.org/wiki/wiki/aq-esc32/esc32-configuration-utility/
Forum thread: http://forum.autoquad.org/viewtopic.php?f=26&t=4623

ESC32 Wiki
http://autoquad.org/wiki/wiki/aq-esc32/

ESC32 V3 YouTube Video Play List
https://www.youtube.com/playlist?list=P ... 41Lny9VfYP

[video=youtube;pxS4nKm0ha4]https://www.youtube.com/watch?v=pxS4nKm0ha4[/video]
 
Zuletzt bearbeitet:
kinderkram

kinderkram

Erfahrener Benutzer
#4
#4
El-dentiste hat gesagt.:
Wie geil ist das den mit der Sprache !!!! sehr cool. und ne saubere GUI
sollte mir für mein AQ Quad wohl dich mal ein paar ESC32 holen!!!
Zum Vergrößern anklicken....
Hat Flyduino auch bald in der Schaufensterauslage! ;)

Die Sprachausgabe is zwar ein cooles Feature, das Augenmerk liegt allerdings eher auf Sachen wie der sanfte Anlauf und saubere Steuerung großer Motoren wie die U8/170kV mit 29" Latten.

Z.B. beim niedertourigen Flappflappflapp (ca. 1:10) krieg ich immer Pipi inne Augen:

[video=youtube;rhT90Ueo3pw]https://www.youtube.com/watch?v=rhT90Ueo3pw[/video]
 
A

aBUGSworstnightmare

Erfahrener Benutzer
#5
#5
kinderkram hat gesagt.:
Hat Flyduino auch bald in der Schaufensterauslage! ;)

Die Sprachausgabe is zwar ein cooles Feature, das Augenmerk liegt allerdings eher auf Sachen wie der sanfte Anlauf und saubere Steuerung großer Motoren wie die U8/170kV mit 29" Latten.

Z.B. beim niedertourigen Flappflappflapp (ca. 1:10) krieg ich immer Pipi inne Augen:

[video=youtube;rhT90Ueo3pw]https://www.youtube.com/watch?v=rhT90Ueo3pw[/video]
Zum Vergrößern anklicken....
Wer will denn Niedertourig? Das geht auch anders:
[video]http://m.youtube.com/watch?v=AGLUZkh9brE[/video]
:cool:
 
Alveran

Alveran

Erfahrener Benutzer
#7
#7
sehr sehr nice ....

Dann hab ich auch gleich mal ne frage ... Is es mit denen möglich in einen Dual Input zu Betriebt? ... also nicht wirklich gleichzeitig ... aber so endlich wie bein den KISS30A ... wenn nix mehr am Main Input is .. dann springt der Fallback ein.
Die frage geht Richtung Redundanz :) ... oder ist da was anderes in der mache?
 
kinderkram

kinderkram

Erfahrener Benutzer
#8
#8
Theoretisch geht da mit dem CANbus einiges...
Unsere Entwickler haben auch schon an Redundanz gearbeitet, wobei die ESC entscheidet, welches Signal sie akzeptiert bzw. verwirft.

CAN ist so robust, dass ein Ausfall unwahrscheinlich ist, also ein Fallback auf PWM nicht unbedingt nötig - aber selbst das wär möglich.
Nur müsste dann bestenfalls eine identische FC mitfliegen, die aber eine niedrigere Priorität hat und im Normalfall keinen Einfluss haben darf. Erst wenn die Hauptkomponenten ausfallen, werden die Steuersignale der 2. FC akzeptiert.

Technisch ist das ein kniffliger Drahtseilakt, die Schwellenwerte festzulegen, damit das Umschalten in jeder Flugsituation reibungslos klappt.

Die in Österreich akzeptierte Lösung über ein Relais zwischen den FCs zu schalten, is jedenfalls keine große Hilfe.
Jede Form von Redundanz verkompliziert den gesamten Aufbau und baut dadurch neue Möglichkeiten für Fehlfunktionen ein.
Nicht nur, dass Abstürze im Ernstfall nicht verhindert, sondern dass sie sogar provoziert werden.
Und teuer wirds obendrein - ohne 100% Sicherheit zu bieten.
 
Alveran

Alveran

Erfahrener Benutzer
#9
#9
hmm leuchtet ein ...

Im Grunde müsste die V3 ein paar Daten von den 2 FC's bekommen .. und schauen ob die (sagen wir mal) +-10/30% gleich sind ... und dann entscheiden ob was faul ist / umschalten auf die 2te FC... und auch das der jeweiligen FC weiter geben und via Telemetrie Melden / RTL auslösen...

ja hast recht Kompliziertes Thema :) glaub da werd ich mal wieder in dem dafür vorgesehenen Threat posten ... (AQ7, ich warte :) )
 
P

phynix

Erfahrener Benutzer
#10
#10
Eine funktionierende Lösung um eine FC-Redundanz einfach(er) realisieren zu können wäre mein größter Wunsch bei den V3ern gewesen - insbesondere dabei solllte doch der CAN-Bus oder besser zwei parallele seine Stärken voll ausspielen können (Bi-directionalität, Robustheit, einfache Möglichkeit der galvanischen Trennung direkt in den Treibern, kommunikation der ESC untereinander...).

Die These, dass redundante FC die Flugsicherheit eher verringern als erhöhen mag im Einzelfall eines suboptimal aufgebauten Kopters stimmen, im Allgemeinen ist sie mM nach aber unhaltbar. Alle mir bekannten FC nutzen "Consumerelektronik" die prinzipbedingt eine vergleichsweise hohe Ausfallwahrscheinlichkeit hat (für sicherheitskritische Anwendungen). Gerade auch der AQ ist (leider) nicht besonders störresistent aufgebaut, dh z.B. EMI oder andere Spikes in den Signalleitungen können leicht zu ein Freezen der MCU führen. OK, nur noch eine CAN-Leitung im Vergleich zu 8 PWM Leitungen könnte dieses Risiko natürlich schon mal reduzieren. Es bleibt eine sache der Statistik - und bei zwei FC kann die theoretische Grenze der gesamten Ausfallwahrscheinlichkeit als das Quadrat der Einzelausfallwahrscheinlichkeit natürlich nicht erreicht werden, eine absolute Senkung des fatalen Gesamtrisikos jedoch schon. Dies geht umso besser, je Ausfallsicherer jede der FC für sich ist...

Ein Totalausfall einer FC, so dass sie gar keine Steuersignale an die ESC sendet (vermutlich der häufigste Fehler, tritt beim AQ bei mir leider auf) lässt sich mit einer zweiten FC und einer Umschaltung in den ESC recht einfach realisieren. Mikrokopter hat es implementiert und es funktioniert, wenn auch hier wohl eher auf die Anforderungen der Zulassung in A geachtet wurde und noch mehr Sicherheit möglich gewesen wäre. Mit den neuen KISS könnte es rudimentär funktionieren, allerdings fehlt dann natürlich die Rückmeldung der ESC an die FC. Ich könnte mir gut vorstellen, dass die Backup-FC mitbekommen muss, ab wann sie das Sagen hat damit die Regelung dann erst z.B. die PID-Schleifen anwirft.

Kritischer wird es bei der Erkennung einer Fehlfunktion einer FC wie zB einer divergierenden Lageerkennung durch defekte Sensoren oder einem Firmewarebug. Hier ist die potentielle Gefahr, insgesamt mehr Fehlerquellen die zu einem Absturz führen können einzubauen ungleich höher. SOETWAS wäre aber mal ein echtes Alleinstellungsmerkmal des AQ und würde seinen ursprünglichen professionellen Anspruch unterstützen ;).

Aber ich weiß, die Treibende Kraft hinter dem AQ projekt sind freiwillige Begeisterte und ich kann sehr gut nachvollziehen, dass neue Features und perfekter Flug viel interessanter sind und auch mehr Spaß machen zu implementieren als zunächst unsichtbare Sicherheitsaspekte die man auf dem Flugplatz und mit Fun-Coptern auch wirklich eher nicht braucht. Somit ist das zwar etwas schade, aber als Nutznießer von viel freiwilliger Arbeit darf und will ich mich darüber nicht beschweren. Vielen Dank also für eure Arbeit und ich werde die AQ Hardware auch in Zukunft weiter zu Spaßzwecken fliegen. ESC32V3 wird demnächst natürlich auch getestet :D !!
 
Zuletzt bearbeitet:
kinderkram

kinderkram

Erfahrener Benutzer
#11
#11
Theoretisch haben wir das schon alles durchgespielt.
Im CAN Verbund könnten mehrere Master werkeln und die ECSs entscheiden demokratisch, welchem Master sie vertrauen.
Oder ein ESC wird zum Anführer ernannt und entscheidet für die anderen mit, welcher Master akzeptiert wird.

Als letzte Reissleine bei einem Ausfall des CAN Bus könnte eine 3. FC mitfliegen (z.B. einfache MultiWii mit Gyros&ACCs - nur um den Vogel kontrolliert runter zu bringen), die über PWM mit den ESCs verbunden sind und solange ignoriert wird, bis die ESCs beide Master verwerfen und auf PWM umswitchen. Zu Testzwecken nimmt man dann nacheinander die Master vom Bus, wobei der Copter in jeder Situation fliegbar sein muss.

Selbst einen Failsafe Event könnte den ESCs signalisiert werden, die dann auf PWM gehen, an dessen FC am besten ein 2. parallel gebindeter Empfänger hängt. Die CAN Master entscheiden dann, den ESCs das Signal zu schicken, wenn bestimmte Voraussetzungen erfüllt werden. Dazu gehört auch, dass die ESCs den Status der PWM FC mitbekommen und anhand einer Summe von Qualitätsfaktoren ihre Entscheidungen treffen.

Die Rechenpower auf den ESCs wäre da. Die Festlegung, wer wann wo wieso was entscheiden darf, is die hundskniffelige Sache dabei.

Da sind mehrere von unseren Entwicklern dran - nur standen jetzt erstmal andere Sachen im Vordergrund wie Robustheit und sauberer Lauf...
 
P

phynix

Erfahrener Benutzer
#12
#12
Hm, hört sich erstmal gut an, aber erst wenn es für die allgemeinheit verfügbar ist wird es interessant da nun schon seit zwei Jahren "da jemand dran ist". Mit den V3ern kann ich jetzt auch nicht mehr selber in der firmeware rumpfuschen... was ich aber auch nur zu Spaßzwecken machen sollte. Denn jemand der die Firmeware ursprünglich mitentwickelt hat kann soetwas bestimmt sicherer und zuverlässiger implementieren als ich mit meinen begrenzten DIY-Programmierkentnissen. Gerne bringe ich aber prinzipielle Überlegungen mit ein und teste sowas ggf auch gerne!

mM nach sollten zwei FCs sich aber nicht den Bus zu den ESC teilen besser wären zwei parallele ... oder doch noch PWM als Backup. Auch wären CAN-transciver mit integrierter galvanischer Trennung eventuell nett...
 
kinderkram

kinderkram

Erfahrener Benutzer
#13
#13
Wenn nur interessant wär, was allgemein verfügbar ist - wo bleibt da der Forschergeist? ;)
Fallback auf PWM dürfte das kleinste Problem sein.

Aber allein die verschiedenen möglichen Ausfall- und Rettungsszenarien durchzuspielen, passt auf keine Flipchart.

Und sein wir mal ehrlich: wär in Ösiland nich die Forderung nach "Redundanz" aufgetaucht, würde niemand ernsthaft überlegen, FCs zu stapeln und sich einen Kabelbaum an die ESC zu schweißen. :D
 
Alveran

Alveran

Erfahrener Benutzer
#14
#14
kinderkram hat gesagt.:
Wenn nur interessant wär, was allgemein verfügbar ist - wo bleibt da der Forschergeist? ;)
Fallback auf PWM dürfte das kleinste Problem sein.

Aber allein die verschiedenen möglichen Ausfall- und Rettungsszenarien durchzuspielen, passt auf keine Flipchart.

Und sein wir mal ehrlich: wär in Ösiland nich die Forderung nach "Redundanz" aufgetaucht, würde niemand ernsthaft überlegen, FCs zu stapeln und sich einen Kabelbaum an die ESC zu schweißen. :D
Zum Vergrößern anklicken....
indeed ... indeed :) ...

Trozdem wär es ziemlich geil eine Alternative zu MirkoCopter zu haben ... so wie ich das zurzeit mitbekommen habe, sind sie zur zeit Konkurrenz los (ja außer die komische DJI Relai Platine da, die eh nicht akzeptiert wird) ...

naja genug darüber geredet :) .. kommt zeit kommt Redundanz ^^
 
P

phynix

Erfahrener Benutzer
#15
#15
@kinderkram: mit allgemein verfügbar meinte ich, dass die "Überlegungen" beim AQ für den allgemeinen AQ-User verfügbar werden :). War etwas unglücklich ausgedrückt. Und mit dem Forschergeist ist es ja genau wie ich meinte: neues ist das, was interessanter ist ;).

Klar, alle Ausfallszenarien durchzuspielen geht nicht, denn das würde ja in Richtung 100%ige Sicherheit gehen, das kann halt schon theoretisch nicht funktionieren. Aber sich hierzu Gedanken zu machen, zu dokumentieren und Sinnvolles zu implementieren würde mM nach den Unterschied von Bastel- und Hobbycoptern bzw. RTF-Spielzeugen (DJI) wie sie heute eigentlich jeder fliegt zu professionellen Arbeitsgeräten ausmachen. Leider habe ich sowas auf dem zivilen Markt noch nicht gefunden. Auch überteuerte kommerzielle Lösungen scheinen leider sicherheitstechnisch nicht zu Ende gedachte Elektronik zu verwenden, die sehr dicht an den aus Hobbyprojekten entstandenen Lösungen ist. Dies spricht einerseits wirklich für OpenSource, aber genau hier ist vielleicht auch eben die Grenze erreicht: OpenSource lebt hier von der Faszination (und dann siehe open :D).

Und Überlegungen zur Redundanz habe ich seitdem ich das erste mal eine Kamera auf etwas ferngesteuertem montiert habe (lange bevor dem Gesetz in A) ... eben so wie eine "Reserve" eigentlich überall da wo sicherheitskritische Systeme vorhanden sind der Standart ist (sei es Luftfahrt, Nautik, Medizin, Robotik, IT...). Richtig konkret wurde das dann mit meinen spontanen Ausfällen des AQ im Flug die bis heute nicht aufgeklärt werden konnten.
 
Y

Yups

Erfahrener Benutzer
#16
#16
ESC32V3, fein!
Endlich mal ein ESC das anständig läuft. Mit dem V2 hab ich bis heute regelmäßig Probleme mit dem Anlaufen der Motoren... (und teilweise Sync Verluste im Flug)

... aber was ist aus eurer OpenSource Idee geworden? Bei Quatos hab ich das Lizenzmodell ja noch halbwegs verstanden, doch jetzt ist auch die ESC32V3 Entwicklung Closed Source? Das Konfigurationsprogramm auch mit Lizenzierung und kostenpflichtig in Verbindung mit der V2. Auch die AQ Firmware wurde bei google code seit Februar nicht mehr aktualisiert ?? Gut, jetzt ist google code eh Geschichte, aber es gibt soweit ich es finden konnte auch keinen Nachfolger.

Kann mich mal jemand kneifen?
 
P

phynix

Erfahrener Benutzer
#17
#17
Ja das mit den ESC32v3 Code ist schade, weil man dann nicht mehr selber drin rumpfuschen kann ... OpenSource Firmeware geht halt leider eher schlecht wenn man mit der Hardware Geld verdienen will (oder vielleicht auch nur Ausgaben decken). Dann bräuchte man auch OpenHardware und seeeehr viel Idealismus!

Wegen dem Code von der Mainplatine hieß es mal das der auf GitHub kommt... und dort freigegeben wird wenn die Portierung vollständig ist.
 
keilie

keilie

Erfahrener Benutzer
#18
#18
muss auch mal was positives sagen, ist es jetzt mal ein super ESC was auch 10s kann und dazu noch bezahlbar ist :)
 
Y

Yups

Erfahrener Benutzer
#19
#19
phynix hat gesagt.:
Ja das mit den ESC32v3 Code ist schade, weil man dann nicht mehr selber drin rumpfuschen kann ... OpenSource Firmeware geht halt leider eher schlecht wenn man mit der Hardware Geld verdienen will (oder vielleicht auch nur Ausgaben decken). Dann bräuchte man auch OpenHardware und seeeehr viel Idealismus!

Wegen dem Code von der Mainplatine hieß es mal das der auf GitHub kommt... und dort freigegeben wird wenn die Portierung vollständig ist.
Zum Vergrößern anklicken....
Ich vermute es liegt am Mitwirken von Felix (ronco), der sicherlich Teile seines KISS und UltraESC Codes da eingearbeitet hat und diesen natürlich NICHT beim Chinesen wiederfinden will. Trotzdem geht Autoquad ganz schön in Richtung ClosedSource, schade eigentlich. Noch viel mehr ärgere ich mich über die Lizenzgebühren für das ESC32 Tool. Da hat man vor einiger Zeit für gutes Geld die ESC32V2 gekauft und guckt jetzt in die Röhre - oder darf nochmal 45$ nachschieben...

Dauert aber sehr lange bis es auf Github kommt, scheint wohl niemandem so richtig wichtig zu sein. Über ein halbes Jahr keine öffentliche Firmwareentwicklung ist sehr schade!
 
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten