Nunchuk RF

barney · 4. April 2016

Hi Dude,

ich habe gerade sinniert, wenn man zwei oder mehr VESC hat, ob man die Telemetrischen Daten über eine uart bekommen kann.

Externe Links nur für Mitglieder sichtbar

Und wieder beruhigt.....

uart0 für den vesc

spi0 für ws28xx oder Pin18

spi1 für die Zellenüberwachung

bt-pi3 intern für die Fernbedienung

wlan-pi intern für das Smartphone

[url=][/url]

Duffman · 4. April 2016

Hey Dude,

ich hab letzte Woche endlich mal die Zeit gefunden meine NRF-Nunchuk Platinen zu bestücken und hab am Wochenende verzweifelt versucht eine Verbindung mit dem VESC herzustellen. Hab mich durch alle möglichen Firmware Versionen gekämpft und auch sonst alles mögliche probiert - ohne Erfolg.

Allerdings hab ich die ganze Testerei ohne Akku direkt über USB versorgt durchgeführt. Als ich dann probehalber mal einen Akku angeklemmt hab, hat es auf Anhieb geklappt.

Daher hier mal eine kurze Liste meiner Feststellungen:

- der NRF-Nunchuk verbindet sich nur mit dem VESC wenn ein Akku angeschlossen ist!!!

- es funktioniert unabhängig von der verwendeten Firmware Version. Hab 2.13 2.15 und 2.16 getestet.

- die binär codierte Nunchuk ID muss mit der VESC Controller ID übereinstimmen die auch die CAN Bus ID ist. (App Config / General)

- App Config auf NRF stellen

- unter Nunchuk zum testen disabled auswählen und den Stickausschlag kontrollieren

- im NRF Tab hab ich keine Einstellungen verändert.

- guck dir die NRF Transceiver gaaaanz genau an, hatte bei zweien Lötbrücken direkt am IC

LEDs:

Blau - beim Laden

Rot - C+Z drücken zum Verbinden, dauerhaft an bei Verbindung, geht aus bei Signalverlust / Verbindungsfehler

Ich werd die Tage noch meine anderen Platinen durchprobieren und ein paar Screenshots machen.

Hatte aus Verzweifelung noch mal unter Linux geflasht, wollt die unter Windows geflashte Platine dann auch noch mal ausprobieren.

Die erste Testfahrt war auch sehr positiv. Die Verbindung war viel besser als mit dem Kama obwohl ich den Empfänger (absichtlich) unter einigen Kabeln direkt auf dem VESC verstaut hatte.

Wenn ich alles am Laufen hab und zufrieden bin, werd ich auch noch einen ausführlichen Baubericht abliefern damit der Nachbau leichter wird...

Dude · 4. April 2016

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

Duffman · 4. April 2016

Bisher hab ichs am 4.10er VESC getestet, muss aber mein 4.7er Board demnächst auch noch umbauen...

Also die Rote LED geht beim Drücken von C+Z kurz an und nach einigen Sekunden wieder aus?

Deine Sachen kannst du mir selbstverständlich gerne schicken. Ich finds auch immer furchtbar wenn ich nicht weiß ob Sender, Empfänger oder Beide nicht funktionieren...

Dude · 4. April 2016

Also die Rote LED geht beim Drücken von C+Z kurz an und nach einigen Sekunden wieder aus?

Exakt so: an und nach wenigen Sekunden wieder aus.

Duffman · 4. April 2016

OK, also scheint der Controller schon mal zu Laufen und der Fehler liegt irgendwo auf der Funkstrecke oder im VESC...

Ich bekomme das gleiche LED Verhalten wenn ich die Falsche ID einstelle oder den VESC ganz abschalte... Hilft nicht wirklich bei der Fehlersuche...

So sahen 2 der 5 bei e b a y gekauften NRF Module unter dem Mikroskop aus:

Dude · 4. April 2016

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

Dude · 4. April 2016

Hi Dude,

ich habe gerade sinniert, wenn man zwei oder mehr VESC hat, ob man die Telemetrischen Daten über eine uart bekommen kann.
Externe Links nur für Mitglieder sichtbar

