Dude

Danke für Deine ausführliche Antwort. Ich bin mir mittlerweile sicher, dass es auch keine einfache gibt. Momentan versuch ich auch so alles mögliche ran zu koppeln, das klappt aber eher weniger als mehr. Daher konvergieren die möglichen Antworten auf meine Fragen einfach nicht mit der technischen Realisierung. Aber das wird schon ... Ach ja, den PPM möchte ich sicher nicht verwenden, da ich wie schon gesagt von der Möglichkeit die aktuelle Geschwindigkeit zu fixieren absolut begeistert bin. Musst Du unbedingt probieren (das war der Hinweis den Nunchuk ans laufen zu bringen ) Es gibt allerdings eine Option, bei verwendetem UART an die Daten ran zu kommen (außer CAN): RPi an den USB-Port (derzeit halt mit USB-Kabel) anklemmen. Dann hätte man den UART um über BLE, Wixel oder weiß der Geier was einen Nunchuk anzuschließen. An den Mini-USB hängt man den RPi mit BLDC-Tool und BLDC-Logger. Der RPi ist mit einer Raspberry CAM ausgestattet und einem 5 oder 7 Zoll Touch -Display. Wenn der angestöpselt ist, kannst Du den VESC umprogrammieren mit BLDC-Tool oder mit dem BLDC-Logger die Fahrt incl. Video (wenn gewünscht) aufzeichnen. Wenn ich das richtig verstanden habe, wird der USB-Port auch nur als serielle Verbindung eingesetzt und damit könnte man mit 2 Wixel (USB->RF<->RF->USB) auch den noch drahtlos anbinden. Was meinst Du? Wären damit nicht alle Ansprüche erfüllt?

So was halt: http://bleduino.cc oder so https://hackerspaceshop.com/collections/teensy/products/teensy-3-1-bluetooth-serial-module oder so https://hackerspaceshop.com/collections/teensy/products/teensy-ble

Nee, kann ich leider noch nicht. Ich hadere noch mit BLE. Hab mir einen Adafruit BLE UART friend zugelegt, und der wird vom Mac noch nicht erkannt. Bin mir aber sicher, dass er funktioniert, da ich ihn unter Ubuntu koppeln kann. Bin mir auch nicht sicher, wie ich da ran kommen soll ... Sniffer am UART-serial während der Fahrt (BLDC-Logger) oder beim Konfigurieren und bei aktivierter Realtimeanzeige? Am Rpi sind meines Wissens die UART-Pins bereits festgelegt auf Pin 8: TxD, Pin 10: RxD. Ich bin auch noch am überlegen, wie eine Lösung aussehen würde, bei der man den Pi nicht dauerhaft auf dem Board mitführen muss (Rucksack oder so oder nur wenn mal aufzeichnen möchte etc.) und trotzdem die ganzen Features auch noch dabei hätte. Was denkst Du über folgende Lösung: - BLE am UART des VESC - Nunchuk mit Teensy+UART/BLE - RPi3 mit eingebautem BLE und zusätzlich noch ein UART/BLE Dann könnte man entweder nur mit dem Nunchuk fahren oder mit Nunchuk+RPi, wobei dann die Nunchuk Befehle einfach durchgeschleift werden. Entspricht wenn ich das richtig verstanden habe Deinem Vorschlag, nur dass der RPi über UART/BT -> BT/UART an den VESC gebunden wird. Alternativ könnte man auch einen Wixel an den UART des VESC anbringen und einen in den Nunchuk sowie einen an den RPi UART. Wenn ich mich richtig erinnere (zweifel, zweifel), kann der Wixel ja RF-Kanäle für die Funkverbindung auswählen und dann würden beide parallel mit dem Wixel auf dem VESC sprechen können. Das ist aber nur neblig in meiner Erinnerung von vor einem Jahr und kann auch kompletter Mist sein und man muss die jeweilige Verbindung immer ab und neu aufbauen ... Die arme Leute Lösung wäre VESC/UART + Wixel, RF-verbunden mit Nunchuk + Wixel. Platzbedarf im Nunchuk natürlich sensationell wenig. Btw. gibt es eigentlich einen Wixel mit BLE - dann wäre das natürlich genial für den Einbau im Chuk.

