Dude

Ich hab/hatte zwei Zippy parallel im Einsatz ... bei einem musste ich nach einer wenig benutzten Saison schon eine der Tüten ersetzen. Beim anderen ist alles noch einwandfrei - also wie Barney sagt: Glückssache. Dude

Eigentlich hätte ich's ja nicht für möglich gehalten, aber mir ist es tatsächlich gelungen einen der Pins des STM32F4 nicht anzulöten - und genau der war für die Verbindung zum USB verantwortlich! Weiter geht's zu Motordetektion ... hoffe aber, dass es das fürs Erste mal war. Elkick, nochmals danke!!! Dude

Danke für Deine Tips! Ich werde dem Hinweis gleich mal nachgehen. Dude

Hab gesehen, dass bei der firmware noch ein "exit" in der Befehlszeile abgesetzt wird. Damit beendet sich auch das Aufspielen des Bootloaders korrekt. Leider wird der VESC danach immer noch nicht an der USB Schnittstelle am PC erkannt. Suche weiter ...

Ich hab im Makefile für den Bootloader das folgende Kommando aktiviert: $(OPENOCDPATH)/openocd -f board/stm32f4discovery.cfg -c "reset_config trst_only combined" -c "program build/$(PROJECT).elf verify reset" Das gleiche verwende ich auch zum Aufspielen der firmware und da haut's komischerweise hin.

Liebe VESC Gemeinde, ich hab mir zur Abwechslung mal einen VESC selbst zusammengelötet und scheitere gerade beim Upload des Bootloaders via stlink (STM32 discovery board). Die Firmware aufzuspielen funktioniert noch prima, aber beim Bootloader bleibt er ganz am Ende (** Resetting Target **) hängen und ich kann nur noch über Ctrl+C abbrechen. Damit kann ich den VESC auch nicht mit dem BLDC Tool verbinden. Barney, Du hattest doch auch mal Probleme beim Aufspielen der Firmware oder des Bootloaders. Ich kann aber die entsprechende Beiträge nicht finden. Anbei noch der Bildschirmdump openocd -f interface/stlink-v2.cfg -c "set WORKAREASIZE 0x2000" -f target/stm32f4x_stlink.cfg -c "program build/BLDC_4_Bootloader.elf verify reset" Open On-Chip Debugger 0.9.0 (2015-09-02-10:50) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html 0x2000 WARNING: target/stm32f4x_stlink.cfg is deprecated, please switch to target/stm32f4x.cfg Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD adapter speed: 2000 kHz adapter_nsrst_delay: 100 none separate Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : Unable to match requested speed 2000 kHz, using 1800 kHz Info : clock speed 1800 kHz Info : STLINK v2 JTAG v14 API v2 SWIM v0 VID 0x0483 PID 0x3748 Info : using stlink api v2 Info : Target voltage: 2.920567 Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x01000000 pc: 0x0800c000 msp: 0x20000400 ** Programming Started ** auto erase enabled Info : device id = 0x10076413 Info : flash size = 1024kbytes wrote 131072 bytes from file build/BLDC_4_Bootloader.elf in 5.989432s (21.371 KiB/s) ** Programming Finished ** ** Verify Started ** target state: halted target halted due to breakpoint, current mode: Thread xPSR: 0x61000000 pc: 0x2000002e msp: 0x20000400 verified 4256 bytes in 0.209286s (19.859 KiB/s) ** Verified OK ** ** Resetting Target ** ^C Makefile:237: recipe for target 'upload' failed make: *** [upload] Interrupt

Woher habt Ihr die Info - auf dem Vedder Forum ist Funkstille ... Dude

... von Vedder hört man seit mehreren Wochen absolut nix. Bin gespannt ob es wirklich eine neue Version von ihm geben wird!? Dude

Erste Teile sind fertig - jetzt muss noch die Achse abgedreht werden ... View image in gallery View image in gallery View image in gallery View image in gallery View image in gallery

Taucht das Problem eigentlich nur bei ppm-Usern auf oder hast Du auch bei Nunchuks darüber gelesen? Ich fahr ausschließlich mit Nunchuk und da kenn ich das so nicht. Barney, steuerst Du die ppm Schnittstelle mit dem BamBam-Controller? Kennst Du das Verhalten? Dude

Hubmotor V2 mit verbessertem Kühl-und Montagekonzept. Kompakter geht es mit einem 6374'er nicht. Kleinere Motoren, wie sie aktuell für Hubmotoren angeboten werden, haben m.E. zu wenig Drehmoment für die nicht vorhandene Übersetzung. Mit zwei von der Sorte wird's eine runde Sache. Die Teile sind gerade in Arbeit. Diesmal werde ich auch mit Klebeverbindungen arbeiten müssen.

