Anleitung Projekt Unvernunft Hyperfire - Ich bastel dann mal los

[AMORph]

Hallo zusammen,

hier möchte ich euch gerne auf dem Weg zu meiner Smarten Hyperfire mitnehmen.
Dies hier wird eine längere Reise da viel zu tun ist.



Aus meiner Standart Hyperfire habe ich begonnen, alle Mechanischen Triggersperren zu entfernen.

Hier die Sperre für den Abzug von dem RevTrigger:



Diese habe ich komplett entfernt und den Trigger mit einer AR Feder von einer Maverick REV-6 aus der Bastelkiste federnd wieder eingebaut.





Weiter ging es mit der Sperre des Abzugs durch das Magazin,
hier musste ich nur folgendes teil entfernen und wieder zusammenbauen.











Nachdem nun die 2 Mechanischen Sperren ausgebaut waren, habe ich die Motoren ausgebaut und von den Schaltern die Position und Kabelfarben notiert.
(Im Späteren verlauf auch die ein und ausgänge am Arduino hinzugefügt.




Rev Trigger
D2
schwarz
blau
gelb/schwarz

Abzug Trigger
D3
schwarz
grau
grau

Magazin erkennung
D4
schwarz
blau
gelb

Jam door
D5
braun
lila
gelb

flywheel motor
D6
rot
braun

belt motor
D7
schwarz
rot

Alle Kabel zu den Steckern habe ich von der Platine abgeschnitten und da ich Lötfaul bin in einen Stecker gepinnt



Danach alle Taster im eingebauten Zustand mit dem Multimeter durchgepiepst. Effektiv habe ich micht dann dazu entschieden bei allen Tastern die mitlere und untere Ader zu nutzen.



Von jedem Taster gehen nun zwei Kabel zum Arduino, jeweils eins davon wird an einen Pin vom Arduino und das andere an Masse angeschlossen.
Dies ist der einfachste Weg, da der Arduino den ich verwende eingebaute Pullupwiederstände hat.

Somit konnte das Coden beginnen und etwa 2 1/2 Stunden Coden später. Temporär habe ich die Motoren über ein Relaismodul mit der Batterie verbunden. Wurde die Funktion des Blasters wieder hergestellt.



Den Code für den Arduino werde ich jeweils als *.txt hier anhängen. (Achtung im Code steckt schon der ein oder andere Leak)

Damit sind 2 Bastelabende vorbei. Heute feile ich vieleicht noch etwas am Code.

Rein Theoretisch lässt sich in der Konfiguration schon ein Einzelschuss / einstelbare Darts Burst Schussanzahl / autofire Codieren. Dies erspare ich mich zum jetzigen Zeitpunkt, weil ich dafür eine Fortgeschrittenere Regelung in Planung habe.

Ich selbst sehe den aktuellen Projektstand als gutes Grundgerüst um mit erweiternden Funktionen zu beginnen. Dafür muss ich nun mir den besten Weg aussuchen und Bauteile bestellen.

Zur Zeit geht es um:

-Einen 3d gedruckten Flywheel Cage sowie Flywheels
-Andere Motoren und ESC´s
-Überlegen ob ich das Förderband über einen ESC oder einen Schrittmotor betreibe.

Da hier die Lieferzeiten eine Rolle spielen. Möchte ich euch gern um Gedult bitten.

Wenn ihr möchtet Poste ich auch gerne Bezeichnungen und Links zu den komponenten die ich Verbaut habe.

Natürlich nehme ich alle Fragen/Kommentare/Kritik/Hinweise oder ein geil, das hätte ich gern eingebaut, sehr ernst und bitte daraum nicht lange hinterm Berg zu halten, sondern reichlich davon gebrauch zu machen und es mich Wissen zu lassen.

 

[Foamsnake]

Super Anleitung, danke!
Dreh Potty und über PWM Schussrate Stufenlos einstellbar machen?

 

[AMORph]

Leider nein, dafür habe ich eine bessere Lösung im Kopf, ließe sich aber einfach über einen Poti und Analog read implementieren.
Hatte auch mal den Gedanken, an einen Hal Sensor am Abzug um die Feuerrate zu bestimmen

Aber offen gesagt, ein Poti ist schön clean und simple um eine wichtige funktion einzustellen. hervorragende Idee....

 

[DevilZcall]

drehgeber/encoder finde ich sehr praktisch, die lassen sich beliebig weiterdrehen und man kann sie sowohl zur menü-navigation als auch zum einstellen von werten benutzen. ohne display sind ein-zwei funktionsspezifische potentiometer aber wahrscheinlich tatsächlich besser

 

[AMORph]

Update:

Zwischen Pin 8 und GND hängt nun ein aktiver Buzzer um Piep Signale auszugeben.

Ich habe die Kabel vorläufig verlegt um etwas Ordnung zu schaffen.

Durch einen Schusstest habe ich das gefühl, das durch das ansteuern der FlyWheels und des Förderbands über das temporäre Relaismodul, die Leistung etwas gestiegen ist.
Das mit dem Rewire und brücken der Sicherungen in den Mod tutorials kann ich somit nur bestätigen.




Da ich auf die ersten Upgradeteile warte, habe ich viel am Code gemacht.

Folgende Funktionen wurden im Code schon hinzugefügt:

Boot vorgang eingebaut der nach abschluss 3 Beeps von sich gibt.

3 mal die sekunde werden JamDoor und Magazin abgefragt und ein/eine selbstcheck/selbstkorrektur wird durchgeführt (dient zur effizienz des Programms)

On the Fly einstellungen:
-Wenn das Magazin gezogen und die JamDoor verriegelt ist, kann man durch drücken des Abzugs, die Geschwindigkeit des Förderbands (Feuerrate) einstellen.
-Wenn die JamDoor offen und ein Magazin gesteckt ist, kann man durch drücken des Abzugs, die Geschwindikeit der Flywheels (FPS) einstellen.

Wenn man den Abgzug drückt wird die Geschwindigkeit in Stufen von 1 bis 100 erhöht (die Auflösung lässt sich bei Bedarf steigern).
Bei 100 erfolgt ein Beep, danach fängt man wieder bei 1 an zu erhöhen.
Diese Einstellungen sind bisher nur im Code vorhanden und werden erst scharf geschaltet, wenn die nötigen Teile dafür da sind.

Beim öffnen der Jamdoor und/oder ziehen des Magazins im Betrieb, ertönt ein Alarm und alle Motoren gehen aus. RevTrigger und Abzug sind gesperrt.

Die Flywheels haben einen einstellbaren Sleep- / Standby- Timer erhalten:
-Ist der Blaster geladen und man drückt den RevTrigger, fahren die Flywheels auf die eingestellte Geschwindigkeit hoch. Blaster ist feuerbereit.
-Lässt man den RevTrigger los, fahren die Flywheels auf eine eingestellte Standby Drehzahl herunter.
-Nach ablauf des Sleep Timers, schalten sich die Flywheels aus.
-Alle Timings und Drehzahlen sind frei konfigurierbar

Aktuelle Zykluszeit wenn Feuerbereit ~36ms

Der Code ist wieder als txt im Anhang mit hochgeladen. Hier würde ich mich sehr freuen, wenn jemand mal drüber schaut.


Auch habe ich damit begonnen meine Bastel und Coding Sessions im Discord zu übertragen:

Schaut einfach mal vorbei.



@Foamsnake & @DevilZcall :

Über die Potis habe ich mir Gedanken gemacht, mich aber dazu entschlossen diese über den Abzug zu realisieren.
Gründe dafür:
-ich zu faul bin die Potis einzubauen und Kabel zu legen
-Der Arduino hat zwar viele I/O Pins, ich möchte aber sparsam damit umgehen
-Jede Abfrage der Potis würde die Zykluszeit des Programs erhöhen, ich möchte aber eine möglichst geringe Zykluszeit (ansprechverhalten des Blasters)

"Drehknöpfe" werden aber in einer Form in das Projekt einzug halten. (ohne viel zu Teasern)

Danke für eueren Input



Bis dahin danke ich für eure Aufmerksamkeit und bitte weiterhin um Kritik und Hinweise.

 

[DevilZcall]

wie wärs damit die 0-100 für fps und feuerrate mit einer frequenz aus dem pieper wiederzugeben? Eventuell willst du auch die untergrenze auf so 20-30% setzen, einfach mal schauen wo der motor aufhört zu drehen. und ich hoffe du kannst beim einstellen rauf und runter zählen.

Aus spielerfahrung würde ich dir dazu raten nicht gleich alle motoren zu bremsen wenn das magazin gezogen wird, soll ja vielleicht gleich weiter gehen wenn das nächste geladen wird.

Im moment wartest du zum schießen immer blind bist der Pusher gurt einen dart erfasst und irgendwann in die flywheels schiebt. Wenn du irgendwie die position vom gurt erfasst, könntest du darts vorladen, oder zumindest sicherstellen, dass du immer von der selben stelle startest. (der "zahn" am gurt könnte sonst zB gerade auf dem dart liegen und du brauchst fast eine ganze umrundung des gurtes bis der nächste zahn den dart erfasst und in die fylwheels befördert.
Also entweder closed loop, oder mit kadenzüberwachung.

Dagegen hat die zykluszeit deines codes kaum einen einfluss, aber es gefällt mir, dass du optimierst.

 

[AMORph]

wie wärs damit die 0-100 für fps und feuerrate mit einer frequenz aus dem pieper wiederzugeben? Eventuell willst du auch die untergrenze auf so 20-30% setzen, einfach mal schauen wo der motor aufhört zu drehen. und ich hoffe du kannst beim einstellen rauf und runter zählen.

Aus spielerfahrung würde ich dir dazu raten nicht gleich alle motoren zu bremsen wenn das magazin gezogen wird, soll ja vielleicht gleich weiter gehen wenn das nächste geladen wird.

Im moment wartest du zum schießen immer blind bist der Pusher gurt einen dart erfasst und irgendwann in die flywheels schiebt. Wenn du irgendwie die position vom gurt erfasst, könntest du darts vorladen, oder zumindest sicherstellen, dass du immer von der selben stelle startest. (der "zahn" am gurt könnte sonst zB gerade auf dem dart liegen und du brauchst fast eine ganze umrundung des gurtes bis der nächste zahn den dart erfasst und in die fylwheels befördert.
Also entweder closed loop, oder mit kadenzüberwachung.

Dagegen hat die zykluszeit deines codes kaum einen einfluss, aber es gefällt mir, dass du optimierst.

Clevere idee, das mit dem Beeper. Evtl nen passiven beeper der das über die Herz zahl ausgibt, von dumpf nach schrill. Gefällt mir sehr.

Das mit der Motorbremse beim spielen hab ich nicht so auf dem Schirm, aber denke drüber nach. Evtl mit der Standbyzeit was machen.

Spoiler zum Thema Pusher
Nuja, in Planung ist etwas anderes:
-Lichtschranke am Eingang vom FlywheelCage
-Funktion: RevTrigger gedrückt, drehe Förderband bis Lichtschranke unterbrochen wird. (Dart sitzt direkt an den Flywheels)
-Funktion1: RevTrigger gedrückt && Abzug getippt, drehe Förderband bis Lichtschranke ein -> aus (einzelschuss mit Dart vorladung)
-Funktion2: RevTrigger && Abzug gedrückt halten -> entweder dauerfeuer, oder Burst (wird einstellbar)


Die Zykluszeit in meinem Programmsetup ist gleichzeitig die Abtastrate vom RevTrigger und Abzug. Ich will halt mit allen mitteln Vermeiden, das der Blaster ne gedenksekunde braucht um zu schießen.

HHmmm, jetzt war ich grade dabei verzweifelt nach Lichtschranken zu suchen und nu überlege ich wegen der Motorbremse bei Magazinwechsel
Die Idee mit dem Buzzer feier ich total.....


Danke vielmals für die Ideen und Erfahrungen @DevilZcall

 

[AMORph]

Update:

Buzzer von aktiv zu passiv gewechselt und Pin für den Buzzer ist nun 10
(aktiver Buzzer kennt nur ein und aus bei einer Tonfrequenz, ein passiver kann verschiedene Frequenzen ausgeben)

Dank des hervoragenden Inputs von @DevilZcall habe ich am Code was geändert:

-Maximalleistung für Motoren eingebaut (Man könnte es auch eine Vorwahl für die maximalen FPS sehen, die nicht so einfach zu ändern ist)
-Minimalleistung für Motoren eingebaut (die mindestleistung bei der sich die Mechanik anfängt zu drehen. Noch nicht feinjustiert)
-Motorleistung beim On the Fly einstellen wird nun durch eine Tonfrequenz ausgegeben. Hört sich an wie ein Bombentimer.
-eine einstellbare Rampe zur Verstellung eingepflegt. Diese regelt die Geschwindigkeit in der die Motorleistung erhöht wird. Das ist wieder so eine Usability Sache, am Anfang ohne die Rampe hat es mir zu lange gedauert die Motorleistung zu erhöhen
-Wenn maximale Motorleistung erreicht ist, gibts einen hohen Piep, lässt man dann den Abzug los, ist die maximale Leistung eingestellt
-hält man den Trigger weiter gedrückt, kommt ein niedriger Piep, lässt man dann los, ist die minimale Leistung eingestellt
-ab dann kann man wieder von niedriger zu hoher Leistung einstellen
-Zur besseren Verarbeitungen wurde die Auflösung der Motorleistungen von 100 auf 254 erhöht
-alle 2min (einstellbar) in dem der Blaster in Sleepmodus ist, Piepst er kurz, als Erinnerung ihn doch auszuschalten
-Beeptöne in drei Kathegorien aufgeteilt, tiefe, mittlere und hohe Töne (steigert die Usability, tiefe töne für Status, hohe für Alarme)
-Es gibt nun ein Bestätigungston für das verschließen von der JamDoor und/oder einlegen des Magazins

Habe auch angefangen gleichtzeitig die Bausessions auf twitch zu Streamen.

Aktueller Code im Anhang als txt

Aktuelle Zykluszeit: ~38µs (Sry, hatte die einheiten bisher falsch angegeben)


Bis dahin danke ich für eure Aufmerksamkeit und ich bitte weiterhin um Kritik und Hinweise.

 

[battle-axolotl]

Du willst deinen Code verschlanken wegen Zykluszeit, schön und gut, aber glaubst du wirklich, irgendwas unter 10 oder 20 Millisekunden (1s=1000ms=1000000us) macht da einen merklichen Unterschied?
Ist natürlich deine Sache, aber bei 38us konnte ich mir die Frage jetzt echt nicht verkneifen...

 

[AMORph]

Du willst deinen Code verschlanken wegen Zykluszeit, schön und gut, aber glaubst du wirklich, irgendwas unter 10 oder 20 Millisekunden (1s=1000ms=1000000us) macht da einen merklichen Unterschied?
Ist natürlich deine Sache, aber bei 38us konnte ich mir die Frage jetzt echt nicht verkneifen...

@battle-axolotl
Ich stimme dir da voll und ganz zu. Selbst mit den besten Schaltern an den Triggern mach ich mir um Zeiten gedanken, die man sich schlecht vorstellen kann.
Anderst ausgedrückt, im moment wird der RevTrigger und Abzugtrigger bei einer Zykluszeit von ~38µs etwa 26 316 mal die Sekunde überprüft.
Eine sinnhaftigkeit stelle ich nicht wirklich in frage, weil unsinnig.

Deshalb auch die Abtastrate von Magazin und JamDoor von 333ms (oder 3 mal die Sekunde).
Mehr macht da einfach keinen wirklichen Sinn, obwohl das Projekt Unvernunft heißt.

Bei den vernachlässigbaren Funktionen (momentan JamDoor & Magazin) überlege ich nach der sinnhaftigkeit von Checks.
Bei den Hauptfunktionen möchte ich nur das best mögliche.

Die Sache ist auch die:
-hält man nicht ein Auge auf die Zykluszeit, passieren Missgeschicke
-in der heutigen Bastellsession, hatte ich trotz , das der Blaster funktioniert hat, teilweise eine Zyklustzeit von >74000µs
-ignoriert man das und bastellt weiter, addieren sich solche Fehler und man gerät irgendwann an einen punkt an dem der Blaster eine Gedenksekunde zum reagieren braucht
-will man diese Gedenksekunde dann minimieren, bekommt man nur Kopfschmerzen

Ich möchte weiterhin, die geringst mögliche Zeit für das Ansprechverhalten der wichtigen Funktionen.
Deshalb:
-Funktion eingebaut
-beim einbauen schon schauen, was es für eine Auswirkung auf die Zeit hat
-eventuell Funktion optimieren
-dann weiter im Text



Nachtrag:
Es werden noch so die ein oder andere Funktion kommen, die einen ganz schönen Impact auf die Zykluszeit haben werden.

 

[DevilZcall]

Wie wäre es, mit dem trigger analog zu schalten?
Also folgende struktur:
- Flywheels kontrolliert vom mikrocontroller, rev schalter wird normal abgetastet
- Pusher wird vom Trigger direkt angeschaltet, aber von einem relay unterbrochen wenn die flywheels nicht an/ auf geschwindigkeit sind, das relay wird vom mikrocontroller geschaltet.

Wenn du also revst, hast du sowieso eine anlaufzeit von 0,2-1+s (je nach motorleistung und zielgeschwindigkeit) und die abtastrate vom flywheelschalter ist ziemlich hinfällig. Laufen die Motoren aber und der Abzug wird betätigt, ist die reaktion instant.

 

[AMORph]

Leider verliere ich durch eine direktschaltung vom Abzug, die einstellmöglichkeit für genauen Einzelschuss & Burst. Auch die Vorladung des Darts wird komplizierter.
Die feuer rate ist dann nicht ohne weiteres codierbar.

 

[DevilZcall]

das stimmt natürlich.

Ich hab keine erfahrung wie optimierter code für mikroprozessoren ausschaut, aber noch folgende ideen:
- Verwendung von interrupts für die beiden Trigger, die müssen dann an pin 2, und 3 gelegt werden
- abfragen der routine zur rof und geschwindigkeitsänderung nur beim booten (mit einem hauptschalter zum trennen der batterie ginge das ja auch "on the fly")
- switch case für den blasterflag? ich weiß nicht ob das tatsächlich schneller ist.

 

[medusa]

Seufz... Interrupthandling in kleinen Embedded Controlern überfordert schon so manch einen der "professionellen" Codeschmiede...
Natürlich sollte alles, was zu beliebiger Zeit ausgelöst werden kann (in der Regel von dem doofen Fleischsack, der das Gerät in den Fingern hält), einen Interrupt triggern. Wobei man sich, wenn's mehr wird, auch Gedanken dazu machen muß, was Priorität hat. Da spielt dann auch die Prozessorarchtektur eine Rolle. Bei manchen ist es recht qualvoll, das sauber hinzubekommen.

 

[AMORph]

AMORph stellt sich in die Ecke und schämt sich.

Offen gesagt habe ich mich noch nicht mit Interrupts beschäftigt und schiebe das Thema genau wie switch case vor mich hin, so weit es noch geht.

Im Moment versuche ich mich noch mit workarounds über Wasser zu halten.

 

[Foamsnake]

Im arduino Umfeld, gibt es nicht so viel zu beachten wegen der Besonderheiten im Aufbau der gesammten Runtime - von Main, loop und allgemein Funktionen

Funktionen benutzen und so wenig wie möglich im LOOP stehen haben, Lokale Variablen und keine Globalen - die Lokalen dürfen gerne übergeben werden mit der Funktion selbst - (Aber nicht in eine globale Variable wenn es geht, sondern direkt in den Code als teil des Funktion.

(Sollte man auf sowas Wert legen im Rahmen eines Projekts). Man muss sich auch die Frage stellen ob man einen Lauffähigen Code will der tut was man wollte mit dem KISS prinzip und wenigsten Aufwand, oder nebenbei noch 3 Jahre Programmiererfahrung nachholen / aufbauen will

Von daher hast du meinen Respekt für deine Mühen!

 

[AMORph]

Update:

Die ersten Teile die ich bestellt habe kommen so langsam an und somit komme ich an den Punkt weshalb ich den Thread direkt zu Projektstart eröffnet habe.
DIeser Punkt ist:

-Ich brauche Hife und Erfahrung aus der Comunity

Worum geht es bei diesem Aufruf?

Heute sind die Flywheels und Cage angekommen, die mir @smells like foam super schnell und für einen schmalen Taler gedruckt hat.
Kudos dafür! Ich bin immernoch wirklich begeistert!

Sowie auch direkt wieder ein dank an @smells like foam raus geht, da ich das Bild einfach nochmal verwende:


Die Druckdaten habe ich hier gefunden, was mich zu meinem Problem führt.

Denn hier und hier sieht man das Motor / Akku Setup.

Wie ich das sehe sind das 3000kv Motoren an einem 2S Akku, somit 3000kv*7,4 = 22200rpm (theoretisch)
Die Motoren habe ich leider nirgends lieferbar gefunden, möchte auch ein anderes Setup.

Nämlich diese Motoren an 4S Akkus (An dieser Stelle möchte ich nochmal anbringen, dass das Projekt "Unvernunft" heißt)
Nach meiner Rechnung dann also 2300kv*14,4V = 34040rpm.

Hier konnte ich einen kleinen Überblick über Drehzahlen erhaschen, womit das Setup am Ende des unteren Leistungsdrittels liegt.

Ich habe zwar hier und da etwas über abgerissene Dart-Köpfe gelesen, aber keine brauchbaren Daten gefunden.

Deshalb mein Hilferuf:

-Bitte gebt mir Rückmeldung wie ihr mein Motor / Akku Setup (C Rating und ESC sind erst mal zweitrangig) einstufen würdet
-Hat dieses Setup genung Leistung um das maximale aus einem Dart rauszuholen (es sollte möglich sein, das Darts bei 3/4 Leistung zerissen werden können (unvernünftiger weise)
-Welche kombination würdet ihr mir für das Flywheel / Cage Setup empfehlen, um in die von mir gewünschte Leistungsklasse zu kommen?
-Welche Drehzahlen sind für die Leistungsklasse nötig?
-Welche Drehzahl ist zu viel?
-Welche Drehzahl ist viel zu viel?
-Welches Setup würdet ihr für die angepeilte Leistungsklasse und den vorhandenen Cage/Flywheels nehmen?

Fragen über Fragen....

Mir ist bewusst, das es auch auf die Masse der Flywheels und Motoren, sowie das Drehmoment ankommt, aber auch dazu haben ich nicht wirklich Daten gefunden. Wenn jemand was hat, bin ich überaus dankbar, wenn mir das jemand zur verfügung Stellen würde.

Hier möchte ich das Szenario auch noch weiter eingrenzen. Ich möchte nur origianale Elite oder Akkustrike Darts verwenden um Qualitätsunterschiede der Darts außen vor zu lassen.

Bisher habe ich weder Motoren, ESC´s noch Akkus, diese möchte ich mir speziel für dieses Projekt zulegen. Dies hat auch noch etwas Zeit, da ich die Rückseite der Cages an dem die Motoren befestigt sind, mit einer Metallplatte verstärken will, die aber erst mal angefertigt werden muss.
Somit genug Raum für euren Input.

DIe Betriebsspannung des übrigen Setups ist auch nebensache, dafür will ich einen seperaten Spannungsregler und/oder BEC von ESC´s nutzen.

Im Grunde genommen hätte ich gern ein "Foam eating Dartbiest", da ich gerne mit dem "Dart launch" experimentieren möchte und dafür auch die angezielte Leistungsklasse brauche. Es sollte mehr wie das maximum das ein Dart aushält bieten.

Zur besseren Verständniss warum ich das möchte, folgender Gedankengang von mir:

Der Dartkopf reist ab, wenn das Delta der Drehzahl der Flywheels, zu der zufuhrgeschwindigkeit des Dart, zu groß ist und zu viel "Energie" auf einmal dem Dart zugeführt wird, sodas das Material des Darts einfach schlapp macht.

Wenn aber:
-die start Drehzahl der Flywheels knapp unter der maximalen Dart belastung liegt
-der Dart vorgeschoben wird, bis detektiert wird das:
-der Dart von den Flywheels erfasst worden ist
-die Steuerung das erkennt und dann
-nochmal mehr Leistung frei gibt (die den Dart bei start zerreisen würde)
-der Dart sich dann aber schon in bewegung befindet, so dass:
-der Dart dann nochmal mehr beschleunigt wird
-sobald detektiert wird, das der Dart den Cage verlassen hat, die Flywheels wieder auf die anfangsdrehzahl herunter geregelt werden.

Liege ich mit dem Gedankengang falsch, auf diesem Weg mehr FPS rausholen zu können, wie Flywheels ein -> Dart los?
Mir ist bewusst, das es nicht einfach wird dies umzusetzten, aber ich würde es gern probieren.

Ich möchte nicht auf Kurzdarts wechseln, Gedankengang hierzu:
-Je länger der Dart
-Desto länger die Zeit im Cage um nochmal zu beschleunigen

Mein Gedankengang ist auch, wenn ich viel mehr Leistung habe, wie ich brauche, läuft das Setup im normalbetrieb kühler und nicht so stromhungrig, aber das ist auch nebensache.

Ich möchte euch hier nochmal bitten, mir mit euren ungefilterterten Erfahrungen / Meinungen / Kritik / Korrekturen und Hilfe zu helfen, da Brushless und Nerf Modding für mich absolut Neuland ist und ich nicht 10mal was falsches bestellen will.

 

[smells like foam]

^^
Ich versuche mal auf alles ein zu gehen, wozu ich eine verlässliche Aussage treffen kann. Der Rest wird bestimmt von der einen oder anderen Person hier vervollständigt.
Die meisten Standard Tuning Motoren haben aktuell um die 33.000 rpm, auf der jeweiligen, dafür ausgelegten Spannung, aber natürlich ist, das, wie du schon so schön erkannt hast, nicht die ganze Wahrheit.
Je größer der Umfang der Flywheels bsw. desto schneller bewegt sich die Oberfläche, die mit den Darts in Berührung kommt.
Je stärker, der "Crush", also je näher die Flywheels zusammen sind und umso mehr Oberfläche der Flywheels mit den Darts Kontakt hat, desto besser ist die Energieübertragung der Wheels auf die Darts. -> Desto effektiver ist das ganze.

An der Stelle möchte ich dir "Airzone", auf Youtube empfehlen. https://www.youtube.com/@AirzonesBlasters

Externer Inhalt

An dieser Stelle wurde ein Inhalt von youtube eingebunden. Wenn wir diesen Inhalt anzeigen, werden möglicherweise personenbezogene Daten wie deine IP-Adresse an youtube.com und github.com übertragen. Zudem kann youtube.com Cookies auf deinem Gerät speichern. Mehr Informationen und Einstellungsmöglichkeiten findest du hier.

Ich bin damit einverstanden, zeige mir immer Inhalte von youtube.com an.

Zeige mir immer alle externen Medien an.

Zu deinen Fragen:

- Ich bilde mir ein, schon mal 4000kv Motoren in der Größe auf Fundoino gesehen zu haben, die dürften sich vermutlich besser eignen (Wenn sie passen). Die waren glaub 2-3s. Die waren höher und dürften somit nicht mit den Wheels funktionieren. Ich würde kucken, dass du das mit den meisten kv nimmst, was mit Cage und Wheels geht.

- Da du das Cage und Wheels ja schon hast, würde ich erst mal kucken wie weit du damit kommst. Ich kann micht nicht erinnern schon mal ein canted Brushless Setup gesehn zu haben. (Die Wheel stehen schräg und drehen so die Darts). Da wäre es mal interesant zu sehen, wie gut das so geht.

- Ich glaube zu viel RPM geht nicht, solange die Motoren die Kraft nicht verlässt ^^

- Ich denke, dass du in dem Leistungsbereich, also um die Darts zu zerstören, am besten ein Setup mit sehr viel Crush benutzt. Alternativ wäre Multistage (mehrere Flywheelsetups hintereinader vielleicht auch eine Idee.)


Ich glaube deine Idee den Dart so "schonend" zu beschleunigen dürfte an der Trägheit der Motoren scheiter. Die Darts dürften schlichtweg nicht lange genug Kontakt mit Wheels haben, dass sie Motoren das mitm Hochbeschleunigen packen.
Multistage Setups haben aber teilweiße eine ähnliche Idee, da drehen sich die ersten Wheels einfach langsamer als die zweiten.
AAAber: Versuch macht kluch

Eventuell können wir da auch gerne mal im Discord drüber quatschen, ich habe halt nicht immer viel Zeit xD

 

[DevilZcall]

Bei brushless ist die devise bis zuletzt gewesen "viel hilft viel" und wenn es die darts dabei zerreißt, liegt das meist eher an schlecht geklebten darts. Die klassischen motoren für flywheels in der größe á la ultrastryfe liegen so bei 3000KV, und da würde ich dir auch erstmal empfehlen anzusetzen.

Ziel ist es möglichst viel kinetische energie in der drehgeschwindigkeit der flywheels zu speichern (natürlich in einer so kurzen anlaufzeit wie möglich) und dann mit einem hohen quetschfaktor (crush) so viel davon wie möglich auf den dart zu übertragen. wichtig ist eigentlich bloß zu wissen, dass bei hohem crush nur entsprechend nachgiebige Dartköpfe zerstörungsfrei durch die flywheels gehen.

Im allgemeinen wird als "crush" übrigens der Achsabstand der motoren angegeben, "hoher crush" ist aber dennoch ein geringerer achsabstand, mit dem wird schließlich mehr gequetscht.

 

[AMORph]

Update:

Nach dem Input von @smells like foam und @DevilZcall habe ich mal mit ein paar Zahlen jongliert:
Vielen dank @smells like foam und @DevilZcall


Alle Handschriftlichen Werte sind natürlich als Spekulativ und Theroretisch anzusehen.

Wenn ich dem Blaster eine Leistung von 150fps unterstelle, komme ich auf eine Kontaktzeit (Dart -> Flywheels) von 0,775ms. Weiter recherchiert zum Thema Steuerungszeiten habe ich noch nicht, aber muss zugeben, das ich den glauben an die "sanfte" beschleunigung verloren habe.

Genausowenig habe ich lieferbare 2800kv bzw 3000kv Motoren gefunden, die aus einer seriösen Quelle kommen.

Nun zu etwas positivem:

-Der Cage und die Flywheels passen sehr gut, es sind aber evtl. kleinere anpassungen zu machen (später mehr dazu)
-Habe die Kabelführung mit Steckern und einem Flachbandkabel schon richtung dem Einbauort Arduino vorbereitet
-auch habe ich mir ein "Quality of Life" upgrade gegönnt. Dieses Expansion Board vereinfacht die VCC und Masseversorgung ungemein.



Wie geht es weiter?

Motoren und ESC sind schon in einem Warenkorb und warten auf Bestellbestätigung sobald ich mich für das Setup entschieden habe:
-Motoren
-ESC-Flywheel
-ESC - Förerband mit BEC

Der ESC für das Förderband, steht noch in Frage, da dieser nur max 3S unterstützt, da muss ich nochmal schauen.

Ich würde es herzlich begrüßen, wenn sich jemand die Zeit nimmt und über die Motoren / ESC Flywheel kombination schaut, ob das auch ausreichend dimensioniert ist.

Dann muss ich mir noch gedanken machen, wie und wo im vorderen Teil anpassungen an der Shell gemacht werden, damit die Kabel sowie die ESC´s mit dem Expansion Board gut befestigt werden können.


Wie immer an dieser Stelle würde ich mich über ungefilterterte Erfahrungen / Meinungen / Kritik / Korrekturen und Hilfe freuen.

 

[Dominik]

Interessant, deine Motoren haben auch die Teilkreisdurchmesser 16 und 19 Millimeter bei den Befestigungslöchern. Das ist mir bei meinem ersten Cage für meinen Mega-XL Blaster auf die Füße gefallen, ich konnte den Motor nur mit zwei Schrauben befestigen.

Eine Frage an alle die sich damit beschäftigt haben und die hier auch noch relevant werden könnte:
Kann man Regler von BLHeli-S auf BLHeli-32 umflashen oder ist das flashen eine einmalige Sache?

 

[AMORph]

@Dominik das umflashen dürfte eigendlich kein Problem sein. Was aber geklärt werden müsste, ist ob dein ESC auch die 32bit von BL-Heli-32 ünterstützt?

• BLHeli32 is closed source and based on 32bit ARM MCUs. All modern BLHeli ESCs use BLHeli32
• BLHeli_S is open source and 16bit. This is no longer actively maintained but the last published version, 16.7, is installed by default on “BLHeli_S” ESCs when shipped from the factory

 

[DevilZcall]

mich hat jetzt auch mal wieder das arduino-fieber gepackt, und da habe ich die chance genutzt um mal mit Interrupts zu spielen.

Funktional folgendes: beim betätigen des Abzugs soll ein Magnetventil für kurze Zeit mit voller leistung angesteuert werden, dann für längere zeit mit reduzierter leistung um Akku zu sparen und Wärmeentwicklung zu reduzieren, danach soll noch eine Zeit ohne Aktivierung gewährleistet werden. Ach ja und falls während dem Zyklus noch ein weiteres mal Getriggert wird, wird der Schuss einfach hinten dran gehängt und nicht geschluckt.

#define triggerPin 2 //PB2 fest an Int0 geknüpft
#define ledPin 1
#define solenoidPin 0

const int solenoid[] = {255, 150, 0};
const unsigned long timing[] = {50, 100, 300};

int firingState = 4; //0 = full power, 1 = hold, 2 = reset, 3 = ready, 4 = startup

unsigned long cycleStartTime = 0;
bool shotQueue = false;

void setup() {
  pinMode(triggerPin, INPUT);
  digitalWrite(triggerPin, HIGH);  // Enable internal pull-up resistor
  pinMode(ledPin, OUTPUT);
  pinMode(solenoidPin, OUTPUT);
  attachInterrupt(0, triggerInterrupt, FALLING);
  firingState = 3;
}

void loop() {
  unsigned long relativeTime = millis() - cycleStartTime;
  if (firingState < 3) {
    if (relativeTime >= timing[firingState]) {
      firingState ++;
      analogWrite(solenoidPin, solenoid[firingState]);
      digitalWrite(ledPin, LOW);
    }
  } else if (shotQueue) {
    shotQueue = false;
    firingState = 3;
    triggerInterrupt();
  }
}

void triggerInterrupt() {
  if (firingState = 3){
    analogWrite(solenoidPin, solenoid[0]);
    cycleStartTime = millis();
    firingState = 0;
    digitalWrite(ledPin, HIGH);
  } else shotQueue = true;
}

 

[AMORph]

pinMode(triggerPin, INPUT); digitalWrite(triggerPin, HIGH)

Schon nice,
Aber warum nicht hier:

pinMode(triggerPin, INPUT_PULLUP);

Oder so ähnlich?

 

[battle-axolotl]

Wofür ein Magnetventil bei einer Hyperfire? Ich dachte, die wäre ein Flywheeler und kein AEB wie Stampede oder Vulcan?