Dude

Neueste Version des BLDC-Loggers wurde von Vedder an die FW2.16 angepasst. Jetzt geht's.

Hallo Hexa, bei mir ist es mehr eine Frage des persönlichen Könnens als der Möglichkeiten. a) Wixel an VESC: ich traue mir zu, mittes der Beispiele ein RF-Signal von Wixel2Wixel zu übermitteln, PPM erzeugen, an die PINs des VESC stöpseln und im BLDC GUI konfigurieren. Fertig. b) Raspi (USB) an VESC: ich kann ein Betriebssystem drauf braten, USB anschließen und dann geht's los. Irgendwas muss man in jedem Fall in der Firmware anpassen, um über die USB Schnittstelle die Kommandos zur Motorsteuerung abzusetzen (und sei es nur der gewünschte Duty Cycle). Ich kann ja nicht in der Kommandozeile des GUI's meine gewünschte Geschwindigkeit während dem Fahren eingeben. Also muss ich irgendwie verstehen, was Vedder da so programmiert hat ... und das geht (auch wenn es mich super interessiert) gefühlte Lichtjahre länger als wenn ich den Wixel programmiere. Was aber nicht heißt, dass ich es nicht doch irgendwann mache. c) Raspi & Wixel gleichzeitig macht keinen Sinn, wenn der Raspi schon BLE hat. Ich hatte nur wegen der Echtzeitfähigkeit Zweifel/keine Ahnung ob der nicht doch notwendig ist. Ich unterstütze da gern, aber kann nur auf dem aufbauen was jemand beisteuert, der was davon versteht (z.B. bei dem BamBam Controller hat das super mit Barney geklappt). Bei dem Nunchuk_rf bin ich gerade in einer Dead-Lock Situation. Um den zum Laufen zu bringen bleibt mir nur eine neue Platine zu löten und sehen, ob die Läuft. Oder mich in die Programmierung der Kommunikationsschnittstelle im Nunchuk_rf & VESC einzuarbeiten und versuchen, ob ich darüber an den Fehler komme. Aber das ist ohne Vorkenntnisse schwierig (meine Elektrotechnik Kenntnisse habe ich aus einer Grundlagenvorlesung von vor 28 Jahren - also nix Microcontroller oder so). Nehme auch gerne Buchempfehlungen zu dem Thema entgegen! Bist Du dabei, und machst die ersten Schritte, dann mach ich gerne mit! Der Raspi3 ist bereits bestellt und liegt ab Freitag bei mir auf dem Tisch:thumbsup:

Hört sich gut an ... muss man aber nicht in der RT-Firmware dennoch rumprogrammieren, damit die ganzen Kommandos von USB gezogen werden? Sorry, aber die Diskussionen zu VESC5.0 konnte ich nicht in aller Tiefe nachvollziehen

Mir dämmert's. Der Pi fährt also mit und wird nicht nur zu Konfigurationszwecken angesteckt. Kommunikation mit dem Pi -> VESC über die USB Schnittstelle. Kann der Pi über den USB vom VESC auch mit Strom versorgt werden? Wenn der Pi die Steuerkommandos, die er von einem Drahtlosempfänger (Wixel, BLE) bekommt und dann via USB an den VESC weiter leitet, steht das nicht in Widerspruch zu seinem Nicht-RT-Betriebssystem?

Hi Exo, Vedder hat auf meine Bitte eine rpm-Anzeige im Realtime-Data Reiter eingebaut. Wenn ich dich richtig verstehe, müsste die Drehzahl bei Dir ab einem gewissen Duty-Cycle sprunghaft nach oben gehen. Könntest Du bei Gelegenheit mal Screenshots mit Duty und einen mit rpm machen? In welchem Modus betreibst Du dein PPM -Duty/Current/Speed-Control? Ich werde wohl auch mal die ppm-Ansteuerung probieren, aktuell bin ich aber noch mit dem Kama unterwegs, der hat nur Current (wobei ich meine, das ist Speed, da die Geschwindigkeit gleich bleibt und nicht der Strom). Jedenfalls könnte ich dann mal vergleichen.

