barney Geschrieben 22. Mai 2015 Autor Geschrieben 22. Mai 2015 Hallo Beatfreaktico, schon ins Wiki reingesehen. Plug and Play ist bei diesem Projekt nicht. Da musst du schon zum Lötkolbem greifen. Programmieren musst du nicht. Die Software liegt vor. Du musst diese nur in den Microcontroller laden. VG Barney Zitieren
Dude Geschrieben 25. Mai 2015 Geschrieben 25. Mai 2015 Hi Barney, ich hab bei meinem Board noch die Controller HW Version 08/2014 am laufen, die Du mir gelötet hast. Nun möchte ich die neueste Version der SW aufspielen ... spontan fällt mir ein, dass mittlerweile andere Pins zur Strommessung verwendet werden. Weißt Du, was ich sonst noch beachten muss (weitere Änderungen)? Bin dankbar für jeden Hinweis! Gibt es weitere User, die noch mit der "alten" HW fahren? Dann würde ich die Anpassungen in der SW, damit die noch mit älteren HW-Versionen läuft, umschaltbar/parametrierbar einbinden. Ansonsten eher quick and dirty für mich (ist dann ein separater Branch in Git???). Gibt es sonst noch irgendwelche todo's in der SW? Absicherung gegen versehentliches Umschalten direct drive/tempomat? Kai, wenn für Dich in Ordnung würde ich das ggf. im Wiki dokumentieren. Kannst Du mir Schreibrechte einrichten und sagen, wie ich drauf zugreife/Änderungen einpflege? Zitieren
barney Geschrieben 25. Mai 2015 Autor Geschrieben 25. Mai 2015 Hi Dude, ich habe im Wiki einen Abschnitt, welche Pins umgelötet werde müssen, damit die neue ADC-Routine verwendet werden kann. Wenn du kein Brmesservo verwendest, musst du nur eine Brücke löten, die mit Fotos in Wiki dokumentiert sind. Beide Varianten lassen sich nicht per Software abbilden, da zwei ADCs im Teensy sind, die nur bestimmte Pins adressieren können. Leider nicht die Pins die ich in den früheren Versionen verwendet habe. Wenn beide ADCs gleichzeitig laufen, kann ich die Average Routine im Teensy (Hardware) verwenden. Das macht die Messungen störunanfälliger gegen Rauschen. Hast du das Polynom schon getestet? Wenn was im Wiki nicht zu erkennen sein sollte, bitte ich ausdrücklich um Änderungen. Gerade meine Schlechtschreibung und die Joda Satzbauten. VG Barney Zitieren
Dude Geschrieben 25. Mai 2015 Geschrieben 25. Mai 2015 (bearbeitet) Polynom wollte ich bei der Gelegenheit auch testen - bin gerade im Urlaub und hätte da ein wenig Zeit (bilde ich mir zumindest ein). Blöd, dass ich keinen Lötkolben zum Brückenlöten mitgenommen habe. Temporäre Fix bis Lötkolben zur Hand: Ich werde dann wohl zunächst noch die "alten" Elemente der SW zur Strommessung verwenden und das dann später updaten. Bei der Gelegenheit kann ich mich dann endlich mal mit Sourecetree vertrauter machen. (Beim Abbilden beider Varianten in SW meinte ich tatsächlich getrennte Teile des Codes aktivieren, wobei dann natürlich unterschiedlich genaue Messungen statt finden.) P.S.: ist im Wiki sehr gut zu erkennen, ich habe nur in der falschen Sektion "BoardController" statt "BoardController löten" gelesen. Ich werde sobald ich Zugriff auf's Wiki habe einen Querverweis einfügen. Danke! bearbeitet 25. Mai 2015 von Dude Zitieren
Dude Geschrieben 26. Mai 2015 Geschrieben 26. Mai 2015 Hi Barney, ich seh mir gerade die neuen Features im Code an und habe folgende Fragen: 1. gibt es einen Grund für die Verwendung von FASTRUN bei der UI-Ausgabe, war's ohne zu langsam (rein aus Interesse)? 2. Was genau war der Grund, dass Du den Drivemode-Umschalter deaktiviert hast? Ich meine Du hast mal aus versehen umgeschalten ... wenn Du eine Idee hast, wie das vermieden werden soll, würde ich versuchen es zu implementieren 3. Ich würde den Leerlaufoffset wieder in integrieren (drivemodespezifisch) - spricht was dagegen? VG Dude Zitieren
barney Geschrieben 27. Mai 2015 Autor Geschrieben 27. Mai 2015 Hi Barney, ich seh mir gerade die neuen Features im Code an und habe folgende Fragen: 1. gibt es einen Grund für die Verwendung von FASTRUN bei der UI-Ausgabe, war's ohne zu langsam (rein aus Interesse)? 2. Was genau war der Grund, dass Du den Drivemode-Umschalter deaktiviert hast? Ich meine Du hast mal aus versehen umgeschalten ... wenn Du eine Idee hast, wie das vermieden werden soll, würde ich versuchen es zu implementieren 3. Ich würde den Leerlaufoffset wieder in integrieren (drivemodespezifisch) - spricht was dagegen? VG Dude Hallo Dude, zu 1.) Ich habe Fastrun rein aus Interesse implementiert. Natürlich habe ich die Ausführungszeiten gemessen und verglichen. Bei bestimmten Operationen, wie Berechnungen, ist eine Verkürzung der Ausführungszeit zu beobachten. Keinen positiven Effekt konnte ich bei Schnittstellenoperationen messen, was auch zu erwarten war. zu 2.) Die Drivemode Umschaltung in der jetzigen Form hat zu Situationen geführt, wo die Winkelgeschwindigkeit des Rades höher war als mein Hintern es erwartet hat. Das Board war zweimal Autonom unterwegs, was ich im Sinne des Fahrspaßes für Suboptimal halte. Die Routine müsste auch ein Zeitfenster bekommen, wo die Kommandokette als gewollt erkannt und gewertet wird. Meine damit, eine Umschaltung sollte innerhalb von 2 Sekunden erfolgen, danach sollten eventuelle Teilkommandos verworfen werden. zu 3.) Kannst du gerne wieder reaktivieren. War nicht beabsichtigt. Wenn du gerade dabei bist am Code was zu ändern, dann siehe dir bitte mal die Bremsservo Routine an, die ist nur Rudimentär und nicht gerade funktionell. Auch der Blinker ist nicht wirklich Blinkig. Ich habe momentan für die Programmierung keine Zeit und möchte lieber an den Leiterplatten weiterarbeiten. VG Barney Zitieren
Dude Geschrieben 27. Mai 2015 Geschrieben 27. Mai 2015 Danke. Bremsservo etc. kann ich mir gerade allerdings nur als Trockenübung ansehen, da ich nix davon angeschlossen habe. Ich wollte, sobald die neue SW auf meinem alten Platinenlayout läuft mich ein wenig um die Ankopplung meines BananaPro via BT an den Teensy kümmern. Zumindest läuft der BPi schon mal, ich kann mich einloggen und die ad-hoc-Netzwerkverbindung zu meinem MacAir geht auch schon. Wie das ganze weiter gehen soll weiß ich nicht aber ich hoffe der Kai hat den ein oder anderen Hinweis für mich. Apropos keine Ahnung: das ging schon damit los, dass ich hinter "bootstra(i)pping" was ganz anderes vermutet hätte ... ich werd mich zunächst mal durch sein Script kämpfen müssen. Was ich aber weiß ist, dass ich jetzt gerade offtopic bin - tschüß Zitieren
Dude Geschrieben 28. Mai 2015 Geschrieben 28. Mai 2015 (bearbeitet) Hi Barney, Zwischenstatus zur Spannungsmessung: 1 x 120 kOhm auf der Platine verwendet, 42,9 V als BattSpgMax in Parameters.h eingetragen tatsächliche Batteriespannung: 32,9 V (mit Messgerät gemessen) UBatt und UBattPoly liefern hierzu unterschiedliche Werte (ca. +2-3 Volt). Das kommt mir recht viel vor. Frage zu weiterem Vorgehen: BattSpgMax in Parameters.h so lange anpassen, bis UBattPoly = gemessene Batteriespannung (dann wird wohl das Polynom nicht mehr stimmen)??? Oder die 42,9 V stehen lassen und alles über das Ausgleichspolynom korrigieren??? Ach ja: Dummerweise bin ich beim Spannungsmessen an beide Pins gleichzeitig ran gekommen ... bambam ... Pin für Spannungsanschluss auf der Platine kurz mal abgeschmolzen ... kein Lötkolben zur Hand :mad: bearbeitet 28. Mai 2015 von Dude Zitieren
barney Geschrieben 28. Mai 2015 Autor Geschrieben 28. Mai 2015 Die neuen Platinen sind da: Gut, dass die Leiterplatten auf Kurzschluss und Durchgang getestet werden. Siehe Teensy Pin. 2 Zitieren
barney Geschrieben 28. Mai 2015 Autor Geschrieben 28. Mai 2015 Hi Barney, Zwischenstatus zur Spannungsmessung: 1 x 120 kOhm auf der Platine verwendet, 42,9 V als BattSpgMax in Parameters.h eingetragen tatsächliche Batteriespannung: 32,9 V (mit Messgerät gemessen) UBatt und UBattPoly liefern hierzu unterschiedliche Werte (ca. +2-3 Volt). Das kommt mir recht viel vor. Frage zu weiterem Vorgehen: BattSpgMax in Parameters.h so lange anpassen, bis UBattPoly = gemessene Batteriespannung (dann wird wohl das Polynom nicht mehr stimmen)??? Oder die 42,9 V stehen lassen und alles über das Ausgleichspolynom korrigieren??? Ach ja: Dummerweise bin ich beim Spannungsmessen an beide Pins gleichzeitig ran gekommen ... bambam ... Pin für Spannungsanschluss auf der Platine kurz mal abgeschmolzen ... kein Lötkolben zur Hand :mad: Polynom: Hast du die Koeffizienten für das Polynom neu bestimmt?. Wenn du andere Widerstände verwendest und damit den Messbereich veränderst, musst du natürlich die Spannungskurve, mit 5-6 Messpunkten über den gesamten Messbereich, neu aufnehmen und die Koeffizienten bestimmen. Dafür sind die zwei Methoden hier beschrieben worden, um mit Scilab oder Libre Office dies zu tun. Kurzschluss: Jetzt weißt du, warum die Projektreihe BamBam heißt. Warte ab, bis ich mit dem Toshiba Sigma ESC die ersten MOSFETs gekillt habe. Da ist noch ganz viel BamBam drin. Oder Bum? Viele Grüße Barney Zitieren
Dude Geschrieben 28. Mai 2015 Geschrieben 28. Mai 2015 Polynomstützpunkte werde ich aufnehmen, sobald ich wieder eine variable Spannungsquelle zur Verfügung habe. Mich hat nur gewundert, dass bereits der nicht korrigierte Wert UBatt um 2-3 V von der tatsächlichen Spannung abweicht. So wie ich Dich verstehe ist das aber in Ordnung?! Implementierung zur maximal zulässigen Dauer für einen Umschaltvorgang (Hase/Igel oder DriveMode) ist in der Mache und bald im Code drin. Zitieren
Dude Geschrieben 29. Mai 2015 Geschrieben 29. Mai 2015 (bearbeitet) Hi Barney, Umschaltung DriveMode ist jetzt sicher(er). Ich hab mittlerweile auch gesehen, was Du mit "rudimentärer" Implementierung der Bremse gemeint hast. Hoffentlich verwendet das keiner so :devil: Sobald ich das Ausgleichspolynom für den Wertebereich 43 V neu bestimmt und den Fix für die alte Platine gelötet habe stell ich den getesteten Code wieder ins Git. bearbeitet 29. Mai 2015 von Dude Zitieren
Dude Geschrieben 29. Mai 2015 Geschrieben 29. Mai 2015 Thema Bremsservo Da ich leider keinen verwende wollte ich vor einer Implementierung in die Software so eine Art Lasterheft-Light abfragen. Abfrage geht an alle, insbesondere an die, die schon Erfahrung mit Bremsservos besitzen und an unsere potentiellen Nutzer aus den Bergregionen (Allgäuer, Schweizer, etc.). In einem ersten Entwurf stelle ich mir folgende Funktionalitäten vor: 1. Generell ist bei aktiver Servobremse die Motorbremse inaktiv. Während des Betriebes lässt sich dies jedoch umschalten (3x c-Taste bei Joystick links). Damit hätte man schon eine Redundanz, falls der Servo und die nachgelagerte Mechanik ausfällt. 2. DirectDrive: Bremse aktiv, sobald der Joystick nach hinten geht. Lineares Bremsverhalten, weitere Parametrierung des Bremsverhaltens über Kennlinie mit versch. Exponenten in Parameter.h möglich 3. Tempomat (Incremental Drive): Bremse aktiv sobald Joystick hinter seiner Neutralstellung UND der Vorgabewert für die Drehzahl kleiner als die Leerlaufdrehzahl ist. D.h. solange die Drehzahl noch über der Leerlaufdrehzahl ist wird diese lediglich verringert und noch nicht gebremst (ist aktuell auch bei reiner Motorbremse schon so). Generell ist der Bremstempomat eine feine Sache. Man kann dadurch eine bestimmte Bremskraft einstellen, und diese bleibt erhalten solange die Z-Taste gedrückt ist (Joystick kann man nach der Einstellung loslassen). Ist sehr komfortabel, wenn man länger den Berg runter fährt. Das alles ist halt nur rein theoretisch. Da Bremsen eine heikle Sache ist, wären Hinweise aus der Praxis prima bevor ich mich an eine Umsetzung mache. Ach ja, danach bräuchte ich noch ein Versuchskaninchen! P.S.: Nur so aus Interesse, wär fährt denn eigentlich mit dem Bam-Bam Controller & Nunchuk? Dude Zitieren
eXo Geschrieben 29. Mai 2015 Geschrieben 29. Mai 2015 (bearbeitet) Hi Dude, Leider habe ich noch keine Erfahrung mit den Bremsservos. Würde dies beim aktuellen Umbau aber gerne einbauen, da hier noch ein paar Channel-Trucks mit Magura-Bremsen rumliegen. Punkt 1, macht mir ein bisschen sorgen, weil ich viel lieber hinten mit den Motoren, als vorne über die Maguras bremse. Ich dachte eigentlich immer an eine voneinander unabhängige Verteilung mit zwei definierbaren Kurven. Ich versuche mich mal zu erklären. Sobald sich das Board in Bewegung befinde hätte ich gerne ein lineare Bremsverteilung von z.b 25% über die Servo (vorne) und 75% über die Motoren (hinten). Im Stillstand sollten beide Systeme gleich stark bremsen. Daraus müsste nun ein Drehzahl abhängiges Bremsverhalten resultieren. Je höher die Drehzahl umso stärker möchte ich hinten bremsen. Kriegt man das hin oder ist das zu viel des guten? Punkt 2, ist Top! Punkt 3, klingt sehr komfortabel. Ich kann mir das so noch nicht ganz vorstellen um ehrlich zu sein. Liegt vielleicht daran das mein Controller seit Tagen bei mir rumliegt und ich noch keine Zeit oder Mut hatte daran rumzulöten. Mahlzeit bearbeitet 29. Mai 2015 von eXo Zitieren
barney Geschrieben 29. Mai 2015 Autor Geschrieben 29. Mai 2015 P.S.: Nur so aus Interesse, wär fährt denn eigentlich mit dem Bam-Bam Controller & Nunchuk? Dude Diesen Gedanken hatte ich auch schon vor einige Wochen, gepaart mit einer Verwendungs- und Versionsabfrage: Boardtyp: Street Version der Leiterplatte: v3.71 Version der Software Datum: Spannungsbereich des Akkus in S: Maximaler Strom: HV-Regler (1/2) Sonderfunktionen: Licht (X) Hupe Bremslicht Blinker R/L Spannungsmessung Strommessung Bluetooth-Übertragung Bremsservo Irgendwas habe ich Vergessen, ich weiß nur nicht was. Zitieren
Dude Geschrieben 29. Mai 2015 Geschrieben 29. Mai 2015 Punkt 1, macht mir ein bisschen sorgen, weil ich viel lieber hinten mit den Motoren, als vorne über die Maguras bremse. Ich dachte eigentlich immer an eine voneinander unabhängige Verteilung mit zwei definierbaren Kurven. Ich versuche mich mal zu erklären. Sobald sich das Board in Bewegung befinde hätte ich gerne ein lineare Bremsverteilung von z.b 25% über die Servo (vorne) und 75% über die Motoren (hinten). Im Stillstand sollten beide Systeme gleich stark bremsen. Daraus müsste nun ein Drehzahl abhängiges Bremsverhalten resultieren. Je höher die Drehzahl umso stärker möchte ich hinten bremsen. Kriegt man das hin oder ist das zu viel des guten? Punkt 2, ist Top! Punkt 3, klingt sehr komfortabel. Ich kann mir das so noch nicht ganz vorstellen um ehrlich zu sein. Liegt vielleicht daran das mein Controller seit Tagen bei mir rumliegt und ich noch keine Zeit oder Mut hatte daran rumzulöten. Mahlzeit ad1: Geht. Im Teensy hab ich allerdings keine Drehzahlinformation - nur die Stellwertvorgabe, die ist im Schubbetrieb allerdings beliebig weit von der Drehzahl entfernt. Die %-Bremse im APS Controller ist allerdings proportional zur Drehzahl (viel Drehzahl = viel Bremsmoment = viel Abwurf. Ist also mit Vorsicht zu genießen, man merkt das aber schnell). Ich kann den Bremswunsch einfach wie bisher an den Motorcontroller über die Sollwertvorgabe der Drehzahl weiterreichen und man kann im APS-Setup einfach die %-Bremse entsprechend dem eigenen Wunsch vorgeben. Eine Reduktion zu dem Setup mit Motorbremse allein ist allerdings ratsam, sollte aber noch genügend Luft nach unten sein (ich fahr mit 60-70%, ohne Servo). Der Maximalwert für den Bremsservo ist in Param.h wählbar und man kann damit das Bremsmomentniveau der Servobremse frei wählen. Das Beste: es ist diesmal unabhängig von der Drehzahl und in Kombination mit der Motorbremse sind die Kombinationen quasi unendlich. Nachteil: man stirbt evtl. den Parametriertod und hat keine Redundanz mehr. D.h. wenn der Bremsservo ausfällt ist die maximale Bremskraft der Motorbremse im APS nicht ohne Laptop zu ändern und wohl eher zu klein eingestellt ... there's no free lunch. ad2: Ja, ist allerdings die leichteste Übung. ad3: IST komfortabel, absolut! Dude Zitieren
Dude Geschrieben 29. Mai 2015 Geschrieben 29. Mai 2015 Dude Boardtyp: Street Version der Leiterplatte: v2.3 mit ADC fix Version der Software Datum: v41p1 Spannungsbereich des Akkus in S: 8S Maximaler Strom: 120 A (ESC) HV-Regler: 1 ESC 3-12S LiPO 120 A Opto Alien ESC Type: Car 3-16S Firmware V4.5 (CAR16S_V45) Sonderfunktionen: Spannungsmessung (in Arbeit) Strommessung (in Arbeit) Bluetooth-Übertragung Zitieren
barney Geschrieben 31. Mai 2015 Autor Geschrieben 31. Mai 2015 Boardtyp: Street Version der Leiterplatte: 08/2014 Version der Software Datum: Immer die aktuelle Version von mir Spannungsbereich des Akkus in S: 8 (LiPoFe) Maximaler Strom: 50A (Sicherung) Leistung des Akkus: 240W HV-Regler (1) Sonderfunktionen: Licht () Hupe () Bremslicht () Blinker R/L () Spannungsmessung (X) Strommessung (X) Modifikation gemäß Wiki Bluetooth-Übertragung (X) Bremsservo () Zitieren
barney Geschrieben 2. Juni 2015 Autor Geschrieben 2. Juni 2015 Jetzt habe ich ein Teensy weniger. Heul! Der Temperatur Sensor für dem Motor hat auf den Boden sich abgeschliffen und beim Befestigen am Motor eine Überspannung im Teensy verursacht. Meine Ausfahrt dauerte 2 Sekunden. Zitieren
barney Geschrieben 7. Juni 2015 Autor Geschrieben 7. Juni 2015 Neues Feature: Messung der Asphalt Temperatur. Nicht empfehlenswert. Zitieren
Dude Geschrieben 7. Juni 2015 Geschrieben 7. Juni 2015 Dein neuer Schleifkontakt für's Fahren auf Bahngleisen Zitieren
elkick Geschrieben 7. Juni 2015 Geschrieben 7. Juni 2015 Habe ich gestern mit einem Lipopack versucht, geht auch nicht! PS. Es hat's gerade so überlebt. Zitieren
barney Geschrieben 10. Juni 2015 Autor Geschrieben 10. Juni 2015 Leiterplatten Hersteller: Externe Links nur für Mitglieder sichtbar Multilayer erscheint bezahlbar und die Preise sind verlockend, aber 3-4 Wochen Lieferzeit. Zitieren
Dude Geschrieben 10. Juni 2015 Geschrieben 10. Juni 2015 Neue SW-Version ist validiert und im Git (hoffe ich, da ich mich mit Sourcetree noch nicht so richtig anfreunden konnte): - DEBUG-Flag aus Settings.h entfernt, da ohne Verwendung. Verallgemeinerung der Ausgabe auf 2 generelle Ausgabekanle (USBSerial und BT) - Update Kommentare - Motorsteller-Offset wieder eingefuegt (zeigt nicht den gewuenschten Effekt, obwohl der Motorstellwert korrekt erhoeht wird, ist noch zu ueberpruefen) - Umschaltung DriveMode und Stellwerbegrenzung ist gegen versehentliches Umschalten geschuetzt (muss innerhalb einer vorgegebenen Zeit statt finden) - Korrekturpolynom fuer 42,9 V Messbereich ergänzt Dude 1 Zitieren
ToniGadget Geschrieben 15. Juni 2015 Geschrieben 15. Juni 2015 Soooo... nachdem ich endlich die ersten Teile aus China bekommen habe, habe ich mal eine kleine Versuchsanordnung gemacht (siehe Anhang). Als Eingabemedium habe ich einen Mini-Joystick mit Tastfunktion gewählt. Dieses deshalb, weil nur drei Eingänge am Arduino belegt werden. Poti rauf/runter = Menü durchblättern Poti links/rechts = Menüwerte ändern Tastfunktion = Enter/Bestätigen Und durch die Wahl eines Potis statt Eingabetaster kann man auch eine Geschwindigkeitsabhängige Werteänderung vornehmen. So kann man bei großen Zahlenwertunterschieden schnell dort "hingespullt" werden. Das Bluetoothmodul (HC-05) ist auch schon verdrahtet und programmiert mit Name & 115200 Baud. ich habe das Projekt "E-Skateboard DSU" genannt. DSU steht für Direkt Setting Unit" ToDo: - Programm schreiben *Grundgerüst *BT-Anbindung *Temparatur *Speicher für verschiedene Settings - Gehäuse - DSU auf Akkubetrieb umstellen (LiPo 3,7V & DC-Step-Up Chinamodul) - Akkuladeelektronik (China-Modul) - Temparatursensor(en) integrieren (DS18b20) *Umgebungstemparatur *Fühler für externe Messung (z.B. Asphalt, Fahrakku, Motor am E-Skateboard, Angstschweiß...) - RTC (?) Wünsche / Anregungen ??? @Barney Wie viele Werte sollen eingestellt werden ? Wie lautet deren Name ? Welcher jeweilige Werte Bereich ? 1 Zitieren
Empfohlene Beiträge
Tritt dem Gespräch bei
Du kannst jetzt posten und dich später registrieren. Wenn du bereits einen Account hast kannst du dich hier anmelden.