hexakopter

Kein Problem. Ist Benjamins design, welches auch hier besprochen wird: http://www.elektro-skateboard.de/forum/eigenbauten-95/nunchuk-rf-5092.php Am besten fragst du dort, wenn du etwas wissen möchtest. @Tarzan Mal sehen ob es mit größerem Motor-Ritzel besser wird. Erst mal gucken ob ich das andere Teil runter bekomme. Soll wohl verklebt worden sein. Der letzte vorsichtige Versuch das Ritzel runterzubekommen, um mal den Motor von dem Mount abzunehmen (Ritzel ist dafür im Weg) war gescheitert. Motor habe ich wirklich nicht unter der Ferse. Hätte ich ja schon mal einen Ansatzpunkt. Den Motor vorne müsste ich auch einfach mal aus Spaß testen. Verstehe nicht so ganz, warum das Diagonal Setup lenken sollte. Bei einem Motor ist mir das klar, aber der zweite Motor vorne ist doch auf der anderen Seite und sollte versuchen gleich stark in die andere Richtung zu lenken, was in der Summe dann zu einem aufheben führt. Also schön grade aus. Zwei Motoren auf der Hinterachse stelle ich mir auch schön vor, aber das geht bei meinem 6374 ja nur mit einem vor und einem hinter der Achse. Hätte noch einen zweiten SK3 hier (und ein zweiter VESC ist auch gelötet, aber noch nicht getestet), aber der ist leider mit 149kv. Das würde dann ja mit der Can Verbindung untereinander vermutlich nicht klappen, da sie unterschiedlich schnell laufen und das Gearing ja nicht einberechnet wird. Da könnte ich es mir fast noch einfacher vorstellen einfach mal mit einem Motor beide Rollen zu betreiben. Ich könnte mir vorstellen, dass die unterschiedliche Geschwindigkeit der Rollen in Kurven garnicht so groß ist. Und die paar Grad die es sich unterscheidet muss dann halt eine Rolle etwas durchdrehen. Hat das schon einer von euch getestet? Differential gibt es ja leider nichts passendes. Habe zumindest nichts gefunden. Und ja du konntest helfen. Danke. Meinungen von anderen nehme ich aber trotzdem noch gerne entgegen.

Habe ja ganz vergessen hier zu sagen, dass mein Nunchuk nach dem Wechsel des NRF auch läuft. Hier ein Bildchen:

Vielen Dank für die Antwort. Habe jetzt mal verschiedene 15mm Motor-ritzel bestellt. An der Rolle bleibt erst mal nur das 9mm Alu-ritzel dran. Sollte ja keine Probleme machen oder? Teste dann auch mal ein in ABS 3D gedrucktes 15mm Ritzel. Riemen sollte ich dann hoffentlich auch erst einmal genug in 9mm und 15mm haben. Motor-Ritzel war tatsächlich nicht so gut abgestimmt, weil ich von dem Motor außen liegend auf innen liegend gewechselt habe. (Ich hoffe du verstehst was ich meine) Da saß die Halterung aber nicht exakt 90 Grad zur Achse. Werde ich so gut es geht anpassen das nächste mal. Bekomme hoffentlich bald 12/14/15/16 Zähne in 15mm breite geliefert. Dann kann ich da etwas variieren. Danke auch zu den Tipps mit der Achsen-Einstellung. Was ich aber immernoch nicht verstehe ist das Durchdrehen der Rolle. Gefahren bin ich auf Asphalt. Ist es normal, dass 83a Orangatang Rollen durchdrehen und den Grip verlieren? Sollte ich vielleicht Geld zusammenkratzen und mir 90mm Flywheels zulegen? In einer Härte von 75a oder 78a? Oder kann man dem Durchdrehen nur mit einem Dual Setup entgegenwirken?