Ich hab noch nicht ganz geblickt - Meinst Du ein BLE, das über UART am VESC angebunden ist - warum muss dann noch ein PPM Signal generiert werden? Oder hast Du an ein externes BLE-Modul mit Zusatzelektronik nur zur Generierung des PPM-Signals gedacht. - Den Raspberry-Pi über USB am VESC? Der hätte dann ein kleines Display? Den könnte man doch auch über ein (zweites?) BLE/UART-Modul ankoppeln. Jacobbloy hat eine Version des BLDC-Tools geschrieben, die es erlaubt drahtlos mit dem VESC zu kommunizieren ... am USB des Mac ist dann der Nunchuk_rf angekoppelt und der stellt mit dem NRF24 am VESC die Datenbrücke dar. Dazu müsste aber erst mal der Nunchuck_rf funktionieren :mad: Geht er inzwischen bei Dir? - Wenn ich die PPM Aufbereitung mit dem Wixel mache, dann kann an dem UART ja noch ein BLE angeschlossen werden für alles mögliche, feuchte (Handy, Raspberry). Gefühlt meine Vorzugsvariante - was spricht Deiner Ansicht nach dagegen?

Treffer. gleich beim ersten Mal - Ideal mit den Humpe Schwestern. Bravo!:thumbsup:

Inzwischen kann ich (so ziemlich) alle VESC Tools unter OSX selbst compilieren Bei Fragen versuche ich gerne zu helfen.

... ja, das würde mich auch mal interessieren! Dude

Da bleib ich kühl - kein Gefühl. Auch so ein Berliner Spruch/Songtext, der mir dazu einfällt (na, von wem?). Im Ernst, es läuft bei mir eh nicht und ich werd jetzt wohl noch eine Nunchuk_RF Platine zusammenlöten und sehn, ob die sich anders verhält. Das blöde ist und bleibt, dass damit der UART-Port belegt ist und ich auch noch den VESC-Logger ausprobieren möchte. Ist im Prinzip ein BT4/UART Baustein am VESC und der gibt mir die aktuellen Daten vom VESC auf's Handy. Die App konnte ich mir zumindest schon compilieren und auf mein Handy laden ... und der Adafruit BLE UART Friend ist auch unterwegs - hat mich einfach mal interessiert zum ausprobieren. Mir geht allerdings eine weitere Option nicht aus dem Kopf. Nunchuk mit Wixel-Mod-Sender und Empfangswixel zur PPM Vorgabe am VESC. Hat im BLDC-Controller die meisten Optionen mit Speed/Current/Duty Cycle. Damit wäre für das BLE Gedöns der UART wieder frei und zu guter letzt spricht einfach der Name schon allein für das Teil Was meinst Du?

Hier die Zeichnungen für den Umbau des Alien-Power Motors 6374, 130kV mit 3kW. Für den SK3 passt das mit großer Sicherheit nicht, musst wohl noch ein wenig umkonstruieren. Ich hab auch ein paar Änderungen, die ich auf Grund meiner Erfahrung beim ersten Prototyp noch einpflegen werde und die in den Zeichnungen noch nicht berücksichtigt sind. Verwendung daher auf eigene Gefahr und ohne Gewähr meinerseits. Prinzipiell betrifft das die folgende Punkte: Kühkonzept der Glocke Anschlag für den Rotor im Inneren der Glocke zum besseren Rundlauf Madenschrauben auf dem Umfang der Glocke um den Rotor zu fixieren Toleranzanpassungen Die 3D-Druck Parts passen mit Sicherheit nicht für den SK3, das musst Du Dir vermutlich selbst konstruieren. Bei Bedarf schick mir eine PN. Bei der Verwendung erklärst Du/jeder sich automatisch mit den Lizenzbedingungen der Creative Common License "Namensnennung-NichtKommerziell-Weitergabe unter gleichen Bedingungen 4.0 international" http://creativecommons.org/licenses/by-nc-sa/4.0/legalcode einverstanden.

Aktuell gilt für mich "FOC is Hall-Only"

