Nunchuk RF

[barney]

Hi Dude,

 

nicht in die Tischplatte verbeißen:

That takes a lot of space, and I don't really like the NRFs, especially not the counterfeit ones on ••••. I'm looking at alternatives, and I think using something like the NRF51822 with BLE might be an option. I have a few of them at home and have the SDK running since a few days ago. Qt also supports BLE in the latest versions, so then the same radio can be used for the remote, desktop and phone clients. Jacobbloy is spending a lot of time on that, so I want to help him out when I have time. The end result will probably be a small module that is connected over the UART port or CAN-bus.

 

Grüße

 

Barney

[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?

[barney]

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[emoji14]Was meinst Du?

Ideal. Ich suche mal blaue Augen. Das müsste es sein.

[Dude]

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

[barney]

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?

 

Der Wixel hat für eine PPM Steuerung schon fertigen Code da. Die Nutzbarkeit gegenüber einem nRF scheint größer zu sein. Bluetooth hat den Vorteil, dass der Aufbau mittels Handy oder Computer mit BT-Modul getestet werden kann. Dafür muss aber das Ausgangssignal in PPM gewandelt werden. Ich würde gerne immer noch ein Raspberry Pi 3 als als Steuerungszentrale verwenden. Die USB-Verbindung zwischen Pi und VESC kann alle Wichtigen Informationen übertragen. Telemetrie und die Ansteuerung. Der Pi könnte alles das machen, was unsere feuchte Nerd Fantasie so hergibt.

[Dude]

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?

[barney]

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?

 

Etwas anders:

Der VESC soll keine Signale mehr direkt verarbeiten. Also kein PPM oder BT, nRF....

Der Raspberry wird mittels USB an den VESC angeschlossen. Der Raspberry (

Externe Links nur für Mitglieder sichtbar

) hat eine größere Anzahl an brauchbare Interfaces, die für die Funkverbindung (welche auch immer (BT, Wixel, ...)) genutzt werden können. Ich würde hier gerne auch den Akkuwächter für bis zu 12S anschließen. Display von mir aus auch. Durch das WLAN-Interface kann eine Webseite ausgeliefert werden, die eine Konfiguration des VESC ermöglicht (Benjamin hatte da was geschrieben, das QT eine Webdarstellung unterstützt), bzw. telemetrische Daten bereit stellt. Die SD-Karte im Pi wird als Datenlogger genutzt. Die Programmierung eines Pi sollte leichter als ein ST RT-System sein.

 

Einfacher Einstig, wäre der Wixel und der Pi. Oder Wixel und VESC. Quellcode für den Wixel liegt als Demo vor.

[barney]

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?

 

Etwas anders:

Der VESC soll keine Signale mehr direkt verarbeiten. Also kein PPM oder BT, nRF....

Der Raspberry wird mittels USB an den VESC angeschlossen. Der Raspberry (

Externe Links nur für Mitglieder sichtbar

) hat eine größere Anzahl an brauchbare Interfaces, die für die Funkverbindung (welche auch immer (BT, Wixel, ...)) genutzt werden können. Ich würde hier gerne auch den Akkuwächter für bis zu 12S anschließen. Display von mir aus auch. Durch das WLAN-Interface kann eine Webseite ausgeliefert werden, die eine Konfiguration des VESC ermöglicht (Benjamin hatte da was geschrieben, das QT eine Webdarstellung unterstützt), bzw. telemetrische Daten bereit stellt. Die SD-Karte im Pi wird als Datenlogger genutzt. Die Programmierung eines Pi sollte leichter als ein ST RT-System sein.

 

Einfacher Einstig, wäre der Wixel und der Pi. Oder Wixel und VESC. Quellcode für den Wixel liegt als Demo vor.

[Dude]

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?

[barney]

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?

 

1. Entschuldigung, mit den permanenten Onboard war mir so innerlich, dass ich das vergessen habe dies für andere transparent zu machen.:thumbsup:

2. Benjamin hat geschrieben, das ein Pi durch den DRV versorgt werden kann (1.5 A to support MCU or additional system power needs.). Ich habe da so meine typischen Zweifel, aber notfalls kommt da ein Spannungsregler davor. (Step-down HV Spannungsregler Modul 2-3A Uin=4,5-60V einstellbar LM2596 HV, ab €2,-)

3. Nein, steht nicht im Widerspruch, da der Pi keine zeitkritischen Aufgaben ausführen muss, wie eine PWM für den BLDC. Die Diskussion ist beim VESC 5.0 ausreichend durchgekaut. Der Funkempfänger kann auch 1 bis 2 ms später verarbeitet werden. Durch die vielen schönen Schnittstellen, muss man sich nicht mit Protokollemulationen rumprügeln. (

Externe Links nur für Mitglieder sichtbar

) MOSI und der andere Kram ist schon vorhanden. Beispiele für die Programmierung sind auch vorhanden.

 

Las mich mal Optimist sein. Ich will und kann kein RT nebenbei lernen. Scripting sollen wir alle hinbekommen.

 

bearbeitet 30. März 2016 von barney

[Dude]

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

[barney]

Hört sich gut an ... muss man aber nicht in der RT-Firmware dennoch rumprogrammieren, damit die ganzen Kommandos von USB gezogen werden?

 

Nö!

Du kannst im BLDC-Tool Kommandos im Terminal absetzen, die über USB im VESC ankommen. Tipp mal help ein! Das ist Seriell über USB.

[hexakopter]

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.

 

Eure RT Diskussion verstehe ich auch nicht wirklich. Ihr sprecht so als sei RT eine eigene Programmiersprache, aber wenn ich es richtig sehe bezieht ihr euch nur auf Real Time, also ein Echtzeitsystem.

 

Mit "MOSI und der andere Kram ist schon vorhanden" meinst du vermutlich, dass ein onboard SPI vorhanden ist. Damit außen stehende das auch nachvollziehen können.

 

Der LM2596 ist übrigens nicht für 60V ausgelegt.(Maximum Supply Voltage 45V)

Externe Links nur für Mitglieder sichtbar

 

EDIT.: Deine Frage "Is it possible the BLDC Tool GUI offer by WEB-Server?" aus dem VESC Forum verstehe ich übrigens auch nicht. Entweder mein Englisch ist zu schlecht oder der Satz ist kein Englisch. Vielleicht beschreibst du dort ausführlicher was du meinst.

bearbeitet 30. März 2016 von hexakopter

[barney]

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.

 

Eure RT Diskussion verstehe ich auch nicht wirklich. Ihr sprecht so als sei RT eine eigene Programmiersprache, aber wenn ich es richtig sehe bezieht ihr euch nur auf Real Time, also ein Echtzeitsystem.

 

Mit "MOSI und der andere Kram ist schon vorhanden" meinst du vermutlich, dass ein onboard SPI vorhanden ist. Damit außen stehende das auch nachvollziehen können.

 

Der LM2596 ist übrigens nicht für 60V ausgelegt.(Maximum Supply Voltage 45V)

Externe Links nur für Mitglieder sichtbar

 

EDIT.: Deine Frage "Is it possible the BLDC Tool GUI offer by WEB-Server?" verstehe ich übrigens auch nicht. Entweder mein Englisch ist zu schlecht oder der Satz ist kein Englisch. Vielleicht beschreibst du dort ausführlicher was du meinst.

 

1. BT & Raspberry: ja, ist so möglich! Darum die Freude über die vielen Schnittstellen. Und der Pi 3 hat WLAN und BT onboard. Das vereinfacht die Sache.

2. Wixel: Zwischenschritt, weniger Energiebedarf

3. RT: Real Time, ich habe nicht behauptet das es eine eigene Programmiersprache ist. Ich kann etwas C, aber nicht den RT Slang. Daher müsste ich es verstehen und lernen. Hier könnten ggf. ADA Kenntnisse mit Semaphore weiterhelfen. :devil: Ich bin zu blöd dafür.....

4. MOSI: Dafür habe ich den Link mit den Erweiterungsanschluss beigelegt.

5. LM2596: Fies, das der auch für 60V angeboten wird:confused5: LM2596HV bis 63V->

6. Dein Englisch ist besser als meins. Vielleicht kannst du das für mich ins Englische übersetzen: Kann die QT GUI mittels WEB-Server dargestellt werden? Heißt, Muss die GUI modifiziert werden, oder kann QT diese als WEB-Applikation bereitstellen? Ich befürchte nicht.

Wie soll ich es beschreiben. Die GUI würde nativ auf dem Pi laufen und sich mittels am Pi angeschlossenen Bildschirm konfigurieren lassen. Dude hat vor ein Display anzuschließen, ich möchte es mittels Handy als Webapplikation nutzen.

[barney]

oder ESP8266 WLAN Modul

 

Das Teil war eine Pleite im Zusammenhang mit den Teensy, den ich gerne verwende. Direkt Programmieren? Keinen Nerv für solch ein Affentheater....

[Dude]

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:

[barney]

Ich habe meinen Pi3 in der Jackentasche [emoji51]

[Dude]

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.

[hexakopter]

@barney Mein Englisch war wohl doch zu schlecht. Du hast jetzt ja schon eine Antwort bekommen.

Ich weiß nicht wie lange das bei dir mit den ESP8266 her ist, aber da wird ja auch immer mehr daran gebastelt. Was eigenes habe ich dafür aber auch noch nicht geschrieben. Das flashen an sich war schon komisch genug.

 

@Dude Dein angesprochener Punkt c) ist genau das was ich meinte. Beides zusammen ist etwas übers ziel hinausgeschossen meiner Meinung nach.