Python war für mich mehr ein Synonym für eine einfachere Sprache als C++ ... hast Du eine konkrete Lösung in einer anderen Sprache? Tkl-Tk oder bash oder - egal? Ich werde mich mal in meiner Abteilung schlau machen, da hat es ein paar Robotik-Nerds, die können das evtl. auch.

Ich würde mal sagen, ja. Die kann ich aber wohl nur in C++ verwenden oder kann man auch C-Header Files in Python einbinden und dann die Befehle mit geeignetem Argument an die UART-Schnittstelle absetzen? Da kenne ich mich halt gar nicht aus.

... und wenn mir Doofi jetzt noch jemand sagt, wie der komplette Befehlssatz (kommentiert) für die Steuerung des VESC über UART lautet und wie ich einen Befehl wie "COMM_SET_CHUCK_DATA" von einem Python-Script auf dem RPi über UART auf den VESC abfeuere bin ich glücklich Dann klemm ich an den RPi-UART einen Wixel (UART->Radio), an den VESC auch einen (Radio->UART) und schmeiß den RPi in meine Hosentasche oder bäp (schwäbisch für klebe) den mit einer Cam auf meinen Helm und hebe ab :arf:

Autsch - das sehe ich mir gleich mal heute Abend an.

Exakt so: an und nach wenigen Sekunden wieder aus.

Hey Duffman, na das ist mal ein Anhaltspunkt, danke! Ich verwende VESC4.7 welchen hast Du? LED's verhalten sich genau wie bei Dir. FW2.16 und das Prozedere hab ich auch gleich gemacht. Akku auch dran. Ich schau mir jetzt noch mal die Löterei an ... falls das nichts bringt, dürfte ich Dir meinen Nunchuk-Controller und meinen NRF-Empfänger schicken und Du schließt meine HW mal an Deinen VESC an, um zu sehen ob es am Sender oder am Empfänger liegt? Porto übernehme natürlich ich. Dude

Schon bestellt

... lässt sich über die Pfadeinstellungen im .pro-File lösen. Sind nur 2-3 Zeilen, ich kann Dir meines bei Bedarf schicken, vermutlich liegt CV bei Dir an der selben Stelle im Mac-Verzeichnisbaum. Ach ja, und nicht die neueste Version nehmen.

Wenn es sich unter Last anders verhält würde ich mal auf die PID-Reglerparameter unter "Advanced/PID Speed Cpntrol" tippen. Hast Du die schon mal verändert, damals? Leider gibt es da eine allgemeingültigen Werte, da sich die je nach Strecke (Motor + Getriebe) ändern ...

https://github.com/jacobbloy/bldc-logger

Nee, der Nunchuk kommt mir nicht mehr weg :thumbsup: Die App kannte ich noch nicht, weißt Du wo die Sourcen zu finden sind, ich bin noch nicht drüber gestolpert?

Eclipse hab ich mir eigentlich nur für den Nunchuk_NRF installiert, damit ist es einfacher auf die ganzen Header Files zuzugreifen und ich hab ja die Hoffnung irgendwann zu verstehen, was da so vorgeht. Hier hab ich mir einfach 2-3 Tutorials durchgelesen, wie man Eclipse fürs STM32 cross-compilieren und debuggen aufsetzt und ein best-of für mich daraus gezogen. Braucht aber Zeit ... BLDC-Tools hab ich ohne Eclipse gemacht. Prinzipiell musst Du auf dem Mac dieselben Tools wie Vedder unter Ubuntu installieren. Homebrew hilft hier. Firmware: wenn die notwendigen Pakete installiert sind sollte das kein Problem sein. BLDC-Tool: benötigt Qt, dann sollte es klappen BLDC-Logger: damit hatte ich die größten Probleme. Zunächst musste Benjamin die Lauffähigkeit für FW2.16 herstellen, damit konnte ich es zunächst unter Ubuntu compilieren. Für den Mac braucht es etwas mehr, da hier die Linux/serial.h mit Lib benötigt wird. Die gibt es auf dem Mac nicht. Jacobbloy hat von einem Sergey den Mac-Port bekommen, der hat die serial-Lib aus Qt eingepflegt und damit für Windows und Mac das Compilieren ermöglicht. Auch musste ich das BLDC-Logger.pro file anpassen, damit er die CV-Header und Libs finden konnte (kann ich zur Verfügung stellen). Dann lief's.

