Arduino IDE basierte Plattform Pro und Contra

  • Hallo zusammen!

    Nach einigen anfänglichen Schwierigkeiten habe ich mich in die Materie so langsam eingefunden und auch schon den ersten Antweight Wedge mehr oder weniger fertig.
    Dabei musste ich feststellen das besonders die geeigneten ESC für die N20 Brushed ziemlich teuer sind. Da es ein kleines Hobby sein soll und ich im Wahn schon 300 € für die Teile von 3 weiteren Ants ausgegeben habe
    fing ich dann doch recht schnell an nach einem billigen Ersatz für meine Fingertech Tiny v2 Lösung zu suchen. DasMicro gekauft und als (semi)schrecklich befunden.
    Da ich Die Fingertech ESC am billigsten bei exp-tech gekriegt hatte hab ich da mal weiter gestöbert und stieß auf einige Motordriver die geeignet waren und nicht soooo viel kosteten.
    Klar ich kann auch die 65€ bei IBF ausgeben und bin save aber dann bin ich bei 4 Bots die bei mir in Planung sind auch schon bei 260€ nur für die ESCs... Wobei ich auch noch speziellere Varianten anstrebe, die überhaupt nicht abgedeckt werden.
    Nach ein wenig Googeln ergab sich dann eine ganz neue Welt. Arduino basierte Combat Bots. Manche sogar mit eigenem Sender-Empfängermodul. Anleitung
    Da ich zum Beispiel derzeit einen Grabber baue, der mit zwei unabhängigen Servos arbeitet (von denen einer im ideal Fall automatisiert laufen soll...) scheint die gängige Praxis ja nicht ganz so kostengünstig. Wenn man dann noch bedenkt das andere ganz andere Vorteile wie Titanpanzerung etc haben will ich gar nicht so viel Geld für etwas ausgeben das vielleicht nach 5 Sekunden verschrottet wurde.

    Die Idee ist also eine DIY Plattform auf Basis des ATmega 328p zu machen die als ESC controller für brushed und brushless bzw. Servos arbeitet, dies am besten zum Stecken (ergo weniger Kabelsalat und Empfindlichkeit)
    Mototreiber Boards gibt es in hülle und fülle und auch die Codes für Arduino sind in allen Formen und Farben vorhanden.
    Mit Multiplexern kann man da auch noch mehr Motoren dran klemmen und kann eine Plattform für viele Gewichtsklassen machen.
    Projekte wie ein Arduino Radar zum Tracken des Gegners oder ähnliches wären dann auch viel einfacher zu realisieren Das Video

    Vielleicht haben hier ja einge Leute ein paar zusätzliche Ideen?

    Ich will IBF hier auch überhaupt nicht sein Wasser abgraben. Nur würde ich auch gerne mal komplexere Bots bauen als nur die 3 Ch Esc erlauben. Auch wenn ich damit auf seine Qualität verzichten würde.

    Gruß

    • Offizieller Beitrag

    Dass hier mal ein anderer Weg über "käufliche" Controller probiert wird, finde ich gut!
    Krümmel hatte mit dem Arduinio schon mal einen Regler programmiert. Ich kann mich irren, aber ich glaube, das Problem war, mehrere Kanäle gleichzeitig "abzufangen" bzw. "takt-gerecht" anzusteuern. Bin mir jetzt aber nicht mehr sicher, wo das Problem genau lag und wie es umgangen wurde.

    Wenn ich jetzt auf ein paar befürchtete Probleme aufmerksam mache, dann nicht, weil ich gegen das Projekt hetzen will, sondern dass Du vielleicht dann in eine oder mehrere "Fallen" oder Probleme weniger stolperst. => Also bitte nicht negativ betrachten, sondern als Unterstützung !

    Die Idee ist also eine DIY Plattform auf Basis des ATmega 328p zu machen die als ESC controller für brushed und brushless bzw. Servos arbeitet, dies am besten zum Stecken (ergo weniger Kabelsalat und Empfindlichkeit)

    Die Idee, den Empfänger aufzustecken, hatte Replikator bei einem Fahrtregler auch schon mal realisiert. Geht. Aber man ist dann auf einen Empfängertyp fixiert. Und: Je nachdem, ob jemand lieber Kreuzmischer haben will oder mit Panzersteuerung fährt, sind andere Empfängerkanäle zu verwenden. Du musst also in der Software eine "Belegungs-Matrix" einbauen, um dann zu entscheiden, welcher "Eingangskanal des Fahrtreglers" mit "Empfängerkanal" verbunden werden soll.

    Drahtverhau und Kabelsalat vermeiden ist eine gute Option! Es ist wirklich unglaublich, wieviel Drähte hier in einem Ant untergebracht werden müssen...

    Ich will IBF hier auch überhaupt nicht sein Wasser abgraben. Nur würde ich auch gerne mal komplexere Bots bauen als nur die 3 Ch Esc erlauben. Auch wenn ich damit auf seine Qualität verzichten würde.

    Du gräbst mir nicht das Wasser ab . ;)

    Ich mache die ganze Fahrtregler-Entwicklung eigentlich nur, um unser Hobby ein bißchen weiter zu bringen und dass bei einem Turnier die Bots nicht ständig wegen durchgebrannten Fahrtreglern ausfallen.
    Qualität bei den Platinen und verwendeten Komponenten kostet leider etwas mehr Geld, als fertige Baugruppen aus China. "Verdienen" tu ich damit praktisch nichts, ausser man stuft für das Zusammenlöten einen effektiven Stundenlohn von 2€ als "Gewinn" ein, der dann auch noch versteuert werden muss.

    In der Richtung kann ich Dich also nur ermuntern, eine neue Generation von Fahrtreglern zu entwickeln und die dann für unsere Gemeinschaft zu bauen bzw. weiterzugeben.


    Ein kleiner Tipp bei der Entwiclung Deiner Software: Das Problem ist die Ansteuerung von den Endstufen-MOSFETs bzgl. dem Timing. Wie schon öfters im Forum darauf hingewiesen, muss der angesteuerte Motor von der vorherigen Fahrtrichtung/Drehrichtung erst einmal gestoppt werden (Motorbremse durch gepulsten Kurzschluss der Motorwicklungen), bevor er dann in Gegenrichtung bestromt werden darf.
    Die kleinen Getriebemotörchen von den Ants sind da vielleicht noch gutmütiger gegenüber den MOSFET-Endstufen. Aber sobald Du das Konzept eines "Baukastens" weiterverfolgst und fettere MOSFETs für größere Motoren anhängst, wird das ein nicht zu unterschätzendes Problem.

  • Danke erstmal für die Antwort.

    2€ Sind echt nicht viel :pinch: und danke für den Input. Kritik fasse ich erstmal auch nie negativ auf. Also immer her damit. Wenns nicht funzt dann ist das so. Das kann man auch gerne sagen.

    Also für den Anfang sehe ich das Ganze auch nicht so als Entwickelung sondern als "klauen" vieler einzelnen Projekte die so im Web rumfliegen.
    Der Empfänger und so weiter werden am Anfang eh separat sein. Ich hab mit der Recherche eher aus finanziellen Gründen angefangen.
    Vielleicht haben ja noch ein paar mehr Leute lust auf Brainstorming.

    Hier einmal ein paar Dinge die ich so gefunden habe. Vielleicht hat ja der ein oder andere Interesse mit zu machen.

    Arduino Rx Signal auslesen: Anleitung + Anleitung 2

    beliebiges brushed DC Motor Shield: Shield


    Servo Library Arduino: Library


    Arduino multiplexing: Anleitung mit LED Matrix


    Arduino selber bauen: Anleitung


    Es ist nur so eine Idee die ich jetzt nebenbei verfolgen werde. Da es eh alles Open source ist werde ich das auch weiter so halten.

    • Offizieller Beitrag

    mal als absoluter elektro- und programmierlaie:
    Irgendwo las ich mal, man könne servos auch direkt am Empfänger anschließen, und die ziehen den Saft dann auch aus der Versorgung des Empfängers.
    Je nach Größe des servos und Beanspruchung ist das evt. eine doofe Idee, keine Ahnung. Nur mal eingeworfen, falls das geht spart das natürlich enorm kosten, Material und Platz im bot

  • Ich antworte mal als RC Laie

    Ja oder man bezieht nur das Signal vom Rx und den Strom über einen seperaten Schaltkreis. Aber wenn man jetzt zum Beispiel mehrere Servos (4-16) für was weiß ich nicht einbauen will bleibt man schnell auf der Strecke.
    Es wäre ja auch einfach schön nur das Gesamtsignal also PPM über einen Draht in den Controller zu Füttern und Damit dann ALLES zu steuern bzw. als eine Art Router den man einstellen kann.
    Wenn man dann eine Library erarbeitet hat in der es einfach das Copy-Paste von ein paar Zeilen Code aus einer Wiki ist man am Ende wesentlich flexibler und hat ganz neue Möglichkeiten.

    • Offizieller Beitrag

    Stimmt natürlich, ging mir jetzt nur um den Speziellen Fall Ant mit 1-2 Servos + Fahrantrieb.
    Langfristig gesehen wäre sowas natürlich besser und vor allem vielseitiger, aber da ich absolut null Ahnung von sowas hab, kann ich da wenig zu beitragen und auch nicht einschätzen, wie viel Aufwand das wäre.

  • Das werde ich dann sehen. Im September hole ich mir einen Arduino Nano und das dazu gehörige Shield und teste.
    Erst müssen die beiden Ants fertig die ich in der Werkstatt habe. Aber da ich eh das Coden lernen muss...

    Ich hoffe einfach mal auf weitere Beiträge

    • Offizieller Beitrag

    Irgendwo las ich mal, man könne servos auch direkt am Empfänger anschließen, und die ziehen den Saft dann auch aus der Versorgung des Empfängers.

    Das ist die einfache Art, dass der Servo über den Plus-Anschluss vom Empfänger seine Versorgungsspannung bezieht.
    Problem ist, dass ein Servo u.U. 1 bis 2 Ampere will. Die Versorgungsspannung kann dann ganz schnell mal zusammenbrechen.
    Und: Wenn nicht genügend Strom nachgeschoben werden kann, dann kann ein "Billig-Servo" u.U. seine eingestellte Soll-Position nicht erreichen. Er zieht dann ständig Strom, kommt aber nicht vom Fleck. Der Motor wird heiß.

    Ich rate immer, dass bei Verwendung von Servos eine separate Spannungsversorgung nur für die Servos bereitgestellt wird. Der Empfänger kriegt seine 5V und mit der Elektronik im Fahrtregler ist das eine stabile Sache. Da gibt es dann keine Spannungseinbrüche oder "Spikes", die die ganze Elektronik durcheinanderschütteln kann

    Es wäre ja auch einfach schön nur das Gesamtsignal also PPM über einen Draht in den Controller zu Füttern

    Ds wäre auch mein Wunsch, endlich mal kompatible Empfänger zu kriegen, die nur eine Steckbrücke zum Binden und dann einen "Datenausgang" haben. *schwelg*. Das würde das ganze Empfängersignal-Handling drastisch vereinfachen.

    • Offizieller Beitrag

    Ds wäre auch mein Wunsch, endlich mal kompatible Empfänger zu kriegen, die nur eine Steckbrücke zum Binden und dann einen "Datenausgang" haben. *schwelg*. Das würde das ganze Empfängersignal-Handling drastisch vereinfachen.

    Das gibt es doch schon lange: https://www.banggood.com/de/search/ppm-receiver.html?sbc=1
    Wobei sich ppm nie so richtig durchgesetzt haben, weil die Fernsteuerungshersteller eigene, leistungsfähigere serielle Übertragungssysteme entwickelt haben (z.B. sbus).

    Die Stromversorgung für Servos sicherzustellen ist eigentlich kein Problem. In vielen Fällen reicht es schon einen Kondensator an den Empfänger anzuschließen. Ansonsten gibt es aus dem rc-heli-Bereich sehr leistungsfähige BECs (10A+), oft auch schon in ESCs (Castle Talon, Hobbywing Platinum, Kontronik...) integriert. Speziell beim Ant würde ich aber schlichtweg hv-Servos verwenden und die direkt aus dem 2s Akku versorgen. Die meisten Empfänger können auch 8,4v.

    Ansonsten sicherlich ein interessantes Projekt. Ich hatte überlegt mich bei meinem nächsten Raptorweight an etwas Ähnlichem zu versuchen, aber in diesem Fall wäre es deutlich teurer geworden als die Optionen von der Stange. Ein Arduino Nano ist auch schon recht groß für die Bezeichnung "Nano"... Und für eine Eigenbaulösung fehlt mir hinten und vorne das E-Technik Wissen.
    Und weitere Ant-Escs: Vex29, Nanotwo von Team Nuts,Desc von Endbots, Botbitz, awesc von Team arc
    Außerdem gibt es diverse firmwares online um günstige brushless esc auf brushed umzuprogrammieren.
    Edit: Cosmin bietet umprogrammierte Kingkong 12A mit selbstgeschriebener firmware für brushed an.
    Hier eine andere Firmware für die 12A: https://gitlab.com/alexmordue/brushed_tgy
    Die alten botbitz codes: https://launchpad.net/brushed
    Edit2: Megabrush: https://www.questionabledesign.xyz/austin/2017/9/…eed-controllers

  • Ah das sind sehr interessante Links.
    Der PPM hack für Arduino ist in einem der Links versteckt die ich weiter oben gepostet habe. Besser noch man hat die Rx die direkt PPM ausgeben.
    Für das warum habe ich nur eine Antwort: neue Möglichkeiten!
    Für Antweight ist so eine Lösung bestimmt ein overkill aber ab Beetleweight lässt sich damit schon einiges machen. Sogar "eigene" Servos mit Geared Brushed und extra Poti, falls die Kohle für die mit mehr Kraft nicht reicht.
    Die jeweiligen Codes sind ja schon im Netz.
    Ich arbeite z.B. gerade an einem Fahrgestell das sich um 90° drehen kann. Aber wie ich schon sagte: Alles eine Sache der Zeit. Es wird bestimmt noch eine weile dauern bis ich was konkretes auf dem Gebiet Arduino habe.
    Wollte mal hören was die alten Hasen alles so zu sagen haben :)

    • Offizieller Beitrag

    Das gibt es doch schon lange: banggood.com/de/search/ppm-receiver.html?sbc=1
    Wobei sich ppm nie so richtig durchgesetzt haben, weil die Fernsteuerungshersteller eigene, leistungsfähigere serielle Übertragungssysteme entwickelt haben (z.B. sbus).

    Hm... PPM war für mich bishrr nur ein anderes Übertragungsprotokoll. Hat meine alte Futabe FC16 auch drin. Man braucht halt spezielle Empfänger. Aber an den Ausgängen der Empfänger wird immer noch für jeden Kanal das pulsweitenmodulierte Signal ausgegeben.

    SBus habe ich schon mal gelesen. Hab' das aber als internes Protokoll zwischen dem Empfänger und seinem Satelliten-Empfänger eingestuft. => Kann mich irren, muss mal nachforschen. Vor allem der Aufbau des Protokolls wäre interessant.


    Die Stromversorgung für Servos sicherzustellen ist eigentlich kein Problem. In vielen Fällen reicht es schon einen Kondensator an den Empfänger anzuschließen.

    Da muss ich jetzt etwas widersprechen. :D Ein Kondensator (Elko) kann helfen, dass der Strompuls beim Anlaufen der Motoren überbrückt wird. Aber wenn der Servo verzweifelt um 2A bettelt, damit er seine Brücke abgleichen kann und die Soll-Position erreicht, der BEC aber nur ein halbes Ampere bereitstellt, dann hilft ein Elko nicht.


    Ansonsten gibt es aus dem rc-heli-Bereich sehr leistungsfähige BECs (10A+)

    Es ist die Frage, was man will. 10A an den Empfänger abrufbar machen? Bei einem kleinen Bug in der Verdrahtung (Bei Modellfliegern oder RC-Cars weniger, bei unseren Schaukampfroboter durchaus leichter gegeben) sorgen die 10A für eine gute Rauchentwicklung bei den dünnen Drähtchen bzw. der Leiterbahn im Empfänger.

    Ich gehe lieber den Weg, für die Elektronik der Fahrtregler und des Empfängers eine kleine, aber stabile 5V-Versorgung bereitzustellen. Für externe Servos dann eine separate Versorgung.

    ab Beetleweight lässt sich damit schon einiges machen.

    Um den oben angesprochenen Punkt zu erweitern: Bei meinem Beetleweight-Fahrtregler ist für den dritten Empfängerkanal (für Waffe bzw. Servo) ein eigener Spannungskonstanter spendiert. Der kann auch 1A (2A Peek), statt der Konstanter für die Elektronik, der wurde bewußt auf 0.5A begrenzt.

    Das Empfängersignal für den Servo wird im Fahrtregler eingespeist und über den Controller "umgesetzt". Es gibt einen dreipoligen Stecker, dort wird dann der Servo angesteckt. Also statt direkt am Empfänger, jetzt am Fahrtregler.
    Vorteile:
    - Eigene 5V-Versorgung, wenn die Zusammenbricht, ist der Rest der Elektronik immer noch funktionsfähig
    - Über den Controller kann ich das Empfängersignal "begrenzen" oder "zoomen". :D;) Die Funken liefern ein Signal zwischen 1.0 und 2.0ms . Die Servos können aber einen höheren Drehwinkel , wenn man sie mit kürzeren oder längeren PWM-Pulsen ansteuert. Über die PC-Software kann das "Begrenzen"/"Zoomen" eingestellt werden. Also indirekt den Servo ein bißchen "tunen". :D
    => Ist zwar jetzt o.o.t., aber ich wollte Dir die Anregung mal feierlich übergeben. ^^

  • Ja so in etwa hatte ich das auch gedacht! (Also das was IBF geschrieben hat.) Signal vom Rx an den Controller. PPM deshalb weil es ja das gesamte Signal ist das alle Kanäle wiederspiegelt.

    Hier ein paar Links: Instructable, Ein Code für alle Signale und nochmal der Link von weiter oben

    Es lohnt sich das mal anzuschauen. Ich kenn mich ja nicht so dolle aus mit RC aber es scheint bei DSMx auf PPM hinaus zu laufen
    und da braucht man für das Signal nur noch 1 Kabel zum Controller +2 Kabel für den Saft des Rx und da sind es egal wieviel Kanäle man hat.

  • Ach ja! IBF als ich gesehen habe das du PIC´s auf deinen Boards benutzt hätte es bei mir ja aufleuchten sollen!
    Ein umstieg auf die Atmega 8 Reihe würde hier ja quasi alles von mir gedachte in viel besserer Form vorweg nehmen!
    Atmega 8 hat durch das ganze Arduino brimboriom ein Masse an Codes im Netz die alles abdecken...

    Nur so ein Einwurf :)

    • Offizieller Beitrag

    Atmega 8 hat durch das ganze Arduino brimboriom ein Masse an Codes im Netz die alles abdecken...

    C-Code sollte sich wenns nur um die Logik geht, sowohl für den PIC als auch für den AVR compilieren lassen, wenns nur da drum geht.
    Meist dient sowas aber eh nur der Inspiration - zumindest ich finde es ausgesprochen ekelhaft, Fehler im Code anderer Leute zu suchen;
    da schreibe ich das lieber selber, dann weiss ich wenigstens, was man sich dabei gedacht hatte...

    LG
    -Michael

    • Offizieller Beitrag

    Ein umstieg auf die Atmega 8 Reihe würde hier ja quasi alles von mir gedachte in viel besserer Form vorweg nehmen!

    "Viel besserer Form"? :D
    Ich weis, dass die meisten Jung-Programmierer mit Atmel "verseucht" werden. ;) Aber der PIC ist ein RISC-Prozessor und wird massenweise in der Industrie eingesetzt, weil er "stör-unempfindlich" ist. Die Probleme, die unsere Software-Truppe in der Arbeit mit TI's, NECs und Atmel hat, die kenne ich nicht. Der PIC kann halt nicht ständig mit irgendwelchen neuen Generationen aufwarten, die sich mit Flahs, RAM und sonstwas ständig überholen. Er ist halt ein richtiges Arbeitstier.

    Atmega 8 hat durch das ganze Arduino brimboriom ein Masse an Codes im Netz die alles abdecken...

    Lass' Dich nicht täuschen, wenn hier eine "Masse" an Codes herumschwirrt. Ist wie beim Fußball. Du kannst aus der ganzen Welt 11 super Spieler zusammenholen. Aber das ist noch keine Mannschaft. Das muss zusammenpassen.
    Der Ur-Code, mit dem ich vor 16 Jahren angefangen habe, den allerersten Fahrtregler zu programmieren, ist im Prinzip immer noch enthalten. Inzwischen aber von 2 PWM auf 5PWM erweitert, EEPROM-Parameter eingeführt, I2C-Kommunikation mit einem Slave-Modul,... usw. Das muss zusammenpassen. Ich kann nicht einfach einen Code von irgendwoher einbinden und dann hoffen, dass nicht an anderer Stelle was abgeschossen wird.

    Nur so ein Einwurf

    Klar. Ich weis so technische Diskussionen auch zu schätzen ! Da stecken keine persönlichen Angriffe oder Zurechtweisungen dahinter. (Hab' in der Truppe ja auch immer die erfrischenden Diskussionen mit Ralf. Wir haben andere Ansichten bzgl. Motoren etc..... Das bringt für mich auch neue Aspekte, wenn ich mal einen "Gegenpol" habe. )

    C-Code sollte sich wenns nur um die Logik geht, sowohl für den PIC als auch für den AVR compilieren lassen, wenns nur da drum geht.
    Meist dient sowas aber eh nur der Inspiration - zumindest ich finde es ausgesprochen ekelhaft, Fehler im Code anderer Leute zu suchen;
    da schreibe ich das lieber selber, dann weiss ich wenigstens, was man sich dabei gedacht hatte...

    Das ist auch meine Erfahrung. Ich habe einmal eine Routine zum Einlesen von externen I2C-EEPROMs eingebunden. War eine totale Bauchlandung. Dann eine Routine aus dem Netz verwendet. Klappt auch nicht. Sogar mit dem Oszi die Pulse aufgezeichnet, analysiert und festgestellt, dass das nie im Leben mit dem EEPROM schon mal zusammen hat funktionieren können.
    Also doch wieder selber eine Routine geschrieben und "die Ports wackeln lassen".

    Bitte immer bedenken: Die meisten Probleme bei einer komplexeren Software sind nicht die Grundstrukturen, sondern "Timing-Sachen". Dass irgendwo was verloren geht, weil eine Routine mit Delays herumzuckelt, usw.... Also lieber von vorne bis hinten alles selber schreiben und bei einer Erweiterung oder Fehlersuche genau wissen, wo man hinlangen muss. ;)
    Die Fahrtregler-Software ist ziemlich hardware-nah programmiert, weil ich mehrere Timer gleichzeitig bearbeiten muss. Und es gibt eben Eigenschaften im Prozessor, die sind nirgends dokumentiert. Wirken sich normalerweise nicht aus, aber irgendwann klappt halt mal was nicht. (Z.B. gleichzeitige Datenübertragung von I2C und Serial. Da werden ein paar Bits "verzögert" ausgegeben und schon kracht's . Abhilfe: Die beiden Routinen gegenseitig verriegeln. Ist kein Problem, wenn man's weis. Aber die "Netz-Routinen" wissen es eben nicht... :rolleyes: )

    • Offizieller Beitrag

    Ich weis, dass die meisten Jung-Programmierer mit Atmel "verseucht" werden. Aber der PIC ist ein RISC-Prozessor und wird massenweise in der Industrie eingesetzt, weil er "stör-unempfindlich" ist.

    Das dürfte heute nimmer passieren, nachdem Atmel ja von Microchip übernommen wurde.
    Ich weiss, es ist ein Glaubenskrieg - und ich bin AVR-Mensch. Meiner Erfahrung nach laufen die AVRs genauso stabil (nicht: besser, wie viele behaupten) wie die PICs - wobei es bei den PICs viele mit erheblich mehr Leistung als die AVRs gibt, das muss ich zugeben. Habe ja auch beruflich einige PIC-Projekte machen müssen.
    Ich persönlich glaube, dass es einfach Geschmackssache ist, und jeder mit "seiner" Plattform, wenn er sie denn beherrscht, die für ihn idealen Resultate erzielen können wird.
    Erinnert mich an die früheren Glaubenskriege zwischen 65xx- und Z80-Anhängern... (jaja, so alt bin ich schon...) :)

    LG
    -Michael

    • Offizieller Beitrag

    Erinnert mich an die früheren Glaubenskriege zwischen 65xx- und Z80-Anhängern... (jaja, so alt bin ich schon...)

    Gib Fünf ! :thumbup:
    Je nachdem, welchen Informatik-Lehrer man hatte, wurde man auf den Prozessortyp "ein-geeichst". Wobei mir später im Stuidum der 8051 von Siemens am Besten gefallen hat.

    Ich weiss, es ist ein Glaubenskrieg

    Ja, und den werden wir hier garantiert nicht bis zum bitteren Ende ausfechten . :D:saint:
    In der Arbeit sind unsere Softies mittlerweile auf Arm-Prozessoren umgestiegen. Ist nur immer traurig zu sehen, wenn sie nach den EMV-Prüfungen mit trauriger Mine zurück in's Labor kommen....

    Hmm, hatte nicht Alex bereits mit einem arduino hierfür bereits alles fertig?

    Ja, Alex hat viele Sub-Module für Arduino entwickelt.
    Hier seine Startpage: https://www.lxrobotics.com/

    Und das wäre z.B. ein Modul für einen Brushless-Antrieb. (Die verwendeten MOSFET-Halbbrücken kommen mir irgendwie bekannt vor. :rolleyes: ) Über die angegebene Stromstärke und die fehlenden Leiterbahn-Verstärkungen lässt sich bestimmt noch diskutieren.... Aber prinzipiell gibt es sowas schon.
    https://github.com/lxrobotics/BrushlessMotorshield

    • Offizieller Beitrag

    In der Arbeit sind unsere Softies mittlerweile auf Arm-Prozessoren umgestiegen. Ist nur immer traurig zu sehen, wenn sie nach den EMV-Prüfungen mit trauriger Mine zurück in's Labor kommen....

    Wir hatten früher ARMs, jetzt aber in so gut wie ellen Geräten MIPS-Prozessoren. Die EMV-Ärgernisse sind in den allermeisten Fällen gar nicht die CPUs, sondern irgendein Murks aussenrum (Schaltregler, blöd verlegte Leitungen...)

    LG
    -Michael