Anleitung Mikrokontrollerprogrammierung einer RapidStrike

[Pequi]

Moinsen,

hier möchte ich im Detail Infos zur Programmierung einer mikrokontrollergesteuerten RapidStrike darlegen:

geplante Modifikationen:
- Umbau des FWCs auf DrS oder Artifacts (Gold oder Rot)
- Motoren: - 2x Slotdevil für die Treibräder
- evtl. Ersatz des Pushermotors durch Slotdevil. Eher nicht notwendig, da keine extreme Kadenz gewünscht ist
- Betrieb der Treibradmotoren mit 3s-Lipo (11,1V nominal)
- Schaltung der Treibmotoren und des Pushermotors mittels MOSFETs und damit eine Aufteilung der Stromkreise in einen "Niedrigenergetischen" und einen "Hochenergetischen"
- Steuerung aller Funktionen mittel Arduino-Mikrokontroller (Entwicklung auf Arduino Uno)
- Einstellbarkeit der Treibmotorgeschwindigkeiten in drei Stufen (Feuerkraft), der Pushergeschwindigkeit in drei Stufen (Kadenz), des Schußmodus (Einzel-, 3er-, Dauerfeuer)
- Zählung der Schüsse und Vorwahl der verwendeten Magazingröße
- Akkuüberwachung mit Unterspannungswarnung und automatischer Abschaltung
- Ausgabe aller Informationen über ein sehr kleines OLED-Display (0,96", I2C, 128x64 Pixel, s/w)
- ggf. Ausgabe von Sounds

Da die umzubauende RapidStrike mir noch nicht vorliegt, die elektronischen Bauteile allerdings im Verlauf eingetrudelt sind, habe ich auf dem Steckbrett bereits alles zusammengebaut. Bei voller Funktionalität ist geplant, das Arduino Uno-Board gegen ein bereits erworbenes sehr kleines zu tauschen. Evtl. auch nur den reinen Prozessor mit einigen kleinen Bauteilen drumherum.

Die ersten Programmierexperimente verliefen recht vielversprechend. Allein, der verbaute MOSFET wollte sich vom Arduino-Board nicht steuern lassen, weil er mit den kleinen Steuerspannungen nicht zurechtkam. Daher wurde er gegen einen FQP30N06L mit einer Schaltleistung von 25V bei 30A getauscht. Versuche, die Motoren mit einem noch rumfliegenden ESC (Electronic Speed Controller => Fahrtregler) aus dem Modellbau zu betreiben, verliefen ebenfalls problemlos. Allerdings ist der zwar von der Bauform sehr klein gehaltene ESC dennoch Overkill in einem Spielzeugblaster (Bürstenmotoren mit einer Stromlast bis zu 70A bei einer Spannung bis 25V!). Und auch trotzdem zu groß...MOSFETs sind kleiner und billiger.

Hier mal alles durcheinander, der fliegende Aufbau:



Weg vom fliegenden Aufbau hin zur Lochrasterplatine - getestet und für gut befunden:
Die "Lowside":




Die PusherSteuerung mit der H-Brücke:


verkabelt mit dem Uno R3:




Die "Highside" wird nicht auf Platine gedengelt, sondern in die Kabel integriert.

Schaltplan der Hardware zugefügt:
Haftung für Korrektheit wird ausgeschlossen!
@Lorcan: könntest Du bitte Dein geschultes Auge darüberschweifen lassen?



















Hier jetzt die Pushermotorsteuerung mit Platinenlayout:















Die Grundfunktionalität steht:
Ich kann:
- den Schußmodus mittels eines in Griffnähe einzubauenden Mikrotasters einstellen
- die Feuerkraft einstellen (Jamdoor offen und mit Abzug auswählen
- die Kadenz ändern: Jamdoor offen und mit Motortrigger auswählen
- Anzahl der verschossenen Projektile zählen und von der einzustellenden Magazingröße abziehen
- die Magazingröße aus einer vorgegebenen Anzahl einstellen (Jamdoor offen und Feuermodustaster betätigen)

Ist die Jamdoor offen oder kein Magazin eingelegt, ist ein Starten der Motoren oder des Pushers nicht möglich.

Die Schußmodi (Einzelschuß, 3er-Salve, Dauerfeuer) verlaufen so:
- Betätigen des Motortriggers entsperrt den Abzug elektronisch.
- wird bei betätigtem Motortrigger (Flywheels laufen) der Abzug betätigt, wird ein Einzelschuß/3er-Salve abgegeben, auch wenn der Abzug losgelassen wird.

ToDo:
- Speicherung der Voreinstellungen im EEPROM
- Einbau und Umbau des elektronischen Geraffels auf die kleinstmögliche Abmessung
- erledigt: Spannungsüberwachung
- Soundausgabe
- erledigt: Blink-Blink-LEDs, wenn das Magazin leer ist
- erledigt: Lichtschranken zur Geschwindigkeitsmessung der Darts
- erledigt: Lichtschranke zur Erfassung, ob Dart im Magazin ist und dann erst Pusher auslösen
- erledigt: Ladehemmungserkennung: Erfassen, ob ein Dart auch den FWC verlassen hat -> weitere Lichtschranke einbauen -> Kombination mit Geschwindigkeitsmessung

Bauteileliste Hauptplatine mit Arduino:
- 1x Diode 1N4001
- 5x Diode MUR460
- 1x L298HN
- 1x Mosfet FQP30N06L
- 11x Widerstand 10k Ohm
- 1x Widerstand 4,7k Ohm
- 14x Widerstand 220 Ohm
- 3x Widerstand 2,2k Ohm
- 3x IR-LED, z.B. IRL 81A (880nm)
- 3x IR-Phototransistor, z.B. LPT 80A Inf (400-1100nm, max 880nm)
- Keramik-Kondensatoren:
- 1x 0,33uF
- 11x 100nF
- 2x 470uF Elko
- 2x rote LED
- 1x Festspannungsregler L78S05CV
- 1x OLED Display SSD1306 i2c 128x64 Pixel, z.B. Adafruit

Bauteileliste Pushersteuerung:
- 1x L298HN
- 4x Diode MUR460
- 2x Keramikkondensator 100nF

 

[Pequi]

7.2.2017:
- Code-Optimierung
- Einfügen einer Startup-Message
- LED eingefügt, die blinkt, wenn das Magazin leer ist, ohne den Controller zu blockieren
- Präprozessoranweisung für deutsche oder englische Lokalisation
- Einfügen der DebugUtils.h und Testanwendung im Code. Wird nicht kompiliert, wenn die erste Zeile:

#define DEBUG       // für Debbugging => DEBUG_PRINT ("Text");

so:

//#define DEBUG       // für Debbugging => DEBUG_PRINT ("Text");

auskommentiert wird.

10.2.2017:
- Code-Optimierung
- Magazin-LED pulsiert nun -> sieht cooler aus.
- Bugfix der Magazinfüllungserkennung
- Erweiterung der Schaltung um einen Festspannungregler LM78S05CV, um den Arduino aus dem Akku zu versorgen
- Die MOSFETs FQP30N06 werden vom Arduino nicht richtig durchgeschaltet, weil die Gatespannung höher sein muß -> ersetzt gegen den FQP30N06L

11.2.2017:
- Überwachung der Gesamtspannung des Akkus mittels Spannungsteiler (10k Ohm und 4,7k Ohm) und enervierende Displaydarstellung. Deaktivierung der Blastermotoren bei Akkuspannung unter 10,2V bei 3S-Lipo (entspricht <3,4V/Zelle). Keine Einzelzellenüberwachung.

17.2.2017:
- Überwachung der Gesamtspannung des Akkus stark überarbeitet, damit kurzzeitige Spannungseinbrüche, z.B. beim Anlaufen der Motoren, nicht zum Abschalten führen. Akku wird nur jede Sekunde vermessen und alle 5 Sekunden der Mittelwert gebildet. Damit wird das Akkumessen auch nicht so CPU-intensiv. Desweiteren Umstellung der Spannungsberechnungen von "float" auf "long". Die Berechnungen von Fließkommawerten sind extrem rechenaufwendig und auch ungenau (6.0 / 2.0 ergibt nicht zwingend 3.0 !!) und sollten daher vermieden werden.
- Warn-LED durch eine 10mm dicke Version ersetzt: sieht kuuhl aus!

26.2.2017:
- Die pushermotorgesteuerte Zählung habe ich rausgeworfen. Der Code wird grad komplett auf die Lichtschrankensteuerung umgeschrieben:
Die Geschwindigkeitsmessung des Darts im Lauf wird interruptgesteuert erfolgen. Die Programmierung der Ladehemmungserkennung muß ich noch auf Herz und Nieren prüfen. Die ist ein bischen tricky und außerdem müßte ich erst mal die Hardware verbauen. Dazu brauche ich aber den Wire Wrap-Draht aus China, der kommt und kommt nicht...
Dennoch wurde der Schalt-/Steckplan schonmal auf die geänderte Hardware eingestellt.
Im Moment spielt sich die Überprüfung der Programmlogik in meinem Kopf ab, da ich es noch nicht am "lebenden Objekt" testen kann (s.o.). Daher werde ich die nächste Version wohl erst veröffentlichen können, wenn ich das ganze Geraffel aufgebaut, zusammengelötet und eingebaut habe. Ob ich mir direkt eine Platine/Shield mache oder erstmal auf Lochrasterplatine teste, steht auch noch nicht fest. Außerdem wird alles auf ein Arduino Pro Mini-Board zusammengeschrumpft. Entwicklungsboard z.Zt. ist der Uno R3. Ma guggen...

6.3.2017 :
Code in großen Teilen verändert und als Anhang in eine Datei verpackt, da die Forum Software keine Beiträge mit mehr als 10.000 Zeichen zuläßt. Die Motoren lassen sich nun zuverlässig schalten. Das Problem mit dem ungetriggerten Aufruf der Interruptroutinen ist noch nicht gelöst. werde als Nächstes die Motoren entstören.

8.3.2017:
Das Problem scheint gelöst:
Sowohl der Motorschalter als auch einer der Motoren haben wohl reichlich Störsignale gesendet. Ich habe durch einen sowohl 100nF zwischen Schalter 5V und GND als auch später durch einen 33nF Keramikkondensator den Schalter entstören können. Desweiteren habe ich an beide Motoren 100nF Kondensatoren zwischen den Motorpolen gelötet. Zwei weitere 33nF Kondensatoren wollte ich noch zwischen je einem Pol und Gehäuse löten, allerdings ließ sich das Motorgehäuse nicht löten, nahm kein Lot an. Funktionierte allerdings trotzdem!
SourceCode angepaßt

Update:
Habe noch ein bischen weiter experimentiert und ein RC-Glied an den störenden Taster (Abzugschalter) getüddelt, da er trotz o.g. alleinigen Kondensator noch immer gelegentlich störte.
Nun scheint das Problem entgültig behoben zu sein.

siehe Schaltung:



9.3.2017:
Problem gelöst, warum der Pin 4 beim Arduino beim Booten auf "HIGH" gesetzt wird:

Habe mal einen Test gemacht: eine LED an Pin 4 gesteckt: Die LED leuchtet beim Booten des Arduino kontinuierlich. Erst ein "digitalWrite(4, LOW);" hat dem ein Ende gemacht.
Warum der Arduino den Pin 4 auf HIGH schaltet (oder mit PWM beschickt) ist mir unklar. Aber des Pudels Kern scheint gefunden.

Edith:
Habe den Schuldigen gefunden:
Die Displayinitialisierungsroutine der Adafruit-Library setzt den Pin 4 auf "HIGH".

display.begin(SSD1306_SWITCHCAPVCC, 0x3C);

ein manuelles Setzen auf "LOW" nach der Initialisierung schaltet ihn dann wieder aus:

    pinMode (FeuerLEDPin, OUTPUT);
    digitalWrite(FeuerLEDPin, LOW);

Diese LED wird zusammen mit der Alarm-LED genutzt, um die Lauflänge, bzw. den Lichtschrankenabstand zu eichen und in den Code einzutragen, damit man eine genauere Chronyfunktion bekommt.

12.3.2017:
Endlich das Geraffel auf eine Lochrasterplatine gedengelt. 5V-Spannungsregelung funktioniert ebenso wie der Spannungsteiler. Der Rest wurde noch nicht getestet.
Der Arduino Pro Mini ist nun als Nächstes dran und muß mit der Platine verkabelt werden.

14.3.2017:
- Aufbau der "Lowside" auf Lochrasterplatine vollendet und getestet. Bilder im ersten Posting.
- Die "Highside" wird nicht auf Platine gedengelt, sondern direkt in die dicken Kabel integriert. Spart Leitungslänge zu den Motoren und reduziert damit Verlustleistung.

16.3.2017:
Update Hardware:
Also: nach reichlicher Recherche habe ich mich für den (bereits gekauften) L298HN entschieden.
Das hat folgende Bewandnis:
- Wie bereits von Dominik erfolgreich eingesetzt (https://blasted.de/threads/mosfet-aktive-motorbremse-active-breaking-system.5645/), kann dieser Doppel-H-Brücken-Motortreiber zu EINER H-Brücke zusammengeschaltet werden und damit bis zu 4 A schalten
- Desweiteren kann ich diesen nicht nur so schalten, daß man den Motor durch Kurzschluß abbremst, sondern (weil echte H-Brücke) ihn auch "rückwärts" laufen lassen. Will heißen: zum Abbremsen gebe ich über den Arduino ein Umpolsignal und anschließend ein sehr kurz dauerndes PWM-Signal. Nur so lange, wie es dauert den Motor zum Stillstand zu bringen.
- Einen Schaltplan habe ich bereits entworfen und kann im ersten Post begutachtet und bitte auch kommentiert werden (Prüfung auf Fehler erbeten!)
- Zusätzlich habe ich wieder den Pushermotorpositionsschalter an den Arduino angeschlossen, um die Pusherstellung zu detektieren und danach die Motorabschaltung zu steuern (s.o.)

Das alles ist bislang nur theoretisch und im Schaltplan zu bewundern und harrt noch der Ausführung. Muß auch noch sehr schnellschaltende Dioden besorgen.
Wenn es dazu Anregungen gibt, bin ich sehr dankbar dafür.
Weiterhin muß das alles noch im Code berücksichtigt werden und dazu muß ich schauen, wie die Analog-Eingangs-Pins (A0-A5), obwohl nutzbar, auf Digitalabfrage reagieren. Oder ob ich doch die Pins D0 und D1 nutze, dabei aber die Möglichkeit der Seriellen Schnittstelle verliere. Weiters soll es beim Booten aufgrund des Arduino-Bootloaders zu Abfragen/Eingaben der D0/D1-Pins kommen, die evtl. dann die Elektronik verwirren könnten. Evtl. lege ich dann unproblematische Bauteile darauf (LED, Taster, etc).

18.3.2017:
- kleine Schaltplan- und Bauteillistenänderung

21.3.2017:
- Fertigstellung der Pushersteuerungsplatine, Bilder s.o.

10.4.2017:
- Umstellung der Schaltplansoftware auf KiCad
- Umstellung des Schaltplanes auf SMD-Bauteile und DIL-Sockel für den Arduino, quasi als "Shield", um Platz zu sparen
- Alle Eingänge des Arduino mit Tiefpässen versehen, um EMV zu vermindern
- 3D-Darstellung der Platine mit Vorder- und Rückseite im ersten Post
- Anpassung der Bauteilliste

13.4.2017:
- Verarbeitung der Tips von Lorcan: 45°-Leiterbahnen und Zufügen von Kupferflächen als Massefläche
- durch wildes Durchkontaktieren und Verlegen von Bauteilen auf die Rückseite, konnte ich die Platinengröße nochmals schrumpfen
- Anpassung des Schaltplanes, Einfügen von Vorder- und Rückseite des Platinenlayoutes

16.4.2017:
- Erstellung der Pushersteuerungsplatine mit KiCad
- Ergänzung der Bauteileliste für diese Platine

22.4.2017:
- Ergänzung des Platinenlayoutes durch eine originale Arduinovorlage und daher mit zusätzlichen Pinheadern für die Analogpins des Arduino Pro Mini, so daß der nun komplett mit allen Pins auf das Shield paßt und daher keine Verdrahtung der innen gelegenen Pins A4-A7 vonnöten ist.

 

[Pequi]

Den Code nur noch als Anhang, da die Forensoftware nicht mehr als 10.000 Zeichen zuläßt.

Die Endung ".txt" bitte vor dem Compilieren entfernen.

9.3.2017: Version 0.4
- Code-Update: Fehler mit Fontgröße behoben (hoffe ich). Diverse kleinere Bugfixes.

Update: Version 0.5
- Code-Update (s.o.): ich habe eine zusätzliche LED an (den nun freigewordenen Pin 4) getüddelt, um ein Ausmessen der Lauflänge/Flugdistanz im Lauf mit den Lichtschranken zu ermöglichen. Wenn man ein Maßband in den Lauf schiebt, triggern die Lichtschranken nacheinander die LEDs (Alarm und Test). Dann kann man, wenn die LEDs angehen, die Distanz messen und im Code verankern, um eine genauere Chrony-funktion zu bekommen. Kann man dann im Code wieder deaktivieren, wenn die Lauflänge geeicht ist.

Man könnte diese LED durch eine sehr starke Version ersetzen und damit ein Mündungsfeuer simulieren.

14.3.2017: Version 0.6
- kleinere Verbesserungen und Anpassung der Akkuanzeige mit Kommastellen.

17.3.2017: Version 0.7
- Anpassung des Codes an die Steuerung des L298-Doppel-H-Brückentreibers und der Detektion des Pusherpositionstasters zur Pushermotorabschaltung. Dazu werden die Analog-Pins A1 bis A3 als Digital-Pins verwendet. Allein für die Pushermotorsteuerung werden also ingesamt 4 Pins notwendig, wenn man den Pushermotor flexibel ansteuern will. Ich habe daher zwei Möglichkeiten des Motor zu stoppen:

- Variante 1: Setzen der Steuereingänge des L298 entsprechend einer Motorbremsfunktion (Kurzschlußbremse) analog zur Schaltung in der Stock-RapidStrike, dort allerdings mittels Tastern implementiert.

- Variante 2: falls o.g. Variante den Pushermotor nicht ausreichend rasch abstoppen kann, wird Folgendes gemacht:
Ansteuerung des L298, der den Motoranschluß umpolt und für einen entsprechenden Zeitraum, der noch ausbaldowert werden muß, einen Gegenstrom auf den Motor gibt, bis dieser zum Stillstand gekommen ist.

=> Beide Möglichkeiten sind im Code berücksichtigt und müssen nur entsprechend "umkommentiert" werden.

Anpassung der "DebugUtil.h": Es müssen nun zwei Stringparameter an "DEBUG_PRINT" übergeben werden:

DEBUG_PRINT ("Text", anyType);
oder
DEBUG_PRINT (anyType, "Text");
oder ein Mix aus Obigem

Damit kann man nun etwas aussagekräftigere Ausgabezeilen kreieren, z.B.:

DEBUG_PRINT ("Spannung", Voltage);

Weitere Codeoptimierungen.

 

[diam0nd]

Holy Makkaroni..... Da krieg ich ja direkt.... Ähm... Also, sehr geil, das ganze! Hammer!

Danke Dir für die Arbeit, ich werde (wenn ich darf) das sehr gerne nutzen, denn das integrieren eines Arduino in eine RS ist eins meiner nächsten Projekte.

Die RS hab ich schon hier liegen, die Arduino Komponenten kommen im März, für Februar ist das Budget schon aufgebraucht.....

 

[Kommandante]

Sehr, sehr geil!!
Basic Stamp kann sowas nicht oder?

 

[Moggih]

Weisste, da gibt es Leute, die hier lange Zeit recht aktiv sind und solche Projekte ankündigen, ein paar "Teaser" posten und dann ohne "abzuliefern" einfach verschwinden.

Und dann gibt es Leute, die sind ein paar Wochen hier und hauen gleich ein zu 90% lauffähiges Setup raus, ohne großes Buhei.

Das hier kommt spätestens auf Seite 4 meines Buches der coolen Leute.

 

[Pequi]

Sehr, sehr geil!!
Basic Stamp kann sowas nicht oder?

Ich kenne die Basic Stamp nicht, nur mal davon gehört. Welcher Prozessor wird dort verwendet?

Anyway, die Arduinoprogrammierung ist in der Tat recht einfach. Ist mein erster Ausflug in die uC-Programmierung. Programmiere aber auch schon seit meinem 14. Lj an. Schau dir den Code an und entscheide selber, ob ein Umstieg lohnend wäre.
Wie man sehen kann, ist der Code recht schlank.
Ansonsten einfach ausprobieren…

Grüße,
Pequi

 

[medusa]

Hi Pequi,

nimm das jetzt bitte nicht persönlich. Ich bin halt ne alte Omma, die Probleme damit hat, wie achtlos heutzutage mit Mikroelektronik umgegangen wird. Kann auch sein, weil ich meine Euros damit verdiene, so ein Zeug (in C++) für Bildverarbeitung in Autos zu entwickeln, bin ich in meiner Freizeit eher allergisch dagegen. Und das, obwohl ich vor über 30 Jahren zu den ersten Computer-Nerds gehört habe. Ja ich hatte einen ZX81 und nicht nur den.
Ich habe von jüngeren Leuten (kA wie alt Du bist) schon oft gehört, "och, da nehm ich einfach n RaspPie", wenn ich vorgeschlagen habe, ein einfaches Problem mit Hilfe von ein paar Logik-Gattern (oder gar analog) zu lösen. Also, da wird ein Chip mit einer Rechenleistung, die zu Beginn meines Studiums ein ganzes Mathematik-Institut einschließlich aller Mitarbeiter und Studenten gücklich gemacht hätte, dafür benutzt, um ein paar Schalter umzulegen. Sorry, für mich entbehrt das jeder Verhältnismäßigkeit.

Wie gesagt, nicht persönlich nehmen (und schon gar nicht rechtfertigen müssen jetzt), ich wollte das einfach nur mal loswerden. Ich finds cool, daß Du Dir die Mühe machst das zu entwickeln und zu testen und dann für die Community freigibst. Wäre übrigens schön, wenn Du dazu noch sagst, ob der Quellcode Open Source ist und ggfs. unter der Gnu GPL von Dir lizensiert wird. Dann wären alle anderen User rechtlich auf der sicheren Seite. (Mit gepostetem Programmcode ist es genau wie mit Bildern, copyrightmäßig).

Grüße, ~Diane.

 

[Moggih]

Das sehe ich persönlich anders. Wenn das Bauteil kann, was es soll und nicht mehr kostet als es darf - why not?

Ich habe schon Menschen ein 1,20x0,50 m Hochbeet vermittels eines Minibaggers mit Erde befüllen sehen. Einfach weil grad nicht der erforderliche Bock da war, eine Schaufel in die Hand zu nehmen. Übertriebene Werkzeugauswahl gehört zum Spaß und Hobby doch einfach dazu

 

[Pequi]

Also ich bin ein alter Oppa (50). Bin als Computerfreak mit Commodore PET 2001 angefangen, dann über PC-kompatible, Hochschulrechenzentrum, Amiga 500 + 3000, Linux auf PC usw. aufgewachsen. Habe von Anfang an programmiert. Meine Elektronikausflüge beschränkten sich darauf, Schaltungen nachzubauen. Eine eigene Schaltungsentwicklung habe ich trotz Selbststudium nicht wirklich kultivieren können. Bin ein Softwarefreak. Daher auch die Mikrokontrollernutzung, in die ich ohnehin längst einsteigen wollte und daher die Gelegenheit genutzt habe. => gute Kombination aus einfacher Hardware und (evtl. komplexer ) Software.
Was Andere davon halten ist mir wurscht, da ich das als Hobby verstehe (Bin im echten Leben Anästhesist, Intensivmediziner und Chirurg). Die Definition von Hobby sollte jedem klar sein: "Maximaler Aufwand mit geringstmöglichem Nutzen" . Ergo: eine solche Diskussion erübrigt sich.

P.S.: Bin auf Medizinfilme allergisch

P.P.S: dieser einfache "Bananen"-Code steht nun unter der "GNU General Public License"

 

[MolotovRocktail]

Ich finde es eigentllich ganz praktisch Arduinos und RaspPis für sowas nutzen zu können. Die sind für mich, als jemand "der mal HTML gelernt hat" wesentlich greifbarer als bspw. Logik-Gatter, bei denen ich erstmal googeln müsste was genau das ist und wie ich damit arbeiten müsste.
Das ist wohl der Unterschied zwischen jemandem, der das mal eben als Hobby macht und es einfach funktionieren soll oder jemandem, der das professionell und auf einem ganz anderen Niveau macht, wie @medusa .

 

[Pequi]

Vielleicht sollten wir sowas in einem anderen Thread diskutieren, da ich diesen hier mehr für eine Themenbezogene freihalten möchte...

 

[Pequi]

7.2.2017:
- Code-Optimierung
- Einfügen einer Startup-Message
- LED eingefügt, die blinkt, wenn das Magazin leer ist, ohne den Controller zu blockieren
- Präprozessoranweisung für deutsche oder englische Lokalisation
- Einfügen der DebugUtils.h und Testanwendung im Code. Wird nicht kompiliert, wenn die erste Zeile:

#define DEBUG       // für Debbugging => DEBUG_PRINT ("Text");

auskommentiert wird:

//#define DEBUG       // für Debbugging => DEBUG_PRINT ("Text");

 

[Dominik]

Ich habe meine Begeisterung schon am Sonntag persönlich zum Ausdruck gebracht, finde es aber immer noch begeisternd.

Und was die Bevorzugungen von diskreten Schaltungen oder Mikrocontrollern angeht, bei mir ist das der Unterschied zwischen SPS-Programmierung und "Klappertechnik" mit Schützen.

Eine Programmierung ist allgemein vielseitiger und leichter zu ändern, aber manchmal sind analoge Schaltungen tatsächlich präziser, einfach aufgrund der fehlenden A/D-Umwandlungen.

Ich nutze beides, jedenfalls im Rahmen meiner Fähigkeiten.

 

[Pequi]

10.1.2017:
- Code-Optimierung
- Magazin-LED pulsiert nun -> sieht cooler aus.
- Bugfix der Magazinfüllungserkennung
- Erweiterung der Schaltung um einen Festspannungregler LM78S05CV, um den Arduino aus dem Akku zu versorgen
- Die MOSFETs FQP30N06 werden vom Arduino nicht richtig durchgeschaltet, weil die Gatespannung höher sein muß -> ersetzt gegen den FQP30N06L

 

[Pequi]

Mittlerweile mal eines der 5 Arduino Pro Mini-Boards gelötet und getestet: funktioniert! Immerhin wird das Pro Mini in die RS eingebaut werden, weil kleiner. Warte noch auf das Wire Wrap-Geraffel (Tool und Draht) aus China... Dominik hat mich drauf gebracht -> genial!

BTW: Muß ich um den Festspannungsregler eigentlich die Kondensatoren drumherumbauen, wenn ich nur Gleichstrom aus dem Akku nehme und keine gleichgerichtete Wechselspannung? Guckst du hier:
(die umkreiste Diode nicht beachten...)

 

[Pequi]

11.2.2017:

- Überwachung der Gesamtspannung des Akkus mittels Spannungsteiler (10k Ohm und 4,7k Ohm) und enervierende Displaydarstellung. Deaktivierung der Blastermotoren bei Akkuspannung unter 10,2V bei 3S-Lipo (entspricht <3,4V/Zelle). Keine Einzelzellenüberwachung.

 

[Lorcan]

BTW: Muß ich um den Festspannungsregler eigentlich die Kondensatoren drumherumbauen, wenn ich nur Gleichstrom aus dem Akku nehme und keine gleichgerichtete Wechselspannung? Guckst du hier:
(die umkreiste Diode nicht beachten...)

Zu den Kondensatoren: Die dienen als Puffer, damit bei Lastwechseln auf der 5-Volt-Ebene der 78xx nicht anfängt zu schwingen. Dazu zählen auch PWMs oder das Schalten von Transistoren. Ich würde die drin lassen, sonst kann es sein, dass dein Arduino ständig neustartet(Brown-out-detector) oder sich aufhängt.

 

[Dominik]

Das sind aber gewaltig große Kondensatoren, normalerweise muss an den Eingang nur 330nF und an den Ausgang 220nF. (meine ich jedenfalls aus dem Kopf)

 

[Pequi]

Update:
17.2.2017:
- Überwachung der Gesamtspannung des Akkus stark überarbeitet, damit kurzzeitige Spannungseinbrüche, z.B. beim Anlaufen der Motoren, nicht zum Abschalten führen. Akku wird nur jede Sekunde vermessen und alle 5 Sekunden der Mittelwert gebildet. Damit wird das Akkumessen auch nicht so CPU-intensiv. Desweiteren Umstellung der Spannungsberechnungen von "float" auf "long". Die Berechnungen von Fließkommawerten sind extrem rechenaufwendig und auch ungenau (6.0 / 2.0 ergibt nicht zwingend 3.0 !!) und sollten daher vermieden werden.
- Warn-LED durch eine 10mm dicke Version ersetzt: sieht kuuhl aus!

 

[Pequi]

Einige sehr interessante Links zum Schaltplan der RapidStrike und Modifikationen, die mir sehr fundiert erscheinen. Diese Website hat neben diesen auch noch weitere sehr interessante Artikel:

https://torukmakto4.blogspot.de/2015/06/tech-rapidstrike-control-circuits-part-1.html
https://torukmakto4.blogspot.de/2015/07/tech-resistive-center-rapidstrike.html

Eine mikrokontrollergesteuerte RS:

http://nerfhaven.com/forums/topic/25012-tr-27-gryphon-cr-18-rapidstrike-mod/?hl= tr-27 gryphon

und der dazugehörige Film des infrarotlichtschrankengesteuerten Pushermotors:

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.

 

[Pequi]

Brauche mal 'nen Advokatus diaboli:

Ich hatte das Dartzählen mit vorgewählten Magazingrößen programmiert (wie ihr in Ulm gesehen habt) und dabei auf Null heruntergezählt.

Nun habe ich 3 Lichtschranken programmiert und auf dem Steckbrett geprüft:
- die Erste in der Kammer, um nur dann den Pushermotor zu starten, wenn auch ein Dart in der Kammer liegt. Ist der dann verschossen, wird er gezählt, wenn er durch die nächste Lichtschranke im Lauf fliegt. Kommt er dort nicht an, liegt eine Ladehemmung vor und der Blaster wird mit entsprechender Warnung gesperrt.
- die dritte Lichtschranke ist weit vorne im Lauf und mißt in Verbindung mit der Zweiten die Dartgeschwindigkeit wie ein Chrony.

Frage:
Ist Euch die Magazinvorwahl (oder gar später die Magazinerkennung mittels "Irgendwie-Codierung") und das Herunterzählen auf "Null" wichtig? Oder kann ich darauf verzichten und "Heraufzählen" von "Null" bis das Magazin komplett entleert ist. Dafür wird dann aber die "echte" Dartanzahl gezählt, unabhängig von der Magazingröße, welche dann weder vorgegeben noch irgendwie codiert werden muß. Ich spare mir dann auch einen Pin am Arduino, den ich für andere Sachen besser gebrauchen kann.

Beides halte ich für doppeltgemoppelt.

Was meint Ihr?

 

[Kommandante]

Es ist schon wichtig, ich würde eine Magazinvorwahl machen. So sparst Du Dir das ganze rumcodiere. Die Lichtschranken find ich super.
Je nach dem für was Du Deinen Arduinopin benutzt würd ich de Technik auch anpassen.
Für was willst Du den denn verwenden?

 

[Pequi]

Es ist schon wichtig, ich würde eine Magazinvorwahl machen. So sparst Du Dir das ganze rumcodiere.

Eine sinnvolle und einfache Magazincodierung, die beim Einlegen des Magazins die Größe automatisch vorgibt, habe ich noch nicht so richtig gefunden. Es werden im Netz Hall-Sensoren verwendet, die aber in der gewählten Konfiguration "nur" max. 9 verschiedene Magazingrößen erkennen können. Die Anzahl der mir bekannten Magazingrößen beträgt aber mindestens zehn! Also inklusive aller käuflichen Fremdherstellermagazine. Und dann könnte ja auch einer auf die Idee kommen, was selbst (huch!) zu basteln mit anderen Größen...

Eine automatische Magazinerkennung verlangt eine Codierung der Magazine mit Magneten, RFIDs, Barcodes oder Ahnlichem. Erscheint irgendwie aufwendig.

Für was willst Du den denn verwenden?

z.B. für einen RFID-Leser... oder so, oder irgendwas anderes. Habe nun schon fast alle Pins belegt. Fällt mir schon was ein.
Ma gucken...

 

[Moggih]

Ganz ehrlich? Magazinerkennung ist zwar schon irgendwie sexy, aber auch nur dann sinnvoll, wenn die Magazine auch immer komplett mit der Nenn-Stückzahl beladen wurden. Sonst weicht die Dart-Anzahl ja ohnehin ab.

Aufwärtszählen halte ich aus diesem und deinen bereits genannten Gründen für sinnvoller, weil einfacher und alles.