iNav

iDaniel

Erfahrener Benutzer
Hi,
hat von euch wer den "betaflight raceflight banggood f4" ? ich hab den heute versucht mit inav zu flashen, nach dem flashvorgang kann ich leider keinen serial port öffnen bzw nicht mit der gui verbinden. Von haus aus war betaflight drauf und das lies sich auch problemlos auf die aktuellste version flashen. Wird dieses board nicht von inav unterstützt? unter betaflight funktioniert es mit dem Target REVO.
 

iDaniel

Erfahrener Benutzer
mit was verbunden? FTDI oder USB?
über USB

Hast Du den iNAV Configurator 1.6 als GUI benutzt?
Ja genau den aktuellen als Chrome app

Versuche mal ihn neu zu flashen, das Board wird vermutlich direkt im DFU Modus booten. Dafür lese mal diese Anleitung

https://github.com/CarlosGS/inav/blob/master/docs/USB Flashing.md
Werd ich mal befolgen danke :)
 

Sibi

Erfahrener Benutzer
kenn ich... bei mir brauchte ich noch zusätzlich 5V vom FTDI order RC RX damit der USB starten wollte... probier das mal, ansonsten geht FTDI auf jeden Fall
 

olex

Der Testpilot
Hat hier schon jemand INAV auf einem Board mit vollintegriertem OSD (MAX7456 per SPI, kein "eingebackenes" MinimOSD mit separater Firmware) betrieben? Habe mein Betaflight (Omnibus) F3 mit BN-800 GPS heute in Betrieb genommen, und soweit sehr zufrieden, außer in einer Sache: der Home-Pfeil im OSD zeigt in eine definitiv falsche Richtung.

Copter sieht wie folgt aus (für die heutigen Testflüge blieb die Xiaomi runter, das GPS war also frei von Abschattungen):

2017-02-25 22.14.31.jpg

Kurze Hardwareliste:

- Martian III 250mm Frame
- Gemfan RT2205-2300kv, Racerstar RS 35A v2, HQ6045
- Omnibus F3 AIO v1.1 (BG Link), BN-800 GPS + Kompass (BG Link)
- HS1177, Unify Pro HV, X4R-SB

Firmware: INAV 1.6.0 RC2

Fliegen tut er einwandfrei - Acro bedarf noch etwas Arbeit, aber alle stabilisierten Modi (Level, Level+Althold, Level+Althold+Poshold, RTH) gehen sehr gut. Der Kompass an sich stimmt definitiv: das Heading wird im OSD korrekt angezeigt, in Poshold steht er sauber da und lässt sich auch 360° auf der Stelle drehen ohne Drift, und in RTH dreht er sich völlig korrekt zum Homepoint hin und fliegt ihn sauber an.

Der Home-Pfeil im OSD verhält sich aber sehr merkwürdig - da scheint irgendwo eine Achsinvertierung vorzuliegen, denn er rotiert immer in dieselbe Richtung wie der Copter yawt (sollte ja eigentlich entgegengesetzt sein), und zeigt damit meistens irgendwohin nur nicht nach Hause. Ich vermute dass der OSD Code die ganzen IMU- und Kompass-Verdrehungen, die eingestellt sind (180° Yaw für Board-Einbaurichtung und CW-270°+Flip für Kompassausrichtung), nicht korrekt mit berücksichtigt. Gibt es da irgendwelche Parameter oder Optionen die ich vllt übersehen habe, oder ist das tatsächlich eher ein Bug?
 
Schickes Ding!
Soweit ich weiß ist das ingegrierte OSD erst kürzlich von Betaflight übernommen worden, kann schon sein das das noch nicht komplett tut. Gerade die GPS Geschichten sind bei INAV ja schon deutlich anders.

Ach ja, habe jetzt INAV auf dem PIKO F3 Board am laufen, musste den Code etwas anpassen um alle Features zu bekommen die ich wollte:
- PPM RX (D4R-II to save the serials for other stuff)
- FrSky Telemetry on Serial1
- MW_OSD on Serial2
- Naza GPS/MAG on Serial3 (Satellite plug)
- Baro via I2C on Pins PA9/PA10 directly on the processor
- 2 Servos on Motor 5/6 Pads.

Kann der nächste kleine Kopter kommen...
 
Ja, PPM RX geht per default, beim PIKO muss man eben die Lötbrücke auf SBUS oder PPM setzten.
Hab den nur dazu geschrieben da ich bei dem Projekt extra den "alten" D4R-II mit PPM nutze um keine Serielle zu belegen.
Brauche alle 3 für andere Zwecke. Bei Serial 3 ist nur der RX Pin rausgeführt, da hier normalerweise der Spektrum Satellit ran kommt. Bei Nutzung des Naza GPS reicht das aus, da dieses nicht von INAV konfiguriert wird beim booten.
 