Hallo Leute, nach langer Zeit habe ich es die Tage endlich geschafft mein Board in vorgesehener Konfiguration zu fahren. (12s statt 6s) Erst einmal Angaben zu dem Board: SK3 6374 192kv Motor 12s 5200mAh (multistar 10c) Akkus Orangatang Kegel Rollen (lila 80mm 83A) Motor-ritzel 12 Zähne Rollen-ritzel 36 Zähne 9mm HTD5 Riemen Selbstgelöteter VESC und selbstgelöteter Nunchuk mit NRF Modul Dabei ist es immer wieder vorgekommen, dass etwas rattert (also durchdreht). Hatte erst nur die Rolle im Verdacht, dann aber vielleicht auch den Riemenantrieb. Also mal etwas stärker gespannt den Riemen. Das ging aber leider nur für ein paar Meter gut, danach hat der Riemen sich verabschiedet und alle Zähne wurden "abgeschreddert". Habe dabei im Verdacht, dass es größtenteils an der vielleicht zu starken Spannung gelegen hat. Beim schnellen Anfahren und starken Bremsen blieb aber auch auf den paar Metern das Problem, dass da etwas nicht ganz in Ordnung ist und durchdreht. Dürfte also die Rolle sein, die bei der starken Belastung den Grip verliert. Jetzt meine Frage an euch. Ist das normal? Sind die Rollen wohlmöglich zu hart für eine 70kg Person und mit weicheren sollte ich auch beim vollen Durchzug kein durchdrehen mehr haben? Sollte man vielleicht auch lieber auf 15mm Riemen und Ritzel wechseln, bevor ich mir den nächsten 9mm Riemen bestelle und schredder? Wäre gut zu wissen, ob ich irgendetwas falsch mache. z.B. ist mir auch nicht ganz klar, wie hart man die Achsen anzieht. Damit man auch bei 30kmh nicht ins wackeln kommt (speed wobbel) sind sie so hart, dass der Motor in einer Kurve immer den Kontakt zum Boden verliert. Das ist dann vermutlich ja zu hart eingestellt oder? Bei weicher Einstellung bekomme ich aber Angst bei höheren Geschwindigkeiten dem Speedwobbel zum Opfer zu fallen. Ist das vielleicht nur Übungs-/Gewöhnungssache? Bin über jegliche Tipps dankbar. Grüße

Hallo zusammen, war ich wohl nicht der einzige, der es eine Sauerei findet einen bata tester zu spielen ohne es zu wissen. Ich spiele zwar gerne Beta Tester und hatte Jacob auch angeschrieben seine App testen zu können. Aber ich bin nur gerne Beta Tester, wenn ich es auch weiß und es den Leuten nicht einfach so aufgedrückt wird ohne an Konsequenzen zu denken. Zu der App hatte er erst gesagt ich darf nicht testen, obwohl er ein paar Wochen vorher gesagt hatte Tester sind gerne gesehen und sollten ihn privat anschreiben. Nach längerem schon fast "betteln" meinte er dann in ca einer Woche fügt er mich zu dem Beta Programm hinzu auch wenn man es normal KAUFEN müsste nur um die App probieren zu können. (das war etwa vor einem Monat) Seit dem nichts mehr gehört gehabt. Also einfach mal die App vom neusten Stand selber auf ein iPhone gespielt. Kein Wunder, dass er die App noch nicht verteilt, wenn nicht einmal schreiben funktioniert. Ist ja schön und gut, dass man Werte (auch wenn teilweise völliger Blödsinn gelesen wird) lesen kann, aber ohne Abänderung bringt einem das ja wahrlich nichts. Das gleiche Problem über die BLE Verbindung mit dem Mac. Kein schreiben möglich. Ziemlich nutzlos also. Hat noch einer die Erfahrung machen können? Immerhin ist es jetzt ja schon ein Fortschritt, wenn er den Müll von seiner Seite entfernt. Keine Ahnung ob ich der einzige war, bei dem der Motor einfach mal losgelaufen ist wie er wollte (kann am bluetooth gelegen haben), aber das kann auch schnell böse enden. Euer reboot Problem mit den original sourcen von Benjamin kann ich jedoch nicht nachvollziehen. Bei euch stürzt das Programm ab, wenn ihr auf den reboot button drückt? Habe sowohl mit V2.17 als auch V2.18 auf dem VESC keine Probleme. VESC blinkt nach dem reboot und nach einem erneuten klick auf connect ist die Verbindung wieder hergestellt. Hab mir die Source auch mal angesehne und keinen Punkt auf die schnelle ausmachen können, warum es plötzlich zu einem Problem kommen könnte, da nichts direkt am reboot geändert wurde, wenn ich das richtig sehe.