Und wieder beruhigt.....

uart0 für den vesc

spi0 für ws28xx oder Pin18

spi1 für die Zellenüberwachung

bt-pi3 intern für die Fernbedienung

wlan-pi intern für das Smartphone

[url=][/url]

... 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:

barney · 6. April 2016

Hi Dude,

meintest du diese Kommandos?

typedef struct {
  int js_x;
  int js_y;
  int acc_x;
  int acc_y;
  int acc_z;
  bool bt_c;
  bool bt_z;
} chuck_data;

was im Widerspruch zur Vedder Firmware steht
ind = 0;
chuck_d_tmp.js_x = data[ind++];
chuck_d_tmp.js_y = data[ind++];
chuck_d_tmp.bt_c = data[ind++];
chuck_d_tmp.bt_z = data[ind++];
chuck_d_tmp.acc_x = buffer_get_int16(data, &ind);
chuck_d_tmp.acc_y = buffer_get_int16(data, &ind);
chuck_d_tmp.acc_z = buffer_get_int16(data, &ind);

COMM_FW_VERSION = 0
COMM_JUMP_TO_BOOTLOADER
COMM_ERASE_NEW_APP
COMM_WRITE_NEW_APP_DATA
COMM_GET_VALUES
COMM_SET_DUTY
COMM_SET_CURRENT
COMM_SET_CURRENT_BRAKE
COMM_SET_RPM
COMM_SET_POS
COMM_SET_DETECT
COMM_SET_SERVO_POS
COMM_SET_MCCONF
COMM_GET_MCCONF
COMM_GET_MCCONF_DEFAULT
COMM_SET_APPCONF
COMM_GET_APPCONF
COMM_GET_APPCONF_DEFAULT
COMM_SAMPLE_PRINT
COMM_TERMINAL_CMD
COMM_PRINT
COMM_ROTOR_POSITION
COMM_EXPERIMENT_SAMPLE
COMM_DETECT_MOTOR_PARAM
COMM_DETECT_MOTOR_R_L
COMM_DETECT_MOTOR_FLUX_LINKAGE
COMM_DETECT_ENCODER
COMM_REBOOT
COMM_ALIVE
COMM_GET_DECODED_PPM
COMM_GET_DECODED_ADC
COMM_GET_DECODED_CHUK
COMM_FORWARD_CAN
COMM_SET_CHUCK_DATA

bearbeitet 6. April 2016 von barney

Dude · 6. April 2016

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.

barney · 6. April 2016

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.

Externe Links nur für Mitglieder sichtbar

Wenn ich das wüsste....

Aber warum Phyton, macht es die Sache nicht noch schwerer?

Dude · 6. April 2016

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.

barney · 7. April 2016

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 für die Steuerungsfunktionen c bevorzugen. Ansonsten Scriptsprachen für goodies wie LED Steuerung, damit jeder darin rumrühren kann.

Externe Links nur für Mitglieder sichtbar

barney · 9. April 2016

Hi Dude,

Hier ist die Ausgabe über uart0 und c recht gut erklärt:

Externe Links nur für Mitglieder sichtbar

barney · 10. April 2016

Hallo Dude,

ich habe mir gerade 2 x WS2812b LED-Streifen (je 1m wasserdicht) 60LED/m bestellt. Dafür soll es eine Lib geben, die für den Pi geschrieben wurde. (Phyton)

Einige DS1820 (Temperatursensoren) rumliegen. Die werden auch durch Libs vereinfacht. (RRD)

Ich habe zwei Studenten wegen der Webdarstellung generft. CSV und Ajax wurde empfohlen. Oder:

Für die Datendarstellung als Graph könnte RRD

Externe Links nur für Mitglieder sichtbar

verendet werden. Spart die Arbeit. Später kann man es selber schöner machen.

Wir müssen noch die Pins am Pi3 festlegen.

@Dude

kannst du schon die Werte aus dem VESC auslesen, wenn ja, kannst du mir einige 100 Datensätze als Textfile zukommen lassen, damit ich schon mal mit RRD und HTML5 experimentieren, oder es den beiden Studenten als Aufgabe weitergeben. :-)