olex

Der Testpilot
Soweit ich weiß ist das ingegrierte OSD erst kürzlich von Betaflight übernommen worden, kann schon sein das das noch nicht komplett tut. Gerade die GPS Geschichten sind bei INAV ja schon deutlich anders.
Das tut schon ziemlich gut, bis auf den Homepfeil eben :)

DigitalEntity (Hauptentwickler von INAV) hat sich auf meine Anfrage bei RCG gemeldet. Laut ihm ist das Problem der OSD-Font, und er hat auch eine korrigierte Version bereitgestellt die das Problem lösen soll: https://www.rcgroups.com/forums/showpost.php?p=36977623&postcount=11678. Mit etwas Glück komme ich heute früh genug nach Hause um noch eine halbe Stunde Testflug bei letztem Sonnenlicht hinzubekommen, dann kann ich sagen ob's geholfen hat.
 
Ja, mit den Fonts ist immer so ne Sache beim OSD. Gerade weil die Pfeile da als extra Zeichen definiert sind und nur über die Position im Zeichensatz angesprochen werden. Beim falschen Zeichensatz kommen dann eben falsche Zeichen, in deinem Fall halt der falsch zeigende Pfeil.
 

olex

Der Testpilot
Testflug erfolgreich. Der neue Font von DigitalEntity hat das Problem tatsächlich gelöst, der Pfeil ist im Vergleich zu den "standard" Fonts ausm INAV-Configurator invertiert und zeigt jetzt in die richtige Richtung :)

Außerdem, falls jemand außer mir ein Problem mit dem Acro-Verhalten hat: Hardware-LPF vom Gyro ausschalten (auf 256Hz stellen, dann ist er afaik komplett aus), und die Notch-Filter-Werte aus Betaflight kopieren! Ich habe noch zusätzlich den Async-Modus aktiviert, Gyro auf 4kHz, und Looptime und ESCs beides auf 2kHz gestellt. Alternativ kann man einfach den 5" Racer-Preset im Configurator nehmen, der stellt das genau so ein, und nimmt dazu für 5" passende Default-PIDs. Für meinen etwas übermotorisierten 6"-2300kv-4S Setup musste ich die etwas runternehmen - damit fliegt er in Acro effektiv wie Betaflight, sprich nahezu perfekt.

AltHold und GPS Tests habe ich heute bei gefühltem 60km/h Dauerwind gelassen, wobei ich nicht davon ausgehe dass sich an dem Verhalten etwas verschlechtern sollte. Wenn dann im Gegenteil, der ACC sollte jetzt ohne Regelungsschwingungen deutlich sauberere Daten liefern, wodurch beides die Positions- und Höhenbestimmung besser laufen sollte.
 
Zuletzt bearbeitet:

Elyot

Erfahrener Benutzer
Frage an die Profis: Lassen sich die Servos ummappen? Für einen Tricopter würde ich gern den FRSky XSRF3E verwenden. Der hat eine SP Racing F3 drauf, aber nur PWM 1-6 rausgeführt. Beim Tri sitzt das Servo aber normalerweise auf PWM 7.
 
Ich vermute das wird nur gehen in dem du den Code anpasst und selbst kompilierst.
Habe das fürs PIKO Board gemacht um 2 Servos auf Motor 5 und 6 zu legen.
Müsste vermutlich dann so ausschauen:
Code:
const uint16_t multiPPM[] = {
    PWM1  | (MAP_TO_PPM_INPUT    << 8),  // PPM input

    PWM9  | (MAP_TO_MOTOR_OUTPUT << 8),
    PWM10 | (MAP_TO_MOTOR_OUTPUT << 8),
    PWM11 | (MAP_TO_MOTOR_OUTPUT << 8),
    PWM12 | (MAP_TO_MOTOR_OUTPUT << 8),
    PWM13 | (MAP_TO_SERVO_OUTPUT << 8),
    PWM14 | (MAP_TO_SERVO_OUTPUT << 8),
    PWM15 | (MAP_TO_MOTOR_OUTPUT << 8),
    PWM16 | (MAP_TO_MOTOR_OUTPUT << 8),
    PWM5  | (MAP_TO_MOTOR_OUTPUT << 8),  // Swap to servo if needed
    PWM6  | (MAP_TO_MOTOR_OUTPUT << 8),  // Swap to servo if needed
    PWM7  | (MAP_TO_MOTOR_OUTPUT << 8),  // Swap to servo if needed
    PWM8  | (MAP_TO_MOTOR_OUTPUT << 8),  // Swap to servo if needed
    0xFFFF
};
https://github.com/iNavFlight/inav/blob/master/src/main/target/SPRACINGF3/target.c
 

olex

Der Testpilot
FPV1

Banggood

Oben Unten