Dude

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.

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

Ich kann eurer Diskussion nicht so ganz folgen. Wozu sollte man einen Wixel benutzen, wenn man vorhat sowieso eine Raspberry PI 3 (mit WLAN und BLE) zu benutzen. Ergibt meiner Meinung nach keinen Sinn.

Entweder Wixel (mit selbst programmierten Funktionen was ihr auch immer vorhabt) oder einen Rpi 3 über den man dann direkt über das Handy Wlan/Bluetooth oder über ein in einem Nunchuk verbauten HM-10 Bluetooth oder ESP8266 WLAN Modul (Welches man wie den Wixel übrigens auch selbst programmieren kann und an sich somit auch eigenständig nutzen könnte) zugreifen könnte.

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:

Nur der Mini-USB Anschluß verrät das Innenleben: 2x300mA LiPo + Nunchchuk_mod Platine mit NRF24l01

Jetzt sollte es bloß noch funktionieren, ich hänge noch an der Kopplung zum Empfänger am VESC

NRF24L01+ Empfänger ist inzwischen auch am VESC angeschlossen. Rote LED leuchtet für einige Sekunden nach dem Drücken von C+Z Taste, geht dann aber wieder aus. Wenn ich's richtig in Erinnerung habe bedeutet dies, dass die Funkverbindung nicht aufgebaut werden kann.

Ich weiß allerdings nicht, was ich in den entsprechenden Feldern im BLDC-Tool unter NRF konfigurieren muss (Channel = ?, Adress = 1111b = 15d aber 3 Eingabefelder im Tool mit Range 0-255). Möglicherweise ist auch die general_conf.h noch zu konfigurieren.

Barney, wenn Du soweit bist melde Dich, bin gespannt wie weit Du kommst. Hoffe es klappt bei Dir, dann hab ich einen Anhaltspunkt mehr.

Empfangseinheit ist verdrahtet und der entsprechende Kondensator C3 am VESC ausgelötet. Bald kann ein erster Funktionstest gemacht werden ...

Barney, was sagt Dein Bauchgefühl: kann ich an die 5V des Servopins einen RaspberryPi oder BananaPi anschließen (möchte ich zur Aufzeichnung von Bild und VESC-Daten mit dem BLDC-Logger während der Fahrt nutzen)?