Kommunikation zwischen Arduino und Flugcontroller

[Thomas E. (rc_flyer)]

Ich versuche gerade, Daten vom Arduino Uno über den Pixhawk an 
QGroundcontrol zu senden.
An Bord meines Flugzeugs habe ich zwei NTC-Sensoren und einen 
RPM-Sensor, um Temperatur und Geschwindigkeit (rpm) zu messen.
Ich denke, Mavlink ist der richtige Weg, um die Daten vom Arduino zu 
meinem Pixhawk und dann zu QGroundcontrol zu senden, oder was denkt ihr?

Dies ist mein Arduino-Code:

#include <Thermistor.h>
#include <NTC_Thermistor.h>
// wiring: https://funduino.de/nr-54-ntc-temperatursensor
const int Sensor_Pin1 = A0;
const int Sensor_Pin2 = A1;
const int signalPin = 2;

#define Referenzwiderstand   10000 // 
#define Nominalwiderstand     10000 // 
#define Nominaltemperatur    25 // 
#define BWert                3950 // 

Thermistor* thermistor1;
Thermistor* thermistor2;

volatile unsigned long startMicros = 0;
volatile bool firstEdgeDetected = false;

void setup() {
  Serial.begin(9600);
  
  pinMode(signalPin, INPUT);
  attachInterrupt(digitalPinToInterrupt(signalPin), handleInterrupt, RISING);
  
  thermistor1 = new NTC_Thermistor(Sensor_Pin1, Referenzwiderstand, Nominalwiderstand, Nominaltemperatur, BWert);
  thermistor2 = new NTC_Thermistor(Sensor_Pin2, Referenzwiderstand, Nominalwiderstand, Nominaltemperatur, BWert);
}

void loop() {
  double celsius1 = 0;
  double celsius2 = 0;

  for (int i = 0; i <= 999; i++) {
    celsius1 += thermistor1->readCelsius();
    celsius2 += thermistor2->readCelsius();
  }

  celsius1 /= 1000;
  celsius2 /= 1000;

  Serial.print("Temperatur1: ");
  Serial.print(celsius1);
  Serial.print(" °C");
  Serial.print(" Temperatur2: ");
  Serial.print(celsius2);
  Serial.println(" °C");

  delay(100);
}

void handleInterrupt() {
  if (!firstEdgeDetected) {
    startMicros = micros();
    firstEdgeDetected = true;
  } else {
    unsigned long endMicros = micros();
    firstEdgeDetected = false;
    
    unsigned long timeBetweenEdges = endMicros - startMicros;
    float frequency = 1000000.0 / timeBetweenEdges;
    Serial.print("Frequenz: ");
    Serial.print(frequency);
    Serial.println(" Hz");
  }
}

[Εrnst B. (ernst)]

Das "Serial.print" im "handleInterrupt" ist sehr ungünstig. Berechne da 
lieber nur deine "frequency", und mach die Ausgabe mit zu den anderen 
Ausgaben in der loop().


Dann könnte man noch in die Details gehen, z.B. startMicros und 
firstEdgeDetected müssen nicht volatile sein, könnten stattdessen 
"static" in's handleInterrupt.

Und du könntest, wie bei den Temperaturen auch, für die Frequenz einen 
durchschnitt über die letzten X Takte bilden.

[Thomas E. (rc_flyer)]

Εrnst B. schrieb:
> Das "Serial.print" im "handleInterrupt" ist sehr ungünstig. Berechne da
> lieber..

Vielen Dank für die Anmerkungen, ich werde das in meinem Code anpassen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Εrnst B. schrieb:
> Das "Serial.print" im "handleInterrupt" ist sehr ungünstig.
Weil erstens die Echtzeit kaputt gemacht wird und zudem die 
SIO-Übertragung aus der Mainloop durch den Interrupt unterbrochen werden 
kann.

> Berechne da lieber nur deine "frequency"
Schon die Float-Berechnung dürfte den sehr ins Stolpern bringen. Ich 
würde also nur die Differenz der beiden Zeitstempel wegspeichern und den 
Rest in der Mainloop berechnen.

In der Mainloop ist zudem noch ein Fehler, der sich *delay(100)* nennt. 
Aber dazu kommen wir später, wenn irgendwas zusätzlich "nebenher" 
gemacht werden muss.

[Thomas E. (rc_flyer)]

Lothar M. schrieb:
> *delay(100)*

Ja, die typische Arduino Problematik :D
Ich sehe ihr seid deutlich erfahrener als ich, mir ging es zunächst ein 
mal darum den Code zum laufen zu bringen, Daten zu generieren und alles 
in eine Mavlink Message zu packen, woran ich leider bisher scheitere

[Rainer W. (rawi)]

Εrnst B. schrieb:
> Berechne da lieber nur deine "frequency", und mach die Ausgabe mit zu
> den anderen Ausgaben in der loop().

Die Auswertung der Messdaten hat in der ISR nichts zu suchen. Da 
frequency sowieso nur für die Ausgabe benötigt wird, kann die genau dort 
unmittelbar vor der Ausgabe erfolgen.
Da du immer nur den Abstand zweier aufeinander folgender Pulse 
auswertet, kann es dir passieren, dass der Wert für die Drehzahl 
deutlich instabil ist - hängt davon ab, in welchem Drehzahlbereich du 
dich bewegst.
Stabiler wird der Wert, wenn du die Zeit für mehrere Umdrehungen 
auswertet. Häufiger, als du die Daten ablesen kannst, brauchst du 
sowieso keinen neuen Wert zu messen/übertragen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Thomas E. schrieb:
> mir ging es zunächst ein mal darum den Code zum laufen zu bringen
Das sollte man sich dann im Zuge der Weiterentwicklung aber auch im Kopf 
behalten. Und rechtzeitig vom urschleimigen "Ablaufprogrammieren" (= 
das, was weiter oben steht, wird zuerst ausgeführt) ins Programmieren 
mit Zustandsautomaten (= Programmteile werden abhängig von 
Systemzuständen ausgeführt) übergehen.

Beim zweiten Programmierstil ist kein delay() nötig (weil Zeiten über 
einen Zeitstempel verwaltet werden) und Funktionen können deshalb an 
jeder Stelle der Mainloop zum Programmablauf hinzugefügt werden. Die 
Mainloop (und alle ihre Unterprogramme) wird jedes Mal ohne jegliches 
Warten möglichst schnell durchlaufen. Im Idealfall einige tausend Mal 
pro Sekunde.