Hallsensoren. Der Unterschied in der Performance beim Start hat mich jetzt doch nicht mehr losgelassen. Retrofit mit dem BamBam Halter ist bei dem Hubmotor allerdings nicht drin. Also hab ich den Hubmotor nochmal auseinander genommen (war natürlic alles Loctite gesichert - alles klar?!) und zwischen die Ankerbleche im 120° Winkel (@Barney: 7*17,14° ) Hallsensoren eingeklebt. Was soll ich sagen, wenn man die erst mal drin hat (2K-Epoxy) ist es schon eine feine Sache. BLDC-Tool genommen zum die Ausrichtung testen - perfekt. Ich war allerdings so scharf auf's Testen, dass ich keine Bilder gemacht habe. Im Prinzip hab ich's aber gemacht wie in dieser Aufnahme. Meine Sensoren sitzen allerdings am oberen Rand und dann eben noch mit ordentlich Epoxy eingegossen. Damit geht auch der FOC-Betrieb recht zuverlässig von der Rolle. Erste Testfahrt hatte keine Unregelmäßigkeiten, lief einfach nur super smooth nachdem ich die PID-Parameter noch ein wenig getunt hatte :thumbsup: FOC ohne Hallsensoren würde ich allerdings nicht riskieren. Anzug und Steigungshandling ist durchaus vergleichbar mit meinem einmotorigen belt-driven Board, an Steigungen muss er allerdings ganz schön zupacken, sicher nicht in seinem Optimum. Wenn erst mal der 2. Hubmotor an der Achse installiert ist bin ich durchaus zufrieden.

Kannst Du das nächste Mal bitte eine Kamera mitlaufen lassen - das klingt echt filmreif :devil:

Ich würde sagen: Experimentalstadium, nicht mehr. Wer an Rückschlägen keinen Spaß hat sollte die Finger weg lassen. Ich schätze es gibt weltweit 3-4 Personen, bei denen der so umgerüstete Nunchuk funktioniert. Funktioniert heißt hier prototypisch mit Unzulänglichkeiten. Was da so auf einen zukommen kann beschreibe ich mal so: Ich hab die HW soweit aufgebaut (Leiterplatine bei OSHpark bestellt, Bauteile bei Mouser und mit zittrigen Fingern zusammengelötet). Der Nunchuk gibt Lebenszeichen von sich und die Batterie wird geladen und stoppt auch wenn der Akku voll ist. Leider kann ich keine Kopplung zwischen Nunchuk und VESC herstellen und weiß auch nicht warum. Mit jacobloy (einer bei dem's funktioniert) hatte ich auch einen eMail Austausch, wir konnten den Fehler leider auch nicht ausfindig machen. Daher musste ich mir erst einmal die komplette Entwicklungsumgebung für meinen Mac installieren und bin jetzt zumindest soweit, dass ich in den Sourcen ändern und über die virtuelle serielle (USB) Schnittstelle während der Laufzeit debuggen kann. Hardwareseitig kann natürlich auch noch ein Fehler vorliegen, d.h. ich muss jetzt irgendwie feststellen, ob ich einen defekten RF-Sender auf der Platine habe ... wie ich das hinbekomme weiß ich nicht. Das 2,4 GHz Antennensignal mit dem Oszi zu messen ist wohl nicht der richtige Weg. Hier hab ich noch keine gute Idee und suche noch nach Ideen. Also, keine Zurückhaltung, Tips sind willkommen! Tja, was hat's gebracht? 1. Mein Ziel, den VESC mit einem modifizierten Nunchuk anzusteuern hab ich (noch) NICHT erreicht. Ich werde aber dran bleiben, da wenn's funktioniert ich auch über den NRF Sender/Empfänger den VESC in situ parametrieren kann, OHNE ein USB-Kabel vom Rechner zum VESC. 2. Ich verwende noch immer den Nunchuk-Kama als Steuerung für mein Hubmotor-Board (@Barney, Du wirst es nicht glauben, ich bin also tatsächlich schon damit rumgefahren und soweit funktioniert alles - Erfahrungsbericht kommt, gehört aber in einen anderen Thread. Hab in jedem Fall ein paar interessante Erkenntnisse gewonnen). 3. Ich kann aus "eigener Kraft" die VESC-Firmware, das BLDC-Tool und die Nunchuk_rf-Firmware in meiner Eclipse Entwicklungsgebung auf Mac OSX cross-compilieren, flashen und auch anschließend debuggen. Damit muss ich nach einem SW-Update nicht mehr warten, bis es jemand auch für mein OS compiliert und zur Verfügung stellt. 4. Ich hab einen ersten Einblick in die für mich noch sehr fremde Welt der STM32-Programmierung bekommen. Das heißt nicht, dass ich in irgendeiner Weise schon produktiv bin, aber wenigstens wird meine Neugier befriedigt und Spaß macht es auch. So, ich glaube damit hat jeder, der sich dafür interessiert, einen Einblick in das Thema bekommen und kann selbst entscheiden, ob er sich darauf einlässt. :mad: