2-Channel Ant_FR

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Sooooo,

      ich war gestern wieder ganz fleißig!!

      Und zwar musste ich erstmal einen Fehler beheben. Und zwar sah das PWM-Signal gaaaaaanz grausig aus! Der Übeltäter war, wie sich später heraus stellte, meine ADC-Messung!

      Und zwar dauert die laut Datenblatt bis zu 260µs! Bei einer PWM-Frequenz von 4kHz, also einer Periodendauer von 250µs, blieb dann halt bei jedem Programm-Durchlauf ein ganzer PWM-Zyklus dauerhaft ein, bzw. ausgeschaltet...

      War zugegeben nicht sehr geschickt von mir die Spannung bei jedem Programm-Durchlauf zu messen. Nun messe ich nur jede 1/10 Sekunde die Spannung, was ja schon sehr fix ist.
      Die Auswirkungen auf die PWM sind praktisch nicht mehr messbar!

      Nachdem die PWM dann wieder auf dem alten Stand war, hab ich durch eine kleine Programmänderung das PWM-Signal noch etwas schöner gekriegt!! ;)

      Nun schwanken meine Impulsbreiten nurnoch um wenige µs ! TOP! Bleibt so! ;)


      Dann hab ich mich meiner verbesserten Akku-Anzeige gewidmet:
      Und zwar messe ich jetzt, so wie ich es ja auch vorhatte, beim initialisieren des Reglers die Spannung und sage dann: Ich hab 2-, ich habe 3 Zellen an Bord!
      Bei initialisierten zwei Zellen blinkt die blaue Status-LED zwei- bei drei Zellen drei mal!

      Danach wird die Akku-Warnung nurnoch auf meine Anzahl an Zellen angewendet!

      LÄUFT! ;)


      Was jetzt noch fehlt: Ich möchte versuchen auch die EmPus beim initialisieren zu messen und aus dem Wert die "Neutralstellung" der Funke zu machen.

      Somit wäre es auch für "günstigere Funken" ohne Trimmer möglich, den Ant zum "stehen" zu bringen. (auch wenn der Regler ja eig. nur für die Orange-Empfänger gedacht ist)

      Immernoch aktuell ist die Sache mit der Bremse.... Schön wäre es, das Ding etwas bremsen zu können, wenn man vom Gas geht.
      Das ist halt möglich, wenn man die komplette H-Brücke durchschaltet, so wird ja auch der Motor kurzgeschlossen.
      Aber dann kann ich mir meine süßen 0603er Sicherungen schonmal parrat legen... ;)

      Eine andere Sache viel mir jetzt gerade noch ein:
      Wenn man jetzt z.B. Vorwärts fährt, und die Halb-Brücke Vorwärts dann ausschaltet, die Halbbrücke Rückwärts dann ganz kurz durchsteuert, dann steht das Ding ja eig. auch! Ganz ohne Kurzschluss! :P

      Müsste man mal testen! ;)



      Auf jeden Fall habe ich den Regler jetzt in meinen DredgerII eingebaut und einen Film gemacht, Fährt sich ansich sehr gut!! Das Vid wird noch nachgeliefert! ;)
    • Hehe, ist mir klar Mike! ;)

      Das Problem ist ja hier wiedermal, das ich die Low-FETs ansteuere, und diese dann die High-FETs mit durchsteuern. Halt genauso wie bei den Mini-Reglern.

      Ich hatte ja eig. vor, alle FETs einzeln anzusteuern zu können. Wegen eines dämlichen Denkfehlers war das aber dann doch nicht möglich.

      Darum meine Überlegung, die Bremse anders zu lösen. :)
    • Das war ja meine letzte Überlegung! ;)

      Halte ich auch für die beste Art das Problem so ein bisschen zu lösen! :)
      Muss mir nurnoch überlegen, wie ich das integriere.



      Habe den Regler gestern auf meine Sumobot-Plattform gebaut (so eine von Pololu). Als Testplattform sehr genial! Da sind nämlich auch unsere Mini-Getriebemotoren vebaut. Mit den Raupenrädern müssen sich die Motoren auch richtig qulälen! Gut so, denn da tat sich gleich ein weiterer Hardware-Fehler auf! ;(



      Ich muss eine Diode für den Eingangsteil der 5V-Versorgung haben. Die Motoren saugen mir alle Kondis (zumindest die vor dem Spannungsregler) leer... ;(
      Der Empfänger ist mir bei größerer Belastung immer Resettet...

      Habe jetzt meine Verpolschutzdiode, die eig. Antiparallel zur Einspeisung war, in Reihe gesetzt und einen kleinen Kondi dahinter, also nur für den Spannungsregler, gesetzt.

      Läuft jetzt endlich!! :)

      Konnte schön mit dem Ding rumheizen! :D


      Dazu habe ich noch im Failsafe-Modus, sprich dem langsamen Blinken der blauen Status-LED, die Spannungsmessung integriert. Wenn der Akku nun leer ist und der Regler in den Failsafe-Modus geht blinkt nun die rote LED langsam! ;)
      Kleine Spielerei, aber ich hatte gestern schon das Problem, das die blaue LED blinkt, und als ich die Funke wieder angemacht habe, auf mal die Rote LED blinkte... Ups ;)


      Edit:
      Hier meine neue Testplattform: ;)

    • Gegenkontern. Kurzen Impuls in die andere Richtung.

      8o Also wie beim Autofahren: Statt auf die Bremse zu treten, legt man den Rückwärtsgang ein und lässt die Kupplung springen. Provokativ gesagt: Mal sehen, wie lange das die Endstufen mitmachen...

      und einen kleinen Kondi dahinter

      Gönn' dem Microcontroller und dem Empfänger ruhig ein paar Millisekunden länger an sauberer Versorgungsspannung. Tantal-Elkos sind zwar nicht besonders langlebig, aber dafür sehr klein. Da gibt's schon Baugrößen von 1206, die haben dann 330uF. (Ich verwende 150uF). Damit hälst Du bei einem Spannungseinbruch auch locker einige hundert Millisekunden durch, ohne dass etwas durch den Reset geht.
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Jo, ich hab welche mit, ich glaube, 47uF und der Größe 0603 ! :D

      Echt klasse die Teile. :)


      Ja, die Bremse ist brutal, wenn ich das überhaupt hinkriege. Aber die Endstufe stecken das denke ich weg. Ich habe gestern schon die Motoren blockiert und Vollgas gegeben, bzw. auch schon wie wild zwischen Vor- und Rückwärtsgang gewechselt. Und da passiert Thermisch nichts! :) -> FDS8333

      Mal sehn, wenn der Regler geschrottet wird, weiss ich Bescheid. :P
      Ich muss die Platine eh Ändern wegen der Einspeisung. Darum tüftle ich schon an einer besseren H-Stufe. Aber bei der Größe ist das echt ne Kunst für sich...
      Ich versuche grad ein Layout zu machen mit einzelnen FETs als H-Brücke (die von den Minireglern), mal sehen ob ich das schaffe.

      Aber für den Anfang reicht ja die momentanen Ausführung. ;)
    • Also iwi mag ich ja meine kleine Testplattform! ;)


      Hab gestern mal ein wenig ge-crawler-t ! ;)


      klick


      Hat jetzt nicht viel mit dem Regler zu tun, ausser das der jetzt einen super Job macht, aber egal! ;)


      Ich hatte die letzten Tage aber noch ordentlich Action mit dem Ding...

      Und zwar verfluche ich ja den ATTiny... Während des Programmiervorgangs gibt es ein Zeitpunkt, in dem der uC wohl mal alle Ausgänge durchschaltet... Bei einer H-Brücke nicht so geil. Dazu dauert das Proggen bei mir so lange, das AVR-Studio eine Fehlermeldung anzeigt, es würde zu lange dauern.
      Bis man die Fehlermeldung aber weg klickt, verharrt der uC aber bei dem momentanen stand, sprich wenn die H-Brücken durchgeschaltet sind...
      Auch kam noch dazu, das ich zu dem Zeitpunkt meinen LiPo angeschlossen habe und die Sicherung auf dem Regler überbrückt habe (die flog mir bei jedem Programmiervorgang raus).

      Naja, auf jeden Fall brannten mir die vier Halbbrücken-ICs weg und mein Empfänger wurde auch noch gegrillt...
      Die FETs hatten nämlich einen kompletten Durchgang also zwischen Source, Emitter UND GATE
      Somit sind wohl mein uC und darauf hin der Empfänger hops gegangen 8o 8o



      Totales Chaos....


      Naja, hab jetzt den Ersatzregler drin und der tut!

      Proggen tu ich jetzt nurnoch am Labor-NT und abgestöpselten Motoren (ohne Motoren schließt der die Brücken nämlich nicht so kurz... komisch...)
    • (ohne Motoren schließt der die Brücken nämlich nicht so kurz... komisch...)

      Ich will's jetzt nicht besser wissen, aber Du betreibst die Gate von den P-FETs nicht direkt an den µC-Ports, oder?
      => Damit der P-FET sauber sperrt, braucht er VDD am Gate, also z.B. 7.2V des LiPo. Der Port von dem µC bringt aber im High-Zustand normalerweise nur 4.2-4.5V. ;)
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • #Update#


      - Bremse -> Check
      - automatische Neutralstellungs-Detektions-DingsBums -> Check



      Das WE war wieder sehr Produktiv! :)

      Und zwar habe ich zum einen die Bremse und zum anderen die Neutralstellungs-Erkennung (oder wie man das nennen kann) implementiert!


      Das Bremsen läuft folgendermaßen ab:
      Und zwar jedes mal wenn ich von Gas (Vor oder Zurück) in die Neutralstellung gehe, steuert der Regler den Motor für 10ms in die Gegenrichtung an! :)
      Läuft im Grunde sehr gut! Wenn ich die Motoren z.B. Rückwärts ansteuere (Vollgas) und den Knüppel dann loslasse, steht das Rad Augenblicklich! :) Meine Testplattform hebt sogar vorne ab, weil der so schnell steht! :D :D

      In der Vorwärtsrichtung klappt das noch nicht ganz so perfekt. Da dreht das Rad noch ein wenig länger, bevor es steht. Versteh ich noch nicht so ganz, da der Code ja für beiden Richtungen im Prinzip gleich ist... Naja, halt noch ein kleiner Bug!
      Um die FETs muss man sich meiner Meinung nach keine Sorgen machen. Ich daddel quasi jede freie Minute mit der Testplattform rum. Und da wird weder was heiß, noch flog mal die Sicherung oder so! :D Also ich finde das absolut unbedenklich! ;)


      Sehr Zufrieden bin ich mit der Neutralstellungs-Erkennung:
      Wenn der Regler gestartet wird, werden, nachdem die Akku-Zellen-Zahl erkannt wird, auch die EmPus einmalig gemessen und daraus die Neutralstellung gebildet!

      Also ist das Nachtrimmen passé! :D
      Somit wäre der Regler auch ohne Probleme für Funken günstigerer Preiskategorie, die halt keine Trimmer haben, einsetztbar! :D
      Man sollte dann nur die Knüppel in Ruhe lassen, wenn man den Bot anmacht. Das sollte aber machbar sein! ;)



      Was jetzt nur noch anliegt ist das Feintunig und optimieren des Codes! Aber da gibt es ein Problem...

      DER FLASH-SPEICHER DES UCs IST RANDVOLL!! 8o 8o
      Ich hatte schon öfters die Meldung, das der uC zu 100,4% Voll ist o_O
      Hätte nicht gedacht das ich sowas jemals erlebe... Oha... Das heisst, ich muss den Code echt noch etwas optimieren/komprimieren...
      Bin jetzt wieder bei ~96% angelangt, aber alleine einen Port setzten, kostet ~0,2% Speicher, wie ich feststellen musste. ;)

      Lol ;)

      Naja, mal sehen, im Grunde ist ja alles drin was ich haben wollte, jetzt geht es wie gesagt an die Bugs und den Feinschliff, aber blöd, das ich da echt aufpassen muss jetzt!

      Ich seh schon, Leute die richtig programmieren können, hätten diese Funktionalität wahrscheinlich mit 50-75% des Speichers hingekriegt... ;(
      Naja, iss halt so :P
    • Und zwar jedes mal wenn ich von Gas (Vor oder Zurück) in die Neutralstellung gehe,

      Ist da vielleicht der Grund, dass die in einer Richtung nicht funktioniert? Ich hatte das Problem auch mal, dass bei einem Richtungswechsel die Bremse nicht gesetzt wurde (bei mir werden die Motoren erst kurzgeschlossen, bevor die Gegenrichtung aktiviert wird). Da war das "Zeitfenster" von der Neutralstellung zu klein . Also praktisch die Hysterese von dem Kreuzknüppel der Fernsteuerung nicht berücksichtig. Wenn Du von "Vollgas-Vorwärts" den Knüppel loslässt und der schnellt zurück, ergibt sich ein anderer "Neutralstellungs-Zeitwert" als wenn der Knüppel von "Vollgas-Rückwärts" zurückfedert.

      Ich denke, Du hast bei der Neutralstellung kein kleines "Neutralstellungs-Fenster" implementiert, damit der Bot nicht bei jedem Fliegenhuster an der Funke schon das fahren anfängt?

      Ebenso war bei mir mal der Effekt, dass bei schnellen Richtungswechseln (Vollgas-Vorwärts auf Vollgas-Rückwärts) die Neutralstellung von der Funke gar nicht an den Empfänger versendet wurde. Also war da zunächst gar keine Erkennung von einem Bremskommando möglich. Darum die Statusmaschine im Programm so angepasst, dass die Bremse bei Neutralstellung und bei Richtungswechsel anspringt.

      Was hast Du denn als Totzeit zwischen dem Richtungswechsel drin? (Also zwischen den 10ms Bremspuls und dem Anfahren in der Gegenrichtung?)

      DER FLASH-SPEICHER DES UCs IST RANDVOLL!!

      Willkommen im Club! ;) Aber es gibt normalerweise immer pinkompatible Prozessoren, die ein paar Cent mehr kosten und dafür das doppelte an Speicher zur Verfügung stellen. ;)
      .
      Interesse an Elektronik für Schaukampfroboter und Kettenfahrzeuge (Fahrtregler, ESC) ? => http://www.Robots.IB-Fink.de
    • Hehe, hast recht! Darum heißen die ATs ja auch
      ATTiny261
      ATTiny461
      ATTiny861

      :P

      So ganz freunde ich mich damit aber gerade nicht an.
      Ich nutze ja den ATTiny26, einen ATTiny46 gibt es leider nicht, nur die genannten 461 etc.

      Pin-Kompaktibel sind die wohl, nur beim 461 gibt es noch ein paar Funktionen mehr. Da hab ich schon ein wenig Angst, das da was nicht passt...

      Hmm, ich wollte mir in der nächsten Zeit (nach Behebung der Bugs) zwei neue Regler aufbauen und meinen Dregders einpflanzen. Da ich das Material eh bestellen muss, gehe ich das Risiko denke ich einfach mal ein! ;)
      Sind im Übrigen ganze 6Cent mehr für den 461... Unverschämt, lol :D ;)



      Eine Hysterese hab ich natürlich drin! ;) Die werde ich aber evt nochmal etwas vergrößern. Mal schauen! ;)

      Also eine Totzeit/Hochlaufzeit hab ich nicht drin, die Empfängersignale werden direkt zur PWM umgerechnet. ;)
    • Ich glaube ich muss die Maße für die Höhe des Reglers korrigieren. :D

      Wie ich eben bemerkt habe, haben die neuen Orange-Empfänger keinen Elko mehr an Bord, sondern einen kleinen Tantal-Kondi.

      Gleichzeitig habe ich heute mein Layout für die Version 1.2 (vorerst) fertig gekriegt. Und da sich da auch eine Menge geändert hat, musste ich dort auch auf einen viel Platz-sparenderen Tantal zurückgreifen!

      Somit kann ich den Regler und den Empfänger dichter zusammen setzen! Grob geschätz spart das um die 5mm!! :D
      Somit wäre der Würfel nur noch um die 10mm hoch! Nice! (somit vlt. sogar dünn genug für einen Mike! :P) :D

      Kann sich natürlich noch was ändern. die neue Version lasse ich natürlich erst machen, wenn diese Version Software-Mäßig perfekt funktioniert. Wer weis, was da noch Hardwareseitig für Änderungen / Optimierungen gemacht werden müssen/können! ;)

      oot:
      Das Layout für meine neuen Mini-Ant-FRs habe ich auch schon fertig und lasse die mitsamt der Version 1.2 der 2Channel Regler machen. Hehe :D
      ende oot:


      Die Bremse tut jetzt übrigens auch in beiden Richtungen!
      Der mochte den Befehl

      if (fBremse_l == -1)
      {
      blablub
      }

      nur nicht...

      Und ja, die Variable wurde als "(sign) char" deklariert... hmm, naja egal! ;)

      Mit (fBremse_l == 2) funzt es! ;)



      Morgen kommt auch der ATTiny 461 an! ;) Sprich ich kann mich weiter austoben, hehe :D


      Noch eine Frage bezüglich Sinnhaftigkeit:

      Der 461 besitzt einen internen Temperatur-Fühler.
      Jetzt habe ich mir überlegt, da direkt auf der Unterseite der Platine die FETs sitzen (halt direkt unter dem uC), die FET-Temperatur indirekt zu messen.

      Sprich wenn der Sensor jetzt z.B. 60°C misst, die Temperatur der FETs also bei 80-100°C oder so ist.
      Sinnig oder Blödsinn? ;)
    • Flach ist immer gut. Aber ein alleskönner wäre super. Aber ich denke da meine Vorstellungen zu speziell, sind wird es sowas glaub ich nicht geben.

      Ideal wäre ja ein EM. Son Orange Satellit mit 2 Mosfet H-Brücken und einen 3Pol Anschluss für einen Bruschlessregler/Servo etc.

      Sollte ich mal Zeit haben würde ich mich gerne an so einem Regler ran wagen. Nur bin ich zu doof zum Programmieren.
      Erfahrungen sind was sehr nützliches, leider macht man sie erst kurz nachdem man sie gebraucht hätte...
    • Nö, ist alles geblieben. Wenn ich mal etwas Zeit habe, muss ich den Reglern aber nochmal unter das Gehäuse schauen... ;) passt noch nicht 100% ig.
      Wobei in Dredger MK2 hat der Prototyp-Regler die letzten zwei Events hervorragende Arbeit geleistet! <3

      Muss mal einen Testbot für meine Mini-Ant-FR v2 bauen. Die sind ja auch fertig und es Bedarf eig. nurnoch ein ausrechender Praxistest