Graupner HOTT native Telemetrie auf dem AQ

as.149

Neuer Benutzer
#81
Hi sandmen,
das bedeutet, dass man nur noch mit der Mavlink to Hott Erweiterung und dem IOBoard (http://autoquad.org/wiki/wiki/autoq...ns/telemetry-xbee/mavlink-led-signaling-hott/), an aktuelle Firmware und Telemetrie kommt, oder gibt es da noch etwas anderes?
Ehrlich schade drum, da nun noch mehr Elektronik im Kopter verbaut werden muss. Sprich mehr Kabel, mehr Gewicht und mehr Stromverbrauch.
Stizi

Gesendet von meinem Nexus 10 mit Tapatalk
 

r0sewhite

Erfahrener Benutzer
#82
Na ob sich die 3 Gramm mehr von einem Arduino messbar auf die Flugzeit auswirken, wage ich zu bezweifeln. Solche "Addons", insbesondere, wenn sie eine hohe CPU-Last mit sich bringen, sind auf der Flugsteuerung meines Erachtens nach nicht gut untergebracht. Daher freu Dich einfach, dass es eine HoTT Telemetrie-Lösung gibt, ohne die Leistungsfähigkeit und Zuverlässigkeit des AutoQuad in irgendeiner Weise zu beeinträchtigen.
 

as.149

Neuer Benutzer
#83
Morgen Tilman,
war ein paar Tage unterwegs, daher melde ich mich erst jetzt.
Letztendlich hast du recht, die paar Gramm werden mich schon nicht umbringen.
Von der CPU her habe ich das so noch nicht betrachtet. Aber klar, die Telemetrie wird schon ein wenig CPU-Last ausmachen.
Wichtig ist weiterhin noch für mich und andere Autoquader, diese Infos zu lesen, dem im Netz findet man dazu nicht viel bis gar nichts.
Es wäre auch mal schön davon in der Autoquad-Wiki zu lesen, könnte jemand da noch einem nützlichen Zusatz schreiben?
Ich werde mir mal die mav2hott Lösung anschauen und wahrscheinlich verbauen.
Vielen dank an alle für die sehr nützlichen Infos.

Gruß
Stizi
 

r0sewhite

Erfahrener Benutzer
#84
Von der CPU her habe ich das so noch nicht betrachtet. Aber klar, die Telemetrie wird schon ein wenig CPU-Last ausmachen.
Nicht nur ein bisschen. Mav2HoTT hat die CPU-Last recht beunruhigend in die Höhe geschraubt. Und da der eine HoTT will, der andere Spektrum und der Dritte Jeti Duplex, macht es einfach mehr Sinn, die Konvertierung von Mavlink in das jeweilige Telemetrie-Protokoll auszulagern, damit die Firmware unangetastet bleibt.
 

as.149

Neuer Benutzer
#85
So habe ein JD IOBoard v1.1 bestellt (http://store.jdrones.com/jD_IOBoard_p/jdioboard11.htm).
Jetzt noch, wie im Wiki beschrieben, die zwei 2200 Ohm Widerstände bestellen und auf die Lieferung warten.
Welchen Current Sensor könnte ich denn verwenden? Wäre ein ACS758xCB (ACS758ECB-200B-PSS-T) in Ordnung?
Man sieht in der AQ-Wiki auf dem vorletzten Bild die Beschriftung nicht so richtig, ist recht unscharf.
Der Kondensator von 100nF müsste ich doch richtig gelesen haben, oder?

Nochmal kurz zum Anschluss des IOBoards an das AQ-Board.
Aktuell habe ich am FTDI-Port einen Funksender 433MHz von Flyduino. Der FTDI-Port lässt sich ja, lt. AQ-Wiki, parallel verwenden.
Also kann ich den Funksender und das JD IOBOard gleichzeitig, mit den Widerständen abgesichert, anschließen und nutzen.
Könnte man das JD IOBoard auch an den TX-Port der DIMU verbinden, da ist ja aktuell der GR-24 angeschlossen.
Wenn nicht für was kann man den Serial Port der DIMU sonst noch nutzen?

Bitte bescheid geben, wenn ich hier zu viel zur Verwendung des Ganzen frage. Schließlich muss man im Forum nur suchen und lesen.
Aber ich möchte den diesen Thread für andere Autoquader besser verständlich gestalten.

Gruß
Stizi
 
#86
Wenn du den Stromsensor auf eine Platine setzen willst ist der ACS758ECB-200B-PSF-T besser geeignet; da sind die Anschlüsse bereits gebogen.
Anhang anzeigen design.brd.zip
Das PCB hat Menno gemacht/verwendet; kannst du ja als Template verwenden.

Nur der TX der UART lässt sich parallel verwenden; am RX kann nur ein Gerät hängen.


So habe ein JD IOBoard v1.1 bestellt (http://store.jdrones.com/jD_IOBoard_p/jdioboard11.htm).
Jetzt noch, wie im Wiki beschrieben, die zwei 2200 Ohm Widerstände bestellen und auf die Lieferung warten.
Welchen Current Sensor könnte ich denn verwenden? Wäre ein ACS758xCB (ACS758ECB-200B-PSS-T) in Ordnung?
Man sieht in der AQ-Wiki auf dem vorletzten Bild die Beschriftung nicht so richtig, ist recht unscharf.
Der Kondensator von 100nF müsste ich doch richtig gelesen haben, oder?

Nochmal kurz zum Anschluss des IOBoards an das AQ-Board.
Aktuell habe ich am FTDI-Port einen Funksender 433MHz von Flyduino. Der FTDI-Port lässt sich ja, lt. AQ-Wiki, parallel verwenden.
Also kann ich den Funksender und das JD IOBOard gleichzeitig, mit den Widerständen abgesichert, anschließen und nutzen.
Könnte man das JD IOBoard auch an den TX-Port der DIMU verbinden, da ist ja aktuell der GR-24 angeschlossen.
Wenn nicht für was kann man den Serial Port der DIMU sonst noch nutzen?

Bitte bescheid geben, wenn ich hier zu viel zur Verwendung des Ganzen frage. Schließlich muss man im Forum nur suchen und lesen.
Aber ich möchte den diesen Thread für andere Autoquader besser verständlich gestalten.

Gruß
Stizi
 

as.149

Neuer Benutzer
#87
Hi,
danke für die RX/TX Infos, wusste ich so nicht. Das mit dem ACS758 und dem PCB muss ich mir noch anschauen.

Da ich den RX nicht parallel nutzen kann, könnte ich aber dennoch mit dem Funksender Telemetrie zum Tablet senden und mit dem IO-Board die Telemetrie, mit RX/TX, zur MX-20 senden und auch über diese, Werte wie Waypoints oder PID- Settings, setzen.

Mein Gedanke ging ja anfangs dahin, dass ich den UART-Port der Dimu z.b. für den Funksender und den Onboard UART-Port für das IO-Board nutzen kann.
Somit hätte ich beide UARTs im Einsatz. Das wäre doch in meinem Fall besser.
Mal davon abgesehen, dass ich nicht gleichzeitig auf MX-20 und Tablet schauen kann, müsste ich somit, wenn der Kopter zusammengebaut ist, nicht immer etwas um stecken.
Waypoints am Tablet setzen und während des Fluges Telemetrie an der MX-20 überwachen und das recht komfortabel, ohne fummeln.
Wie rum auch immer, beide UARTs gleichzeitig im Einsatz entspannt die Geschichte.

Gruß
Stizi

Gesendet von meinem Nexus 10 mit Tapatalk
 

as.149

Neuer Benutzer
#88
So der JDrones DIN A4 Umschlag ist eingetroffen. Hm, DIN A4 für ein kleines Board von ca 1,5 x 3cm. Egal, aber eine 2 Wochen Zustellung aus Thailand ist schon nicht schlecht.

Gesendet von meinem Nexus 10 mit Tapatalk
 

as.149

Neuer Benutzer
#89
Fast fertig. Telemetrie kommt am der MX-20 an.

Habe nun noch die Autoquad FW V7.1 b1897 geflashed und die MX-20 als auch den GR-24 aktualisiert.
Zur Info, ich musste das IO-Board mit der Arduino-IDE V1.05 flashen, mit der neuesten gibt es Kompilierungsfehler.
Der ACS758 und die restl. Komponenten sind bestellt und werden später verbaut.
Weiterhin muss ich noch die Kabel meiner LED-Strips (ohne OnBoard-Kontroller) umbauen und am IO-Board anschließen.

Aktuell nutze ich den UART-Port des AQ6r1 weiterhin für meine Funkverbindung und den UART der DIMU habe ich in der QGC auf das "MavLink" Protokol gesetzt. Danach hatte ich die Telemetriedaten auf meiner Funke.
Was noch nicht ankommt sind die Daten der ESCs. Diese werden bei mir per CAN-Bus angesteuert.
Sollten die nicht auch noch gesendet werden?
Weiterhin gibt es bei der Konstellation mit dem IO-Board, keine Telemetrie im Text-Mode nur Binary Telemetrie kommt an.
Wie sieht es damit aus?
Ich muss gestehen, dass ich in der Mav2HoTT Firmware noch nichts eingestellt habe, fehlt da noch etwas?
Im Readme bzw. Release-Notes habe ich dazu nichts gelesen.

Gruß
Stizi
 

as.149

Neuer Benutzer
#90
Hallo,

habe mich nun ein wenig mit dem Code beschäftigt.
Die Telemetrie der ESCs und die Telemetriedaten im Text-Mode sind in der Mav2HoTT Version 0.981 nicht implementiert.
Wer weiß vielleicht kommem die ja noch in den nächsten Versionen, es ist schon länger her, seit am Mav2HoTT Code etwas gemacht wurde.

Ich habe noch keine Komponenten für die Strommessung erhalten, kann somit noch nichts dazu sagen.

Aktuell habe ich aber das Problem, dass nur drei LED-Strips (ohne Kontroller und nicht RGB) leuchten/blinken. Der 4. Strip wird auch schon beim Booten, des/der IO-Boards/MCU, nicht angesprochen. Dieser Strip ist aber definitiv nicht defekt, da ich diesen an anderen Output-Pins bereits zum aufleuchten gekriegt habe.

In der "FrameConfigs.h" steht folgende Zeile:
"#define maxLed 4"
Das Passt zu meinen 4 LED-Strips.

Alles andere passt meiner Meinung nach auch soweit. Was kann hier die Problematik sein?
Werden hier andere Output-Pins angesteuert, welche sich in der Version 1.1 des jDrones IO-Boards geändert haben?
Siehe io-board_v1.1.pdf letzte Seite.

Gruß
Stizi
 

as.149

Neuer Benutzer
#91
Hallo,

Da ich das IOBoard Version 1.1 nutze, musste ich die Pin-Nummern für die LED-Outputs in der "FrameConfigs.h anpassen (Mav2HoTT Version 0.981):
Von Default:
#ifdef STANDARDLED
#ifndef BOARD_MICRO /* Output I/O pin array, choose your own preferred pins and sequence * (Jdrones IO standard) */
const uint8_t L1 = 10; /* Used for LED & Pattern*/
const uint8_t L2 = 9; /* Used for LED & Pattern*/
const uint8_t L3 = 8; /* Used for LED & Pattern*/
const uint8_t L4 = 4; /* Used for LED & Pattern*/
const uint8_t L5 = 3; /* Un-Used */
const uint8_t L6 = 2; /* Un-Used */
#endif
Nach IOBoard V1.1:
#ifdef STANDARDLED
#ifndef BOARD_MICRO /* Output I/O pin array, choose your own preferred pins and sequence * (Jdrones IO standard) */
const uint8_t L1 = 7; /* Used for LED & Pattern*/
const uint8_t L2 = 8; /* Used for LED & Pattern*/
const uint8_t L3 = 9; /* Used for LED & Pattern*/
const uint8_t L4 = 10; /* Used for LED & Pattern*/
const uint8_t L5 = 3; /* Un-Used */
const uint8_t L6 = 2; /* Un-Used */
#endif
Also entsprechend dieser Grafik:


Nun ist es allerdings so, dass nach dem Einschalten alle LEDs, beim booten des IOBoards angesprochen werden.
Wenn die Autoquad MCU gebootet hat, blinken allerdings 2 LED-Strips unterschiedlich.
Ein Strip blinkt genauso, wie in den LED Patterns in der "LEDs.ino" beschrieben.
Die MCU ist "Disarmed" ohne GPS-Signal. Es wird also diese Pattern angewendet:
{ 1,1,0,0,1,1,0,0,1,1 ,1,1,0,0,1,1,0,0,1,1 ,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0}, // 1 (Disarmed - no GPS fix)
Der andere Strip blinkt kontinuierlich und gleichmäßig, wie ein Heartbeat.
Warum blinkt hier nur ein Strip richtig und nicht 2 (z.B. die 2 vorderen) und der andere wie ein Heartbeat?

Wenn ich nun auf "Armed" schalte, blinkt der o.g. Strip wieder richtig wie in den Patterns angegeben:
{ 1,1,1,1,1,1,1,1,0,0 ,1,1,1,1,1,1,1,1,0,0 ,0,0,0,0,0,0,0,0,0,0 ,0,0,0,0,0,0,0,0,0,0}, // 3 (Armed)
Aber auch hier wieder nur ein Strip, der Heartbeat Strip leuchet dauerhaft.
Geht die MCU in den "Flying" status über, verhält sich wieder der eine Strip richtig und leuchtet dauerhaft, der Heartbeat Strip blinkt dann
wie der richtig angesteuerte Strip im "Armed" Status. Die beiden Strips haben somit ihr Blinkverhalten gewechselt.

Schalte ich die FC im "Flying" Status aus, blinken alle 4 Strips wie verrückt. Hier scheint das richtig Pattern auf alle 4 Strips angewandt zu werden.

Ich habe bereits die Outputs in der "FrameConfigs.h" gewechselt und in der "LEDs.ino" die "signalingWriteLeds" Anweisungen getauscht.
Also "if (pgm_read_byte (&sig_pattern[statusId][(patNo)+ioCounter]))..." gegen "astDigitalWrite(L1,(pgm_read_byte (&sig_pattern[statusId][(patNo*1)+ioCounter]) ? HIGH : LOW));..."
Beides hat nicht geholfen. Weiterhin habe ich auch den UART der MCU verwendet, anstatt wie bisher den UART der DIMU.
Auch hier keine Besserung.

Soweit ich im Internet verschiedene Foren-Threads gelesen habe, handelt es sich immer um das IOBoard V1.0, ich habe ja nun die V1.1.
Hat sich hier nicht nur die PIN-Belegung geändert sondern auch das Ansprechverhalten für die LEDs?
Komme leider mit meinem Latein nicht weiter.
Kann mir dazu jemand weiterhelfen?

Gruß

Stizi
 
FPV1

Banggood

Oben Unten