Nein, es gibt einen eigenen Parameter "Deadband" (oberhalb "Minimum Pulsewidth (ms)").

Shit in - shit out, schon klar. Wenn aus den dort zur Verfügung stehenden Modellen das gleiche raus kommt, wäre das zumindest ein Hinweis auf die Richtigkeit Deiner Gleichungen, Programmierung und Einheiten. Ob's mit der Realität übereinstimmt liegt dann immer noch an der Modellgüte. Ich glaub halt immer noch, dass der größte Unterschied sich aus den verschiedenen Steigungen einer realen Ausfahrt ergibt, da man den Mittelwert für den Ritzelrechner nur schätzen kann. Außerdem habe ich den wagen Verdacht, dass auch der Antriebsriemen je nach Spannung schön was wegschluckt. Beim Trampa mit Riemenantrieb ist das auch auf Straße ordentlich spürbar! Dude

Hi Barney, suchst Du eine theoretische Überprüfung Deines Ansatzes/der Gleichungen oder eine Validierung in der Praxis? Für eine Validierung in einer anderen Simulationsumgebung würde sich SimMechanics (Matlab Simulink) anbieten. Oder wenn Du das ganze noch mit einer netten virtuellen Umgebung haben möchtest würde ich auf eine Robotiksimulationsumgebung setzen (ROS, Gazebo)? Aber Vorsicht: erheblicher Einarbeitungsaufwand und Suchtgefahr In einem Schulvortrag wäre das allerdings der Hammer P.S.: Finde ich übrigens Spitze, dass Du Dich den Vortragsinhalten an unseren Schulen annimmst. Viel Erfolg! Ich hatte vor gefühlten Ewigkeiten die Idee, die ganzen Osterhasen und Nikoläuse in unseren Kindergärten durch Bilder der sieben Wetwunder zu tauschen ... :devil:

Das Verhalten in dem Video ist klar der Unterschied zwischen Momentenregelung (z.B. Auto oder Radlader) und Geschwindigkeitsvorgabe (z.B. Gabelstapler). Momentenregelung kannst Du quasi nur sinnvoll mit Last beurteilen. Die wird aber gerne verwendet, da das Verhalten einem am natürlichsten erscheint, da vom Autofahren her bekannt. Da kannst Du auch das Verhalten fast ohne Last (bis auf das Motorschleppmoment) austesten: Kupplung drücken und Gas geben - der Motor erreicht schneller als Du es möchtest Drehzahlen im roten Bereich und ein weiteres Drücken des Gaspedals bringt nicht wirklich mehr Drehzahl. Falls bei dem Test Dein Motor kaputt geht, bin nicht ich, sondern der VESC schuld! Das späte Ansprechen kann zweierlei Ursachen haben. Entweder ist der "Deadband" Bereich in der Mitte zu groß oder das Losbrechmoment. Kannst Du aber ausprobieren, in dem Du im PPM Tab auf "Duty Cycle" (ist so eine Art Geschwindigkeitsregelung) umstellst. Dann hast Du ohne Last einen vernünftigen Zusammenhang zwischen Hebelweg und Drehzahl (und bist auch vom Losbrechmoment weniger abhängig). Sollte der Motorstart dann immer noch zu spät erfolgen kannst Du mit dem Deadband Parameter spielen. Der soll die Toleranzen bei der Rückstellung ausgleichen und gerade so groß sein, das mein Loslassen des Gashebels auch tatsächlich keine Stellgröße an den Motor raus gegeben wird.

Danke für Eure Hinweise (der Wert steht bei mit nach ein paarmal speichern auf 50!)! Ich hab's an der Stelle noch nicht geschrieben, aber meinen Controller hab ich wieder zu Laufen gebracht. Tatsächlich funktionierte der VESC ja von Zeit zu Zeit in beiden Modi. Daher schloß ich ein echt defektes Bauteil mal aus. Nachdem ich alle Lötverbindungen zu den Meßwiderständen etc. ohne Erfolg getestet hatte, konnte es ja nur noch eine unsichtbare Lötstelle sein und davon gibt es beim VESC nur eine. Also mit der Heißluft ordentlich auf den DRV gebraten und schön auf die Platine eingedampft. Seither geht's ...

Hast Du das mit Last (Board auf der Straße, Du auf dem Board) oder ohne Last (Board auf dem Tisch, Räder nach oben) probiert?