PWM In & Out

Gibt es einen Befehl mit welchem ich ein an einem Pin eingelesenes PWM Signal an einem Anderen Pin (nach bearbeitung) wieder ausgeben kann.

zum einlesen nehme ich

pinMode(pin_RX_Signal_Schub, INPUT);

RX_Signal_Schub = pulseIn(pin_RX_Signal_Schub, HIGH);

so erhalte ich das PWM signal vom reciver das klappt prima

aber wie gebe ich es wieder aus…?

Muss ich das mit “servo” realisieren oder geht das mit “pulseOut” oder so?

Mit pulseIn() misst du die Puls-Länge.

Die PWM Pins haben je nach Pin eine bestimmte Frequenz (die Timer0 Frequenz ist anders) und was du bei analogWrite() einstellst ist das Puls-Pausen-Verhältnis/Duty Cycle. Du müsstest dor also wenn ich das richtig sehe aus der Puls-Länge und der Frequenz (genau: aus Pulsdauer + Pausendauer) das Puls-Pausen Verhältnis ausrechnen.

...macht das nicht auch die "Servo" Lib ...?

Ja, wobei da bestimmte Zeiten eingehalten werden müssen:

Also wenn du einen Servo hast, dann die Servo Lib nehmen. Da ist dann die Umrechnung von Puls-Länge auf Servo Position einfach. write() will ein Zahl von 0-180:
https://www.arduino.cc/en/Reference/ServoWrite

Das sollte man dann mit map() machen können

ja , ich will das PWM Signal zum "Servo" verändern......

ich brauche ein PWM Signal von 1000-1800 ms an einem PWM Pin.

Die Limits stellst du bei attach() ein:
https://www.arduino.cc/en/Reference/ServoAttach

Dann nimmst du map() zum umrechnen des aktuellen Wertes:
https://www.arduino.cc/en/Reference/Map
Das liefert dann 0-180. Und daraus macht die Servo Lib wieder ein Signal innerhalb der Grenzen

Theoretisch...

...ahhhh,

ich denke der Groschen ist gefallen.

du meinst es so?

Servoraus = ((pwmeingang-1000)/4,4)

würde 0-180 ergeben ...

und somit einen 455-2400 ms Range am Ausgang...

....bis zu welchem Winkel kann ich den Servo ansprechen? 180Grad 222Grad oder 240Grad
Geht auch der PWM ausgang Pin5 am Nano für die Servo Lib?

ich bekomme nur sehr ungleiche PWM auf dem Ausgangspin so das der Fluglageregler das Signal falsch interpretiert.


extraschub = (RX_Signal_Schub/100*ausgleich); //% pro cm Unterschied i.d. Höhe

TX_Signal_Schub = RX_Signal_Schub + extraschub ; // Schubkorrektur durch extraschub
schubaus = map(TX_Signal_Schub, 1045, 1845, 0, 180); //legt den Bereich für Eingangswert und Ausgangswert fest

myservo.write(schubaus);


Normal sind 180°. Was praktisch geht musst du testen. Das hängt auch etwas vom Servo ab.

Und die Servo Lib hat nichts mit den PWM Pins zu tun (abgesehen davon dass die einen Timer belegt und dann auf dessen Pins kein PWM mehr geht)! Die schaltest die Pins selbst. Geht also überall.

Hura,

hab´s gefunden.
Wer lesen kann ist klar im Vorteil…

Also es gibt einen Befehl der das gegenteil von “pulseIn” macht …1

Mit “writeMicroseconds(Werte von 700-2300)” geht es perfekt.

hab das programmieren auf dem Ohio Scientific Challenger 1P gelernt, als es noch keine Lehrer dafür gab…da musste man sich auch in trockenen Stoff selbst einarbeiten.

trotzdem Danke Serenifly

Quelle: Arduino - ServoWriteMicroseconds

Ah. Eigentlich offensichtlich :slight_smile:

Da sieht man dass ich kaum was mit Servos mache

Sollte theoretisch aber auch durch den Umweg gehen, wenn die Rechnungen stimmen und durch das Umrechnen nicht irgendwie groß Informationen verloren gehen.