Vielen Dank für diesen ausführlichen Bericht. Habe selber bei meinem VESC den Fehler gefunden und behoben. Leider hab ich dabei keine schönen Bilder gemacht und viel Zeit ist grade leider auch nicht um alles ausführlich aufzuschreiben. Also kurz und knackig. Die letzten Tage war ja sehr gutes Wetter Deutschlandweit und da musste endlich mal der selbstgelötete VESC draußen unter dem Board dran glauben und nicht nur gemütlich auf der Testbank laufen. Und wie sollte es anders sein, im "echten" Leben hat das Teil angefangen rumzuzicken. Bei starken Beschleunigungen und ab und zu auch einfach so setzte der Regler aus und erst nach mehreren Sekunden lief das Board wieder. Also das Board mal mit dem BLDC-Tool verbunden und im terminal "faults" eingegeben um die Fehler auszulesen, die seit dem Starten des Boards aufgezeichnet wurden. Und siehe da ein Haufen Over Current Fehler die alle im Grunde so aussahen: Fault : FAULT_CODE_ABS_OVER_CURRENT Current : 27.6 Current filtered : -106.2 Voltage : 24.15 Duty : 0.80 RPM : 18046.9 Tacho : 13752 Cycles running : 18608 TIM duty : 4123 TIM val samp : 2056 TIM current samp : 4623 TIM top : 5134 Comm step : 1 Temperature : 19.65 Wenn ein Fehler erkannt wird gibt die rote LED auch ein Blinkmuster ab und so war eindeutig klar, dass die Aussetzer mit diesem Fehler zu tun hatten. Also habe ich versucht ein genaueres Muster zu finden, wann die Fehler auftreten. Durch Zufall bin ich dann darauf gestoßen, dass auch "FAULT_CODE_ABS_OVER_CURRENT" erkannt werden, wenn ich die Platine leicht verbiege. Kein gutes Zeichen. Das bedeutet ja, dass entweder die Platine an sich irgendwo ein Mangel aufweist oder irgend eine Lötstelle nicht richtig sitzt. Also noch mal die DRV pinne alle nachgelötet, was aber zu keiner Verbesserung geführt hat. Dann mal mit dem Oszilloskop geschaut, ob bei der "Fault" Verbindung zwischen DRV8302 und STM32 überhaupt etwas ausgespuckt wird. Sowohl direkt am DRV fault pin, als auch am STM32 Eingang der "Fault-Leitung" ließ sich jedoch keine Veränderung feststellen, wenn ein Fehler gelesen wurde. Im Nachhinein auch logisch, weil sonst ein DRV fault gelesen worden wäre. Also weiter im Sourcecode und Schaltplan gesucht wodurch der Fehler überhaupt ausgelöst wird. Und siehe da, nachdem drei weitere Bahnen auf dem Oszi betrachtet wurden war der Fehler irgendwo im Bereich der Shunt Messung gefunden. Ein paar Cs wurden entfernt und wieder verlötet und letztendlich konnte der Fehler direkt auf die Shunts eingeschränkt werden. Also mit dem Lötkolben die Shunts etwas nachgelötet und siehe da er lief ohne irgendwelche Fehler. So muss das. Vielleicht doch etwas viel Text geworden, aber vielleicht hilft die Beschreibung ja jemandem der einen ähnlichen Fehler bei sich findet.

Vielen Dank für diesen ausführlichen Bericht. Habe selber bei meinem VESC den Fehler gefunden und behoben. Leider hab ich dabei keine schönen Bilder gemacht und viel Zeit ist grade leider auch nicht um alles ausführlich aufzuschreiben. Also kurz und knackig. Die letzten Tage war ja sehr gutes Wetter Deutschlandweit und da musste endlich mal der selbstgelötete VESC draußen unter dem Board dran glauben und nicht nur gemütlich auf der Testbank laufen. Und wie sollte es anders sein, im "echten" Leben hat das Teil angefangen rumzuzicken. Bei starken Beschleunigungen und ab und zu auch einfach so setzte der Regler aus und erst nach mehreren Sekunden lief das Board wieder. Also das Board mal mit dem BLDC-Tool verbunden und im terminal "faults" eingegeben um die Fehler auszulesen, die seit dem Starten des Boards aufgezeichnet wurden. Und siehe da ein Haufen Over Current Fehler die alle im Grunde so aussahen: Fault : FAULT_CODE_ABS_OVER_CURRENT Current : 27.6 Current filtered : -106.2 Voltage : 24.15 Duty : 0.80 RPM : 18046.9 Tacho : 13752 Cycles running : 18608 TIM duty : 4123 TIM val samp : 2056 TIM current samp : 4623 TIM top : 5134 Comm step : 1 Temperature : 19.65 Wenn ein Fehler erkannt wird gibt die rote LED auch ein Blinkmuster ab und so war eindeutig klar, dass die Aussetzer mit diesem Fehler zu tun hatten. Also habe ich versucht ein genaueres Muster zu finden, wann die Fehler auftreten. Durch Zufall bin ich dann darauf gestoßen, dass auch "FAULT_CODE_ABS_OVER_CURRENT" erkannt werden, wenn ich die Platine leicht verbiege. Kein gutes Zeichen. Das bedeutet ja, dass entweder die Platine an sich irgendwo ein Mangel aufweist oder irgend eine Lötstelle nicht richtig sitzt. Also noch mal die DRV pinne alle nachgelötet, was aber zu keiner Verbesserung geführt hat. Dann mal mit dem Oszilloskop geschaut, ob bei der "Fault" Verbindung zwischen DRV8302 und STM32 überhaupt etwas ausgespuckt wird. Sowohl direkt am DRV fault pin, als auch am STM32 Eingang der "Fault-Leitung" ließ sich jedoch keine Veränderung feststellen, wenn ein Fehler gelesen wurde. Im Nachhinein auch logisch, weil sonst ein DRV fault gelesen worden wäre. Also weiter im Sourcecode und Schaltplan gesucht wodurch der Fehler überhaupt ausgelöst wird. Und siehe da, nachdem drei weitere Bahnen auf dem Oszi betrachtet wurden war der Fehler irgendwo im Bereich der Shunt Messung gefunden. Ein paar Cs wurden entfernt und wieder verlötet und letztendlich konnte der Fehler direkt auf die Shunts eingeschränkt werden. Also mit dem Lötkolben die Shunts etwas nachgelötet und siehe da er lief ohne irgendwelche Fehler. So muss das. Vielleicht doch etwas viel Text geworden, aber vielleicht hilft die Beschreibung ja jemandem der einen ähnlichen Fehler bei sich findet. Edit.: Der Text sollte eigentlich unter einem anderen Thread landen. Sorry.... Hier passt er aber ja auch etwas. Kopiere ihn trotzdem mal dahin, wo er eigentlich hin sollte.

Man sollte auch beachten, dass der GPS Empfang bei einem Handy in der Hosentasche nicht grade der beste ist. Wenn das Handy kein GPS besitzt braucht man sich da aber keinerlei Sorgen machen...

Vielen Dank. Werde dich mal anschreiben. Hoffe ich habe es grade auch tatsächlich geschafft mein Over Current Fault zu fixen. Das wäre dann ja perfekt.

Ok, danke für die Antwort. Bin jetzt denke ich weiter gekommen, warum meine Platine nicht funktioniert. Dürfte an den NRF24l01 Modulen liegen. Hab wie gesagt die hier: http://www.••••.de/itm/10-STK-SMD-1-27-Pitch-NRF24L01-Wireless-Data-Transmission-Module-Mini-NRF24L01-/181566959487?hash=item2a463bef7f:g:~gUAAOSw~uhUmpBK Die sollen jedoch nicht kompatibel zu den "echten" NRF chips sein. Ist wohl stattdessen ein SE8R01 drauf verbaut, der leider nicht kompatibel ist. Richtig ärgerlich, warum die Chinesen das Teil als NRF24 verkaufen. Hätte zufällig jemand von euch zwei NRF24l01 SMD Platinen über und würde sie verkaufen? Eine würde auch schon reichen. Die Version mit 2,54mm Raster lässt sich ja auch in Deutschland beziehen und könnte dann als Empfänger benutzt werden.