bearbeitet 10. April 2016 von barney

Dude · 10. April 2016

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.

Dude · 10. April 2016

So was halt:

Externe Links nur für Mitglieder sichtbar

oder so

bearbeitet 10. April 2016 von Dude

barney · 10. April 2016

Hallo Dude,

deine Anmerkungen sind nicht einfach zu beantworten. Die erste Frage, die ich stellen müsste, wäre, was hat Benjamin vor.

Letzter Stand ist:

* nrf51822 BT als Multipoint Device vom Nunchuk, hin zum Smartphone. Er hat mit der derzeitigen Platine für den nRF eine schnelle Grundlage, wo im Prinzip nur der Transmitter getauscht werden muss (und die Software).

* Er will WS28xx ansteuern

* AS5704P anschließen oder Hallsensoren

* und ??

Ich würde gerne den puristischen Ansatz fahren, VESC für den Motor und ggf. höchstens Kommunikation für den Nunchuk.

Ist die UART am VESC belegt, stellt sich mir die Frage, wie kommen wir an die Daten. Da bleibt nur noch der CAN-Bus. Das muss aber nicht wirklich sein. Über USB wäre auch eine Möglichkeit. Ich habe versucht den VESC als Serielles Device mit dem Laptop zu koppeln, hat aber nicht auf Anhieb geklappt. Es gab nie eine Rückantwort. Ich weiß nicht, ob er da andere Kommandos verwendet. Da müsste ich einen USB-Sniffer mitlaufen lassen. Hier würde aber nicht dein Wunsch nach temporärer Verwendung des Pi3 greifen. Wir müssen an die BT belegte UART ran. Da müssten wir Benjamin dazu überreden, das er eine Multipoint Kommunikation im VESC hinterlegt. Ab hier wird es schrecklich.

Wixel:

Der lässt sich an zwei Punkten anschließen. Als PPM Geber oder oder an die UART angeschlossen. Mit der UART würden wir uns wieder den Weg zum VESC blockieren.

Ich denke noch mal intensiv nach....

Dude · 10. April 2016

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?

Duffman · 11. April 2016

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 )

Du kannst im Laufe der Woche deine Geschwindigkeit auch per NRF fixieren.

Hab deine Platine zum Laufen bekommen. Weiß aber nicht so hundertprozentig woran es lag.

Dein Empfänger hat auf Anhieb mit meinem Nunchuk funktioniert, daran lag es also nicht. Hab dann den NRF Transceiver von deine Platine runtergenommen und auf meine gelötet. Läuft, lag also auch nicht daran.

Neuer NRF Transceiver auf deine Platine, läuft nicht... Nächster NRF Transceiver auf deine Platine, läuft nicht... Nochmal neuer NRF Transceiver auf deine Platine, LÄUFT!!!

Die NRF Transceiver die bei dir nicht laufen, gehen sonderbarer Weise aber auf meinen Platinen...

Hab bei der ganzen Spielerei aber noch einiges rausgefunden:

Bei FW 2.13 ist die NRF ID gleich der CAN Bus ID.

Ab FW 2.14 gibt es das NRF Tab aus dem das letzte Feld der Adresse die NRF ID bestimmt.

Screenshots reiche ich nach...

Ausserdem hat Benjamin einen kleinen Fehler in seinem Code: Die Pins für die rote und die grüne LED sind in der conf_general.h vertauscht.

// LED Pins
#define LED_RED_PORT			GPIOB
#define LED_RED_PIN				12
#define LED_GREEN_PORT			GPIOB
#define LED_GREEN_PIN			13

Behindert die Funktion nicht, macht aber die Signalisierung des Ladezustands etwas komisch. (Rot = Voll, Grün = Leer)

Hab die Pins angepasst und die Firmware neu hochgeladen. Jetzt ist alles so wie es sein soll:

Wenn man bei aufgebauter NRF Verbindung C & Z drückt wird der Ladezustand durch Binkmuster angezeigt:

Lipo über 4V -> Grün 3s

