NAZA OSD für ca. 20$

Status
Nicht offen für weitere Antworten.
D

DerCamperHB

Erfahrener Benutzer
#81
#81
Ich meine das automatik Setzen selber hatte vor 3.12 noch keine Blinkreihenfolge, das manuelle Setzen schon, mehrmalige schnelle Grüne Blinken.
 
S

SmileyChris

Erfahrener Benutzer
#85
#85
also mein Lite bestätigt auch nicht das Setzen des Homepoints. Im GPS-Mode blinkt es anfangs 1xgrün und 3xrot. Wobei rot die Anzahl der Sats angibt. Erst wenn nur noch grün blinkt, sind die maximalen Satelliten erreicht und man kann starten. Der Homepoint wird nicht durch irgendeine Blinkfolge bestätigt.
 
JR63

JR63

Erfahrener Benutzer
#86
#86
SmileyChris hat gesagt.:
also mein Lite bestätigt auch nicht das Setzen des Homepoints. Im GPS-Mode blinkt es anfangs 1xgrün und 3xrot. Wobei rot die Anzahl der Sats angibt. Erst wenn nur noch grün blinkt, sind die maximalen Satelliten erreicht und man kann starten. Der Homepoint wird nicht durch irgendeine Blinkfolge bestätigt.
Zum Vergrößern anklicken....

ok, das grün wird aktuell als GPS interpretiert.

Hier die Zusammenfassung der Interpretationen:


Code: 
		gelb = 1 oder 2 und grün = 0			--> ATT
		grün = 1 oder 2 und gelb = 0			--> GPS
		gelb = 1 und grün = 1 oder 2			--> IOC
		gelb > 3					--> FS
Tschö
JR
 
M

muerzi

Erfahrener Benutzer
#87
#87
JR63 hat gesagt.:
Danke für den Hinweis.

Wenn das wirklich 'serial communication at 115200 baud' ist, werde ich mir das mal ansehen und evtl. in einer der nächsten Versionen umsetzen.

Tschö
JR
Zum Vergrößern anklicken....
Hi.

Ja das ist Serial 115200. auf Seite 5 ist auch ein Code um nen GPCCA Datensatz auszugeben für ein osd. Die daten sind aber nicht klartext sondern mit XOR "verwurschelt". Sieh dir einfach den Code an. Wenn du willst, unterstütz ich dich beim projekt
 
JR63

JR63

Erfahrener Benutzer
#88
#88
ja, interessant wäre, wie man an folgende Dinge herankommt, damit man den magnetischen Kompass vernünftig nutzen kann:

// add magnetic declination
// add tilt compensation

Ich denke mal, diese Korrekturwerte kennt nur die NAZA-FC durch die Kalibrierung und an diese Werte kommen wir somit nicht heran.

Daher berechne ich aktuell das Heading aus velN und velE.

Jetzt muss ich mal einen Adapter löten und meinen Testkopter auseinander nehmen....

Tschö
JR
 
M

muerzi

Erfahrener Benutzer
#89
#89
velN ist der vektor der geschwindigkeit in richtung Norden analog dazu velE der vektor richtung ost. Mit dem phytagoras kannst du nun die absolute geschwindigkeit über ground berechnen.
Wenn du daraus das heading berechnest gilt das nur wenn flugrichtung gleich ist wie die nase des copters zeigt.

Zum Kompass:
"I now do atan2 on the resulting x any y values, convert radians to degrees and bingo - a nice plot ranging from -180 to 180 (see "Heading" picture)." Alles kleiner 0 rechnest du einfach 360 - wert
Die declinaction sollte sich da nicht so große auswirkungen haben. Da wird dann ein fehler bei neigung des copters sein, aber vernlässlig klein, außer du machst ne tilt kompensation https://www.loveelectronics.co.uk/Tutorials/13/tilt-compensated-compass-arduino-tutorial
 
Zuletzt bearbeitet:
JR63

JR63

Erfahrener Benutzer
#90
#90
Hi,

das mit dem velN velE hatte ich auch schon umgesetzt:


Code: 
void parse_dji_gps(struct DJI_GPS *gps)
{
    int mask = gps->mask;
    
    GPSValues.Satellites    = gps->numSV;
    GPSValues.Latitude    = (float)decodeLong((byte*)&gps->lat, mask) / 10000000.0;
    GPSValues.Longitude    = (float)decodeLong((byte*)&gps->lon, mask) / 10000000.0;
    GPSValues.Altitude    = (float)decodeLong((byte*)&gps->hMSL, mask) * 0.001f;
    GPSValues.Down        = (float)decodeLong((byte*)&gps->velD, mask) / 100.0f;
    
    float velN = (float)decodeLong((byte*)&gps->velN, mask);
    float velE = (float)decodeLong((byte*)&gps->velE, mask);
    
    // calculate groundspeed
    GPSValues.Groundspeed    = sqrt(velN * velN + velE * velE);
    
#ifndef DJI_HEADING_FROM_MAG
    // calculate heading
    float heading = atan2(velE, velN) * 180.0 / M_PI;
    if (heading < 0.0) heading += 360.0;
    GPSValues.Heading    = heading;
#endif
}


void parse_dji_mag(struct DJI_MAG *mag)
{
#ifdef DJI_HEADING_FROM_MAG
    int mask = mag->mask;
    
    short x = decodeShort((byte*)&mag->magX, mask);
    x ^= 0x0100;
    
    short y = decodeShort((byte*)&mag->magY, mask);
    y ^= 0x0100;
    
    float heading = -atan2(y, x) * 180.0 / M_PI;
    if (heading < 0.0) heading += 360.0;
    
    // TODO add magnetic declination
    // TODO add tilt compensation
    
    GPSValues.Heading    = heading;
#endif
}

Ich habe, nachdem ich mir einen Adapter zusammengelötet habe, eben schon die ersten korrekten Koordinaten gesehen.

Noch ein paar Schönheitskorrekturen, dann wird das heute nacht noch committed.


Zum magnetischem Kompass:

Da könnte man mal den GPS berechneten und den vom mag testweise zusammen auf dem OSD darstellen und mal eine Weile flott genau in eine Richtung fliegen um zu sehen ob man die Korrekturen benötigt.


Aber auf jeden Fall extrem super, dass man nun nicht mehr im NAZA GPS löten muss!


Tschö
JR
 
M

muerzi

Erfahrener Benutzer
#91
#91
Die declinaction könnte auch per hand in den code eingegeben werden. So riesen unterschiede sind da selbst im 100km radius
nicht.

Freu mich schon weiters von dir zu lesen!
Weiter so!
 
M

muerzi

Erfahrener Benutzer
#92
#92
Das mit dem flugmodus hab ich aber noch nicht verstanden.
Meine annahme: die naza gibt auf 3pins jeweils die farbwerte für rot gelb grün (nicht blau) aus die du dann einliest? Stimmt das so?

Muss mich morgen mal mit deinem code eingehender beschäftigen, hab den nur grob überflogen...

Wir könnten ja das osd config tool umbauen um zb die magn. Declination und die defines anzupassen auf basis einer eeprom config im atmega
 
Zuletzt bearbeitet:
JR63

JR63

Erfahrener Benutzer
#93
#93
muerzi hat gesagt.:
Das mit dem flugmodus hab ich aber noch nicht verstanden.
Meine annahme: die naza gibt auf 3pins jeweils die farbwerte für rot gelb blau aus die du dann einliest? Stimmt das so?

Muss mich morgen mal mit deinem code eingehender beschäftigen, hab den nur grob überflogen...

Wir könnten ja das osd config tool umbauen um zb die magn. Declination und die defines anzupassen auf basis einer eeprom config im atmega
Zum Vergrößern anklicken....


Die NAZA steuert über 2 Leitungen nur die rote und die grüne LED in der RGB LED an. Die Farbe orange wir additiv gemischt, indem einfach die rote und die grüne LED eingeschaltet werden.

Daher benötige ich nur 3 Widerstände, je einer pro Leitung und einer gegen Masse (wie in dem Diagramm im Wiki gezeichnet)

Eine Leitung wird dann auf einen ADC gegeben und ich finde dann 4 Spannungen:

Spannung 1 für aus
Spannung 2 für rot
Spannung 3 für grün
Spannung 4 für orange


Die Spannungen ergeben sich aus dem Verhältnis der Widerstände.



Jau, das Configtool könnte man mal entsprechend erweitern, wäre cool wenn Du das übernehmen wolltest.

Tschö
JR
 
D

DerCamperHB

Erfahrener Benutzer
#94
#94
Hätte ne Frage dazu
Wärt ihr bereit, aus den Erkenntnissen auch einen Code zu erstellen, für eine 2 geteilte Lösung wie dem FBOSD, wenn man alle Informationen so langsam zusammen hat, könnte man daraus ein Super OSD erstellen, die 1 Platinen Minim Version hat zwar Platzvorteile, durch die kleinen Lötkontakte aber auch Physikalisch Nachteile
durch die Geteilte Version ist es einfach Möglich das ganze Stabiler zu bauen.
Beim FBOSD stört mich aktuell, das es nicht im Standard 45/45 Maß gefertigt ist, was aber wohl machbar sein sollte.
In der aktuellen Informationsversion hätte es den Vorteil, man könnte dann gleich die entsprechenden Steckplätze verplanen, mit dem GPS und dem LED hätte man z.B. schon die Dateneingabe, Spannungsversorgung, Statusmeldung übergeben.
So könnte man zudem z.B. noch den 330Ohm Umbau für LEDV2 an V1 Extern vorsehen, und hätte das ganze ohne Garantieverlust
Wenn man dann noch Ergründet, wie die Spannungsüberwachung beim Naza geht, also ob das nur ein Spannungsteiler ist, der an X3 geht, könnte man den sogar nutzen
 
JR63

JR63

Erfahrener Benutzer
#95
#95
Hi,

klar, gar kein Problem, mein Code ist ja schon seit dem 24.09.2013 öffentlich zugänglich.

Schau mal hier:

http://code.google.com/p/minnazaosd/source/browse/#svn/trunk/minNAZAOSD


Aber besser über folgenden Link einfach per svn auschecken:

http://code.google.com/p/minnazaosd/source/checkout


Heute nacht kommt dann noch die Erweiterung für das GPS Auslesen ohne Löten am GPS Puck.


In einem anderen Thread hier in der FPV-C hat doch jemand mal super beschrieben wie man ein Hardware Layout einfach selber erstellen und dann herstellen lassen kann.

Das wäre doch mal was: Alle Erkenntnisse zu einen coolen OSD zusammen führen. Das geht mir schon seit ein paar Tagen durch den Kopf.

Tschö
JR
 
D

DerCamperHB

Erfahrener Benutzer
#96
#96
da greifst du ja auf Minim zu, meinte eben wie beim FBosd ein Arduino als Sammelbox, und dann die Daten an den Minim weiter reichen, um eben nicht so feine Lötverbindungen in einem Copter nutzen zu müssen
 
TTRCmedia

TTRCmedia

Erfahrener Benutzer
#97
#97
Neues OSD auf Basis der Technik des minimOSD konstruieren? Nur zu:

minimal_osd_v05.png

...und wenn was ohne SMD-Bauteile dabei rauskommt und eine Bezugsquelle für den MAX7456 baue ich auch ;)
 
JR63

JR63

Erfahrener Benutzer
#99
#99
DerCamperHB hat gesagt.:
da greifst du ja auf Minim zu, meinte eben wie beim FBosd ein Arduino als Sammelbox, und dann die Daten an den Minim weiter reichen, um eben nicht so feine Lötverbindungen in einem Copter nutzen zu müssen
Zum Vergrößern anklicken....
Klar, kann man auch machen, dann muss man die geparsten Daten in MavLink verpacken und gut ist.

Dann würde man aber die Lösung von FBOSD nochmal nachbauen.

Daher, wenn schon eine neue Platine im neuen Formfaktor, dann gleich ganz neu... wie im Post von TTRCmedia...schreibe ich gleich noch was dazu...
 
Zuletzt bearbeitet:
JR63

JR63

Erfahrener Benutzer
#100
#100
TTRCmedia hat gesagt.:
Neues OSD auf Basis der Technik des minimOSD konstruieren? Nur zu:

Anhang anzeigen 72010

...und wenn was ohne SMD-Bauteile dabei rauskommt und eine Bezugsquelle für den MAX7456 baue ich auch ;)
Zum Vergrößern anklicken....

cool, genau so.

Und dann noch gleich ein MicroSD Card slot vorsehen und Log daten füttern.

Wenn jemand die Hardware übernimmt, könnte ich das Coden übernehmen...


Jo, SMD ist nicht ganz so easy....
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten