Neues Projekt: RC-Lab

[Moskito_Ron]

AW: Neues Projekt: RC-Lab

Ich habe mir auch ein RC Lab bestellt und der zusammenbau war schnell erledigt.
Tooles Toool zum Messen und Testen der Servos.
Mir gefällt dass sich die Firmware updaten lässt und man so
die nächsten Features einfach aufspielen kann.

[Cherry 2000]

AW: Neues Projekt: RC-Lab

So, die Servo-Geschwindigkeitsmessung funktioniert jetzt auch, zumindest bei meinem Testservo. Ist ein Futaba S3073HV. Ich krieg 0,2 s auf 60° raus, an 6 V. Das entspricht ziemlich genau den Herstellerangaben. Denke das ist prima!

Stefan, wir müssen das unbedingt mal mit dem Junsi vergleichen. Du hattest doch gemeint, dass der nicht genau die Herstellerangaben trifft, sondern eher langsamere Werte ausgibt.

[Moskito_Ron]

AW: Neues Projekt: RC-Lab

So, die Servo-Geschwindigkeitsmessung funktioniert jetzt auch, zumindest bei meinem Testservo. Ist ein Futaba S3073HV. Ich krieg 0,2 s auf 60° raus, an 6 V. Das entspricht ziemlich genau den Herstellerangaben. Denke das ist prima!.

Auf so eine Funktion habe ich schon lange gewartet um div. Servos hier vegleichen zu können.
(unter Last z.B.)
Freu mich schon auf das Update.

Gruss
Ron

[Cherry 2000]

AW: Neues Projekt: RC-Lab

MKS HBL 980 HV 0,04 s bei 6 V und 0,03 s bei 8 V, d.h. Punktlandung

Hab jetzt mal Stefan's Junsi iCharger 308 Duo zum Vergleich hergenommen. Die Ausgangssignale sind halt um 1 us daneben (im Vergleich zur Kalibriersignal vom Oszi, liegt an der flachen steigenden Flanke [Flankensteilheit 1..2 us !!], die fallende Flanke ist OK). Die Speedwerte bei sehr schnellen Servos liegen auch etwas unter den Herstellerangaben, das hat sich bei meinen Servos bestätigt. Ansonsten ganz nett das Teil. Das fehlende analoge Poti (hat nur nen Drehimpulsgeber) würde ich vermissen, und natürlich die Möglichkeit zur Strom-/Spannungsmessung. Ist aber ja primär ein Lader und kein Servo-Tester

[Cherry 2000]

AW: Neues Projekt: RC-Lab

So, die neue V1.3 mit Support für Servo-Speed-Tests ist jetzt released, siehe Webpage.

Es sind nun alle für mich relevanten Dinge implementiert

Sofern keiner mehr Interesse und Wünsche hat war's das dann ;-)

[Husi]

AW: Neues Projekt: RC-Lab

Hallo Gernot,

mich würde mitfliegendes Modul interessieren, das ein Speichern der Servo-Impulslänge (in welchem Format auch immer) von mindestens 4 (besser 7 Kanäle) vornimmt. Mehr als 4 Kanäle, weil ich auch gerne den Motor, die Flugphasen und ein ungemischtes Pitch-Signal mit auf der SD-Karte hätte.
Eine Anzeige, Bluetooth etc. würde ich nicht brauchen, weil ich später am Rechner meine sonstigen geloggten Telemetriedaten auslese und die Empfänger/Servo Infos "dazu werfen" möchte um die restlichen Log-Daten besser beurteilen zu können.

Wie weit kannst du diese Wünsche jetzt schon erfüllen, bzw. hättest du Interesse an dem Projekt noch weiter zu machen?


Vielen Dank
Mirko

[Cherry 2000]

AW: Neues Projekt: RC-Lab

Hallo Mirko,

vielen Dank für dein Interesse. Eine Mehrkanal-Version schwebt mir schon länger vor (wurde auch auf der Rotor Live von verschiedenen Leuten angesprochen). Das jetzige Design kann von den freien Pins her maximal 2 Kanäle (Puls und Strom), der Rest wird für Schalter und LCD benötigt.

1.) Sind die Ströme generell auch von Interesse? Ich denke ja, eine hohe Stromaufnahme kann u.U. frühzeitig vor einem Fehler warnen (Schwergängigkeit, langsam sterbendes Servo, ....). Ich würde wenn dann schon gerne beides, Puls und Strom, vorsehen (auch wenn man nicht beides gleich braucht). Die Segelflieger hatten sich das auch gewünscht.

Sofern wir eine reine Mehrkanal-Mobilversion bauen möchten, d.h. ohne Schalter und LCD, hätte man natürlich mehr I/O Pins zu Verfügung und könnte ein neues Design machen. Das jetzige Sparkfun Pro Micro Board hat etwa 16 I/O Pins, d.h. wenn man Puls und Strom pro Kanal messen möchte, könnte man bis zu 8 Kanäle realisieren. Die Software ist dazu ist nicht weiter tragisch, das meiste existiert ja schon.

Und noch zwei weitere Fragen, die wir vorab diskutieren sollten:

2.) Du sagst, du möchtest Flugphasen und ungemischtes Pitch aufzeichnen. Verwendest du einen klassischen Empfänger mit separaten Kabeln zum FBL? Weil aus dem FBL kommt ja normalerweise keine Flugphaseninfo und auch nur gemischte Servosignale. Sofern man an die FBL-Eingangssignale kommt, sollte die Messung kein Problem sein. Keven hatte auch mal vorgeschlagen, dass man von den Ausgangssignalen evtl. wieder auf die ungemischten Inputs zurückrechnen könnte (die alten ALIGN 3G FBLs haben das ja so gemacht).

3.) Zum Thema Logging: Einen MicroSD-Kartenslot könnte man schon dazubauen. Die CPU unterstützt das, das Pro Micro Port Board hat die Pins allerdings nicht auf Lötanschlüsse rausgeführt. Das könnte man aber zur Not mit Fädeldraht nachrüsten (Kartenslot mit Heißkleber auf der Platine befestigen und dann drei kleine Drähte an die CPU löten). Von der Telemetrieeinspeisung bin ich nach wie vor nicht so ganz überzeugt. Zum einen brauchts Implementierungen für die verschiedensten Telemetriesysteme, zum anderen sind es derart viele Messwerte (bei obigem Design schon 16 nur für Pulsbreite und Strom; noch viel mehr wenn wir Pulsfrequenz und evtl. min/max-Werte für jeden Kanal dazu nehmen) womit viele Systeme bereits überfordert sind. Bleibt noch das Loggen auf dem Handy. Das wäre an sich das einfachste Verfahren. Nur die Reichweite der normalen Bluetooth-Module (30..50 m) spricht (noch) dagegen, evtl. wäre WLAN eine Alternative.

Gruß, Gernot

[Husi]

AW: Neues Projekt: RC-Lab

Hallo Gernot,

wenn du die Mehrkanal-Version mit MicroSD-Logging entwickeln würdes, hättest du mit mir mindestens einen Abnehmer. :-)

Vielleicht kurz zu mir.
Mich interessiert die Flugphysik und Aerodynamik. Darum habe ich mir einen Meßdatenheli aufgebaut, bei dem es zwei Telemetrie Kanäle mit je 16 Sensordaten gibt. Beide Kanäle zeichnen die Daten auf je eine MicroSD Karte auf. Einer der beiden Kanäle funkt seine Meßwerte zu meinem Sender, was ich aber nicht unbedingt brauche.
Hier ein reduziertes Bild von zwei Flügen. Linker Flug konst. Drehzahl mit zwei kräftigen Pitch-Stößen und der rechte Flug mit regelmäßig geänderter Drehzahl im Flug (via 3D Einstell-Digi).


Da mir die Informationen noch nicht aussagekräftig genug sind, möchte ich gerne die Steuerkommandos mit in meine Log-Daten aufnehmen.
Aktuell fliege ich mit Paddel, perspektivisch möchte ich ein FBL-Kopf nehmen, aber KEIN FBL-System, sondern den FBL-Kopf "von Hand" fliegen. Das habe ich vor ein paar Jahren mit meinem 450er T-Rex und Dreiblattkopf auch schon getan, es geht also.

So gesehen wäre deine Weiterentwicklung die passende Ergänzung für meinen Meßdatenheli.

Viele Grüße
Mirko

[Cherry 2000]

AW: Neues Projekt: RC-Lab

Hab mir jetzt mal ein MicroSD-Gehäuse bestellt, mal sehen wie aufwändig das mit dem SD-Logging ist. Werde berichten...

[Husi]

AW: Neues Projekt: RC-Lab

Hab mir jetzt mal ein MicroSD-Gehäuse bestellt

Ein Freund von mir hat zum testen einfach ein SD- auf Micro-SD-Kartenadapter genommen und Kabel an die Kontakte der SD Karte gelötet.
Dann die Micro-SD-Karte in den Adapter schieben und testen.

Viele Grüße
Mirko

[Cherry 2000]

AW: Neues Projekt: RC-Lab

Stimmt, zum Testen geht das auch :-)
Aber wir brauchen eh einen Spannungsregler für 3,3V.
Das CPU-Board läuft mit 5V, SD-Karten mit 3,3V.
Bzgl Pegelumsetzung der Signale muss ich auch mal schauen.

[DirkS]

AW: Neues Projekt: RC-Lab

Da gibt´s ja fertige Breakout Boards mit Level Shifter.

Hier z.B.

[Cherry 2000]

AW: Neues Projekt: RC-Lab

Hier jetzt ein 7-Kanal Entwurf mit Option zur Strommessung. Ich habs mal RC Lab 7x Log genannt.

Die ersten 5 Kanäle werden über normale Interrupts gemessen, die letzten beiden Kanäle brauchen dann Pin-Change-Interrupts, d.h. teilen sich einen gemeinsamen Interrupt (was vlt. etwas knifflig werden kann).

Das mit der MicroSD-Karte hab ich gestern noch auf einem Uno mit TFT/SD-Shield probiert, funktioniert soweit. Das sollten wir auf dem Pro Micro Board auch hinkriegen.

Was jetzt noch zu klären ist:

1. Kabel/Steckerleisten: wollen wir Servoverlängerungskabel dranmachen, so wie im klassischen RC Lab? (Vorteil: kein Platine nötig; keine Aussteck- oder Kurzschlussgefahr) oder lieber eine 3-reihige Steckerleiste so wie bei FBLs/Empfänger? (Vorteil: keine unnötigen Kabel, die nicht benötigt werden und rumhängen). Im Fall von Steckerleisten könnte man eine universelle Streifenplatine nehmen und die von Hand bearbeiten (für kleine Stückzahlen sicherlich OK).

2. Start/Stop/Logfiles: ich würde das Logging sofort nach dem Einstecken des Akkus starten und auch laufen lassen bis der Akku wieder abgesteckt wird; Unilog bietet ja gefühlte zwei Dutzend Startmöglichkeiten. Die Logfiles würde ich 1.log, 2.log,... nennen. Alle in Text-Format, etwa 3..4x Einträge/Zeilen pro Sekunde, Werte durch Leerzeichen und/oder Komma getrennt.

3. Konfiguration: man könnte das Ganze über den USB-Port (serielle Schnittstellen-Emulation) konfigurieren, so wie beim klassischen RC Lab. Allerdings ist das hier wesentlich weniger wichtig. Die Raw-Daten können später ja immer noch nachverarbeitet werden (z.B. zur Umrechnung von us auf %, oder zur Rückberechnung auf die ungemischten Pitch/Roll/Nick Komponenten).

[Husi]

AW: Neues Projekt: RC-Lab

Hallo Gernot,

das hört sich doch erst einmal gut an. Ich finde es toll, das du auf den Zug aufspringst.

Du solltest bei deinen ßberlegungen einbeziehen, wie es für die meisten Anwender am praktikabelsten ist.
Für meinen Teil, würde ich nur eine Plus- und eine Minunsleitung vom Empfänger mit der Platine verbinden. Die zu loggenede Empfänger-Kanäle würde ich am Empfänger einfach "weiter oben" erneut ausgeben lassen. Mein Empfänger kann 16 Servos steuern, da darf man ruhig schon mal das z.B. Gas-Signal zwei mal an den Empfänger senden. Somit würde ich Kabel auf die Platine Löten, an dessen anderem Ende ein Servo-Stecker ist, in dem aber nur der Impuls-Pin mit einem Kabel versehen ist. Dieser Servostecker käme dann am Empfänger z.B. auf Kanal 13 gesteckt.

Was das starten des Logs angeht, bich ich ganz bei dir. Strom da, das Loggen beginnt. Später bei der Auswertung schneidet man eh nur die interessanten Stellen heraus.

Bei den Dateinamen bin ich von GPS-Logger von SM-Modellbau etwas verwöhnt. Dort gibt es das Datum und dann eine laufende Nummer. Aber füs Datum und die Uhrzeit, bräuchtest du wohl einen extra Real-Time-Chip, oder? Soo wichtig ist das jedoch nicht.
Was mir pers. da wichtiger wäre, die Logfrequnz zu erhöhen. Bisher habe ich (leider) auch nur 10 Datensätze / Sek.
Untersucht man jedoch den z.B. ßbergang vom Schweben zum Steigflug, so ist der kurze Moment des Pitchstoßes sehr interessant, aber selbst mit 10 Datensätzen / Sek noch recht ungenau.

RAW-Daten wären mir sogar am liebsten, weil ich eh die Daten über eine eigene Schnittstelle direkt ins AutoCAD lade und dort weiter verarbeite.

Als Konfigurations-Modi würde ich evtl. eine Möglichkeit sehen, die Daten wahlweise in einem binären Format loggen zu lassen, oder als default Einstellung im lesbaren klartext Text.
Binär hätte es den Vorteil, der schreibvorgang auf die Karte müßte viel weniger Bytes auf die Karte schreiben und Rundungsungenauigkeiten würde es dann auch nicht geben. Könnte dann die Logg-Frequenz gleich mit angehoben / eingestellt werden?

Viele Grüße
Mirko

[Cherry 2000]

AW: Neues Projekt: RC-Lab

So, hab den 7-Kanal-Logger nun am laufen. Anbei ein Snapshot der USB-Konfigurations-Schnittstelle. Die Befehle und der Syntax orientieren sich am normalen RC Lab.

Es gibt zur Zeit 3 Parameter. Mit dem Ersten lässt sich das Delay pro Messwert einstellen. Defaultmäßig steht er auf 1000 us = 1 ms, d.h. es wird jede Millisekunde ein Wert erfasst. Mit dem zweiten Parameter kann man dann die Zahl der gemittelten Samples und damit auch die Ausgabefrequenz festlegen. Ich hab mal 250 als Default vorgegeben, d.h. ein Log-Eintrag alle 250 ms (4x pro Sekunde). Wer das ändern will kann dies relativ einfach über diesen Parameter tun. Um beispielsweise 10x pro Sekunde zu loggen, sollte der zweite Parameter von 250 auf 100 verkleinert werden. Der dritte Parameter bestimmt die Logging-Art auf MicroSD-Karte. 0 heißt kein Logging, 1 heißt Logging als normales Text File (Default), 2 heißt raw/binary Logging (dann werden pro Eintrag jeweils 7 16-bit Integer nacheinander im RAW-Mode ins File geschrieben).

Interessant wäre noch ein Swash-Demix, damit man auf die ungemischten Pitch/Nick/Roll-Werte kommt. Dazu müsste man noch Konfig-Parameter für Neutralwert (Subtrim) und Polarität pro Kanal und einen Swash-Mix-Typ (z.B. 120°) hinzufügen. Dann würde man z.B. folgendes bekommen:

Pitch = 246 us
Nick = 13 us
Roll = -7 us

Denke, sowas ist sehr interessant. Man würde dann z.B. sehen, wieviel Nick ein FBL reinsteuern muss, um den Heli gerade zu halten (etwa bei falschem Schwerpunkt). Aber das kann man auch hinterher noch via Postprocessing berechnen .