…stimmt,

mit Servos hab ich auch nicht viel am Hut.

ich bastel mit Koptern…und da wird das Signal für den Flight Controller “traditionell” von einem PPM Reciver via PWM bereitgestellt.

Das ganze ist(wird) ein Bodenverfolgungs-Sonar…

D.h. der Kopter fliegt immer in gleicher Höhe überm Boden?

Ja, ElEspanol.
Es soll den Boden , Büsche und Autos im "Auge" behalten....

Wenn ich meine Bug´s alle gefunden habe....

...hatte bis heute Morgen keinen vollständigen Überblick was "New_Ping" alles kann.(Nun Gefunden)

Ich hatte zu viele Fehlwerte vom US Modul bekommen.

Z.B. wird ein out of Range, also weiter als der voreingestellte Bereich, oder "kein Echo" wenn zu viele Bewegung im Spiel ist, einefach eine "Null" quasi kein "Abstand" ausgegeben. FATAL !!!! ...wenn man daraus das Schubmoment errechnen muss.

Da hilft auch keine Durchnittswertermittlung in Form von ping_median (Anzahl der Echos).

Weil auch da die "Null" auftauch wenn nur ein Echo der media "Serie" eine Null ergab! ...seltsam...?

Nullmessungen würde ich als z.B. 4m in den Running Median einspeisen. Weil wenn du am Boden bist, das weisst du ja selbst, und somit heisst eine Nullmessung im Flug "genügend Höhe" vorhanden. Und ausserhalb des Messbereichs vom US kannst du sowieso keine Höhenstabilisierung damit machen.

jep, an genau solchen Lösungen experimentiere ich grerade !!

Ich möche aber nicht zu viele Werte auf "Plausibilität" prüfen müssen...das kostet rechenzeit.
Ich versuche erst mal rauszufinden warum sooooooo viele fehler im Flug aber nicht im Labor auftauchen.

Die einzige Erklärung wäre das es zu einem zu starken Dopplerefekt kommt wenn der Kopter mit mehr als 27cm/sec fällt.

Dazu muss aber erst mal eine Telemetrie an den Sonarblock anlöten, sonst kann ich nicht in real- and runtime sehen woher manchmal (!!!) die Anhäufung von Fehlmessungen kommt.
Und weil ich das Programmieren auf dem Cellanger 1P gelernt habe .......ist es etwas "hackelig" mit den "neuen dialekten"

Hallo,
Das Abstandsmessen mit Ultraschallsensoren im Flug scheint nicht trivial zu sein.
Bei meinem RC-Flächenflieger zeigten im Datenlog die zum Boden gewandten Sensoren nur erratische Signale, wenn die beiden Motoren an waren (egal ob in Bodennähe oder in der Luft jenseits der Sensorreichweite), im Gleitflug in der Höhe wurde dann richtigerweise nix gemessen, da Bodenabstand > Reichweite.
Entweder sind es die Motorvibrationen die störten, oder Ultraschall der Luftschrauben.
Und bei mir waren die US-Wandler und die Propeller im 90° Winkel, das dürfte bei Deinem Quadrokopter anders sein, oder “gucken” die nach vorne ?

Das Verhalten der Sensoren im Gleitflug in Bodennähe werde ich irgendwann nochmal nachmessen, das ist bei mir aber natürlich nur sehr kurz.

Tütenflieger

Hallo Tütenflieger (was sind Fliegetüten?)

all deine Erfahrungen muste ich auch machen...leider !!

Die empfangenen Werte mit den Sensoren sind nicht zu gebrauchen.
Das liegt an der "Auswertsoftware" aus der Lib. Diese erkennt den Burst nicht wenn eine Freq. Abweichung wegen des Dopplerefektes auftritt.

bei sehr langsamen annäherungen (weniger 10cm sec !!) funktioniert es tadellos !!
Also hab ich vor, mir ein paar Radarsensoren zu beschaffen oder ein LIDAR ...gibt es schon ab 99$.

Danke für deine freundliche und umfangreiche "Anteilnahme" ...
LG