Lipo über 3.6V -> Grün binkt 3x

Lipo über 3.2V -> Rot binkt 3x

Lipo unter 3.2V -> Rot 3s

static void show_vbat(void) {
mote_state state;
read_mote_state(&state);

LED_RED_OFF();
LED_GREEN_OFF();

float v1, v2, v3;

#if HAS_VBAT_EXTRA
v1 = 4.0;
v2 = 3.6;
v3 = 3.2;
#else
v1 = 2.9;
v2 = 2.5;
v3 = 2.3;
#endif

chThdSleepMilliseconds(1000);

const float v = state.vbat;
if (v > v1) {
	LED_GREEN_ON();
	chThdSleepMilliseconds(3000);
} else if (v > v2) {
	for (int i = 0;i < 3;i++) {
		LED_GREEN_TOGGLE();
		chThdSleepMilliseconds(500);
		LED_GREEN_TOGGLE();
		chThdSleepMilliseconds(500);
	}
} else if (v > v3) {
	for (int i = 0;i < 3;i++) {
		LED_RED_TOGGLE();
		chThdSleepMilliseconds(500);
		LED_RED_TOGGLE();
		chThdSleepMilliseconds(500);
	}
} else {
	LED_RED_ON();
	chThdSleepMilliseconds(3000);
}

LED_RED_OFF();
LED_GREEN_OFF();

chThdSleepMilliseconds(1000);
}

barney · 11. April 2016

Hi Duffman,

also benötigt man eine Palette von NRF Modulen (oder zufällig die "richtigen") um den nRF zum Laufen zu bringen. Da warte ich lieber die BT Variante ab.

Stammte der Blinkcode von dir?

Grüße

Barney

barney · 11. April 2016

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?

Kurz und knapp - Ja

Duffman · 11. April 2016

Hi Duffman,

also benötigt man eine Palette von NRF Modulen (oder zufällig die "richtigen") um den nRF zum Laufen zu bringen. Da warte ich lieber die BT Variante ab.

Stammte der Blinkcode von dir?

Grüße

Barney

Na ja, sie funktionieren ja eigentlich alle... nur halt nicht immer...

Hatte einen NRF Transceiver dabei, der bei mir erst nicht wollte. Hab dann mal kräftig mit Heißluft draufgehalten und seit dem geht er. Ich glaub die meisten Probleme bei dem Projekt hatte ich mit schlechten Lötstellen...

Was genau meinst du mit "Stammte der Blinkcode von dir?"

Den Code hab ich aus Benjamins main.c zitiert. Hab nur die LED Pinzuweisung in der conf_general.h geändert.

Habs nur mal ausführlich aufgeschrieben, da man dazu im Netz nichts genaues finden kann...

Bin aktuell noch dabei die Adresswahl über BCD Codierschalter einzubauen, aber ich hab das Gefühl, dass ich bei meinem STM32 irgendwie die zugehörigen Eingänge gebraten hab. Der bleibt immer bei NRF ID 0...

Dude · 11. April 2016

Kurz und knapp - Ja

Raspberry Cam und 7-Zoll Touch-Display hab ich bereits Nur läuft der BLDC-Logger aktuell noch nicht mit der RPi-Cam, nur mit der eingebauten am Mac ... und da waren Sie wieder, meine kleinen Problemchen. Aber nachdem der NRF läuft geht's frisch auf weiter, yes we can!

P.S.: Duffman, you made my day!

barney · 11. April 2016

Raspberry Cam und 7-Zoll Touch-Display hab ich bereits

Und welche Auflösung hat dein Display. Das BLDC-Tool hat ja mittlerweile eine ordentliche Anforderung.

Anmelden

Nunchuk RF

Empfohlene Beiträge

barney

Duffman

Dude

Duffman

Dude

Duffman

Dude

Dude

barney

Dude

barney

Dude

barney

barney

barney

Dude

Dude

barney

Dude

Duffman

barney

barney

Duffman

Dude

barney

Tritt dem Gespräch bei

Community

Was geht ab

Meine Aktivitätsverläufe

Tools