Geht das, an ein einziges BT-Modul am VESC zwei BT-Module (Nunchuk + Handy) gleichzeitig zu koppeln, wenn einer nur sendet (Nunchuk) und der andere nur liest (Handy)?

Was ich so alles in meiner Jackentasche hab sag ich lieber nicht Ach ja, was mir noch einfiel und m.E. der entscheidende Nachteil bei einer Ansteuerung über PPM ist: die Geschwindigkeit-Halten Funktion, welche Benjamin bei Verwendung eines Nunchuk über die UART-Schnittstelle programmiert hat. Das ist schlicht geil und hat neben dem angenehmen und geräuschlosen Fahrverhalten in FOC-Current-Control dazu geführt, dass meine Jungs mittlerweile sich weigern mit dem alten Longboard mit Teensy-Steuerung zu fahren :mad: Ich werde jetzt wohl das Board auch auf VESC umstellen müssen ... Bei einer Steuerung über RPi3 und USB sollte die Funktion unbedingt realisiert bzw. erhalten bleiben. Wenn ich die Ansteuerung mit dem Wixel und PPM mache ist das nur mit Einschränkung möglich, indem man den zuletzt im Tempomat-Modus verwendeten Duty-Cycle speichert und bei erneutem Drücken der C-Tast wieder abruft - so eine Art Memory-Funktion. Was nicht geht ist allerdings die aktuelle Geschwindigkeit durch Drücken der C-Taste zu halten und genau das ist einfach geil beim Longboarden.

Nachdem mein Nunchuk_NRF noch nicht läuft brauchte ich ein Erfolgserlebnis und hab mal was anderes ausprobiert. VESC-Logging über BLE und meinem iPhone. Alles wesentliche dazu ist hier zu finden und das Best ist, es funktioniert: http://vedder.se/forums/viewtopic.php?f=8&t=14. Am VESC hab ich ein Adafruit BLE/UART Modul angeschlossen und die App für mein iPhone mittels Xcode auf meinem Mac compiliert und auf das iPhone aufgespielt. Screenshots vom Handy: Klappt prima. Entscheidender Nachteil: der Comm-Port ist belegt und ich kann den Nunchuk-Kama nicht mehr anschließen. Steuerung geht dann nur über PPM-Port und damit entfällt die Geschwindigkeit-Halten Funktion des Kama

Hallo Exo, hat mir jetzt doch keine Ruhe gelassen und ich hab mal meine GT2B Funke an den PPM Eingang am VESC (4.7, FW2.16) angeschlossen und mal ohne Last in der Werkstatt getestet. Speed Control zeigt einen linearen Zusammenhang zwischen Auslenkung an der Funke und RPM. Im Current-Control Modus beschleunigt der Motor ohne Last schon bei der kleinsten Auslenkung auf Max-RPM, was aber normal ist. Um was zu sehen hab ich dann den Duty-Cycle Verlauf und die ERPM geplottet: Sieht eigentlich einwandfrei aus, ERPM folgt wunderbar dem Duty Cycle. Wie es unter Last ist kann man daraus natürlich nicht sagen. Da fahre ich allerdings mit dem Nunchuk und dann normalerweise nicht als Direkt-Drive (Geschwindigkeit/Current proportional Auslenkung) sondern im Tempomat-Mode (gedrückte C-Taste am Nunchuk) - für mich der entscheidende Vorteil. Das genialste ist dass der VESC immer die Geschwindigkeit behält, sobald die C-Tast gedrückt wird. Push Kick aus dem Stand heraus, C-Taste drücken und Du fährst mit der aktuellen Geschwindigkeit, wenn den Berg runter geht genauso. Sobald die gewünschte Geschwindigkeit erreicht wird Taste drücken und das Tempo ist fixiert.