Läuft dein Nunchuk jetzt eigentlich Dude? Bin nach langer Zeit gestern endlich dazu gekommen mir auch einen Nunchuk aufzubauen. Flashen war auch kein Problem. Rote LED leuchtet kurz, wenn man Z und C gleichzeitig drückt. Verbinden tut sich aber nichts. Habe jetzt ja meine günstigen NRF24 Module im verdacht. Bei den Adress Widerständen auf der PCB bedeutet R7 die 1 oder R10 die 1? Ist irgendwie nirgends dokumentiert, wie die Reihenfolge auf dem Nunchuk festgelegt ist. PS.: Vielleicht hat ja auch jemand von euch eine Idee, warum mein VESC "FAULT_CODE_ABS_OVER_CURRENT" ausspuckt. Werde gegebenenfalls hier einen Thread dazu eröffnen, aber vielleicht löst sich das problem ja im vedder forum.

Naja, ich sehe jetzt nicht das riesige Problem, warum man nicht von einem anderen Port noch einen Pin klauen könnte. Wie du schon sagst bräuchte man trotzdem noch 3,3V und die bekommt man ja auch einfacher von einem andern Port als extra einen zusätzlichen Spannungsregler zu verbauen. Woher nimmst du eigentlich die ganzen Informationen, dass Benjamin zum Beispiel erst auch überlegt hat die Sensordistanz auszuwerten? Ich hatte gedacht, dass der Pin vielleicht intern schon auf ein level gezogen werden würde. Im Datenblatt habe ich jetzt aber auch gesehen: Floating state of a digital input is not allowed.

Vielen Dank. +- 0.15° klingt ja schon mal besser. Hatte es jetzt schon selber in der V2.17 firmware gefunden: Schon blöd wenn man vorher die V2.16 durchsucht aber irgendwie nichts richtig findet... Verstehe aber irgendwie noch nicht richtig, warum du MOSI auf high setzt. Sollte es nicht auch reichen den pin einfach nicht zu verbinden, wenn man nur von dem Encoder lesen möchte. Eigentlich schade, dass nichts an den AS geschickt werden kann. So weit ich weiß kann der nämlich liefern, ob der Abstand zu dem Magneten zu weit weg, zu nah dran oder genau richtig ist.

Sehr nett. Die Genauigkeit sollte sich denke ich mit einer präzisen Ausrichtung noch verbessern lassen. Hast du dir schon Gedanken über eine vernünftige Halterung gemacht oder schon eine aufgebaut? Meine Idee wäre bis jetzt eine aufgeschnittene Getränkedose zu verwenden, wo an dem "Boden" der Magnet Encoder befestigt ist. Damit schützt man den Motor gleich mit. (und vernichtet leider die gute Luftzufuhr) Den Magneten selber über ein 3D gedruckten Halter (der die vier Befestigungslöcher der SK3 Motoren nutzt) befestigen oder direkt den mitgelieferten Propmount absägen und auf Magnet Größe aufbohren. Das ganze wird über den SPI Port angeschlossen richtig? Ist ja bisschen blöd, dass dann kein UART mehr zur Verfügung steht. Die Möglichkeit SPI auf die Hall Pins (Filter vorher entfernen) zu mappen besteht nicht? Wäre ja schon schön, später auch noch einen Nunchuk mit anzuschließen. Sonst bringt einem die genauere Rotor position für die Applikation eines e-boards ja nicht viel.

Naja, ich weiß immer noch nicht ganz wie ich es das nächste mal machen soll. Direkt am Anfang die FETs zu löten ist ja auch schlecht, weil man dann nicht mehr an die Widerstände zwischen den FETs kommt. Ganz am Schluss ist aber wie gesagt auch irgendwie schlecht, weil dann das ein oder andere R und C durch die Heißluft verrutschen kann, da es ein ziemliches gebrate ist. Was habt ihr denn als besten Weg herausgefunden? Mein VESC läuft übrigens. Sowohl BLDC als auch FOC im Leerlauf ohne Probleme. :peace: Für testen unter Last ist mein Board leider noch nicht weit genug aufgebaut.

Hätte übrigens auch noch ein dual VESC Set abzugeben mit allen Bauteilen und zwei V4.11 Platinen. Bei Interesse könnt ihr mir ja eine PN schicken.

Wie ist der Versuch eigentlich gelaufen? Habe jetzt auch einen VESC fertig gelötet, aber noch nicht mehr getestet als ihn zu flashen. Das dauert ja wirklich eine zweistellige Anzahl an Stunden, wenn man alles schön von Hand lötet. Die FETs am Schluss waren eine Qual und mussten sehr viel Hitze aushalten. Hoffe sie hat es trotzdem nicht zerstört. Wenn es dann laufen sollte war es aber definitiv eine gute Erfahrung und definitiv die Zeit wert. Habe übrigens noch ein dual VESC Set mit allen Bauteilen und zwei V4.11 Platinen hier.

Das mit den "defekten" NRFs klingt ja sehr interessant. Klingt irgendwie höhst merkwürdig warum es an der einen Platine klappen soll und an der anderen nicht. Aber ist ja gut, dass es jetzt läuft. :thumbsup: Verfolge eure Rpi Entwicklung mal gespannt weiter. Wenn ich es richtig in Erinnerung habe ist meine ich nur der 7Zoll Touchscreen eine "offizielle RPi Erweiterung". Von einem offiziellen 5 Zoll habe ich noch nichts gehört. Aber wenn alles klappt ist das ja auch egal.

Nein, ist leider nichts von übrig geblieben.

Ist denke ich recht einfach zusammenzufassen was eXo meint. - Du machst sehr viele (unnütze) neue Threads auf, statt mal die Suche zu benutzen und in schon bestehenden Threads zu fragen - Deine Shift-Taste scheint wohl zu klemmen - Du wirkst durch deine dreisten Antworten sehr unsympathisch - Du änderst vermutlich nachträglich deinen Eingangspost um "Recht haben zu wollen", indem du Links ergänzt Kombiniert man diese Punkte mit deiner Rechtschreibung, werden vermutlich viele denken du hättest das zehnte Lebensjahr noch nicht überschritten. Nimm es mir nicht persönlich, aber du hast ja nachgefragt.

Vielen Dank. Jetzt fällt mir aber auch wieder ein, dass ich ja auch noch ein open cv Problem hatte. Werde ich mich aber wie gesagt dann drum kümmern wenn ich es überhaupt brauche.

Eigentlich müsstest du doch bei deiner anderen App darüber gestolpert sein. :confused5: Ist von dem gleichen Entwickler genau so unter github zu finden: https://github.com/gpxlBen Kann sein du musst für Software Version 2.16 etwas abändern. Ist aber nur eine Vermutung von mir.

Genau dieses best-of meine ich. Es gibt meiner Meinung nach sehr viele verschiedene Sachen. An sich kann ich fürs erste die files ja auch mit irgendeinem "Editor" bearbeiten und dann ganz normal übers terminal "maken". Ja richtig. Fürs normale BLDC-Tool braucht man eigentlich nur QT. Das hab ich vor Monaten schon probiert und funktionierte direkt. Bei dem Logger habe ich es mir dann auch so einfach vorgestellt, aber leider wie gesagt dieses "Serial" Problem bekommen. Findet man zu der Geschichte von Jacob und Sergey irgendetwas? Genau das sollte bei mir dann ja auch zur Lösung führen.

Sehr nice. Dann hast du seine Bean VESC App bestimmt auch schon getestet? Beides zusammen kombinieren und du brauchst kein Nunchuk mehr. Problem gelöst.

Normalerweise nicht. Nein. Zumindest nicht das ich wüsste. Mit dem genannten Dual Modul hatte ich aber mal zwei Devices gleichzeitig connected und man konnte wenn ich mich recht erinnre eine Nachricht von device 1 an das Modul schicken, welches das dann über den Uart ausgegeben hat und die Nachricht aber auch gleichzeitig an device 2 "gemirrort" wurde.