Ich bin denke ich erst mal nicht dabei nen Raspberry mit ans Board zu schrauben, weil ich erst mal dazu kommen muss die VESCs fertig zu löten, am besten ein Nunchuk fertig zu bekommen und das Board selbst auch noch lackiert und mit Akkus versorgt werden muss. Außerdem finde ich nen RPi etwas oversized. Ich werde irgendwie versuchen was kleineres zum laufen zu bekommen. Z.B. habe ich hier noch Dual Bluetooth Module die sowohl BT2.0 als auch BT4.0 (also BLE) sprechen. Das ganze soll auch dual laufen können. Ziel wäre es also den Nunchuk über BT2.0 zu verbinden als TX und dann z.B. das Handy über BT4.0 als RX zum loggen. Bin mir noch nicht ganz sicher ob das so klappt. Werde ich zu gegebener Zeit mal testen.

[Dude]

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)?

[hexakopter]

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.

[barney]

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)?

 

Daher hatte ich mir die HC05 geholt. Die können bis zu 7 Gegenstellen gleichzeitig paaren. Paaren, aber nicht "gleichzeitig" ansprechen. Du musst die bestehende Verbindung abbauen und die nächste aufbauen, es entfällt nur das zeitfressende Paaren. Die ms für die Umschaltung hätten verhindert, eine FB und ein Smartphone RT, geeignet in die Kommunikation einzubeziehen. Ich hatte es mit dem BAMBAM Controller probiert und verworfen.

bearbeitet 31. März 2016 von barney

[barney]

@barney Mein Englisch war wohl doch zu schlecht. Du hast jetzt ja schon eine Antwort bekommen.

Ich weiß nicht wie lange das bei dir mit den ESP8266 her ist, aber da wird ja auch immer mehr daran gebastelt. Was eigenes habe ich dafür aber auch noch nicht geschrieben. Das flashen an sich war schon komisch genug.

 

@Dude Dein angesprochener Punkt c) ist genau das was ich meinte. Beides zusammen ist etwas übers ziel hinausgeschossen meiner Meinung nach.

Ich bin denke ich erst mal nicht dabei nen Raspberry mit ans Board zu schrauben, weil ich erst mal dazu kommen muss die VESCs fertig zu löten, am besten ein Nunchuk fertig zu bekommen und das Board selbst auch noch lackiert und mit Akkus versorgt werden muss. Außerdem finde ich nen RPi etwas oversized. Ich werde irgendwie versuchen was kleineres zum laufen zu bekommen. Z.B. habe ich hier noch Dual Bluetooth Module die sowohl BT2.0 als auch BT4.0 (also BLE) sprechen. Das ganze soll auch dual laufen können. Ziel wäre es also den Nunchuk über BT2.0 zu verbinden als TX und dann z.B. das Handy über BT4.0 als RX zum loggen. Bin mir noch nicht ganz sicher ob das so klappt. Werde ich zu gegebener Zeit mal testen.

 

ESB8266:

ca. 12 Monate. Der Aufwand für das Ergebnis, was mit den Pi nur einige Zeilen sind, steht in keinem Verhältnis. Der Pi 3 ist ein deutlicher overkill, dass ist mir klar. Aber wenn man keine RT Kenntnisse hat und viele Mitbastler finden möchte, muss die Umgebung so einfach wie möglich sein. Für €40,- habe ich kein BAMBAM hinbekommen. Der Pi hat, bis auf den Spannungsregler, so viele Möglichkeiten auf der Platine, das er die Beste Basis darstellt. Du Findest Antworten zu vielen Fragen im Internet und musst nicht immer im Uhrschleim waten. Die Größe ist akzeptabel. Ich hätte gerne auf der BAMBAM Platine BT, WLAN, SD-Karte und einen Lautsprecheranschluss gehabt. Kai hat mit der Sprachausgabe schone eine geile Steilvorlage hingelegt. Stell die Vor, dein Board spricht dich an, das du nur noch 20% Energie hast. Du musst dich auf LEDs oder Displays achten. Du kannst nach deiner Ausfahrt Telemetriedaten auslesen, korreliert mit einer GPS Aufzeichnung. Ich bin Nerd und nicht mehr in der Altersstufe wie eXo und mit den Wunsch genährt, an einem Berg die 90° Abfahrt zu nehmen.

 

Ich würde mich freuen, wenn du wie Dude deine Expertise einbringst und hier was beisteuerst.

[barney]

Hi Dude,

 

für debugging:

 

Externe Links nur für Mitglieder sichtbar

 

decodiert das Protokoll vom nRF 24l01. Hardware ist z.B. ein Saleale clone für wenige €.

[Dude]

Schon bestellt