iNav + Matek F405-CTR - Anfängerfragen

[Bunbury]

Vorab: ich habe noch garkeine Erfahrung mit FCs, weder mit der Hardware, noch mit den Firmwares! Aber bevor ihr gleich abschaltet und das als Anfängerprojekt für aussichtslos erklärt: ich bin Elektronik-Ing. und fummle mich üblichweise auch in komplexere Sachverhalte schon irgendwie ein.

Was ich vor habe: einen Quad ohne GPS oder Compass, aber mit auto leveling (zunächst) per Baro und idealerweise (später) per Sonar

Motore, Props, ESCs Funke samt Receiver usw. ist vorhanden. Da ich die in vielen DIY-Projekten mit dem Stichwort "Sonar" verwendeten Naze-FCs nicht (mehr) im Handel gefunden habe (bzw. nicht bei Quellen die mir gefielen) habe ich in anderen Foren nachgefragt, wo man meinte daß ich mit iNAV evtl. die besten Chancen hätte. Nach iNav-Kompatibilitätsliste habe ich mir dann erstmal die F405 geordert, als -CTR um mir gleich einen separten BEC usw. zu sparen.

Das Ding nach Schema-F zu verkabeln traue ich mir nach den im Netz verfügbaren Infos zu, genauso iNav draufzuspielen und den Baro zu aktivieren. Da ich meinen alten (ziemlich kleinen) DEVO-RX710-Receiver recyclen will brauche ich aber vorab eh eine kleine Adapterplatine um das (wirklich widerwärtige) 0,5mm-pitch FPC-Kabel anzuschließen und erstmal in PPM umzuwandeln. Wenn ich aber schon eine eigene Platine layoute würde ich für später gerne gleich passende Anschlüsse für ein/mehrere Sonar-Module vorbereiten bzw. nach außen legen ohne als Anfänger gleich noch irgendwas abweichend vom iNav-Standard modden zu müssen.

Leider enden da die Infos, die ich selbst im Netz gefunden habe und wo Ihr mir mit Tipps bzw. Links auf andere Seiten wirklich weiterhelfen könntet. Ausgehend von einer fertig verkabelten F405:

- Ist iNav für mein Vorhaben (auto altitude ohne GPS) überhaupt tatsächlich die geeignete Firmware?

- Wie kriegt man prinzipiell zusätzliche Signale vom Sonar in die FC, so daß sie für iNav verständlich sind?
Üblicherweise liefern Sonarmodule per Trigger einen Laufzeit-proportionalen TTL-Echo-Impuls, kann iNav damit direkt was anfangen oder soll ich das mit einem kleinen µC vorher in irgendein anderes Signalfromat umwandeln? (Uart, I²C, analog, PPM oder PWM, invertieren o.ä.)

- An welche Eingänge der (ansonsten nach Standard verkabelten) F405 schließe ich die idealerweise an?

Wie gesagt, mit der iNav-Installation und -Konfiguration würde ich mich gerne erst beschäftigen, wenn ich die Platine beauftragt habe, da die schonmal 2-3 Wochen braucht, bis sie hier ist. Außerdem kann ich dann erst meinen Receiver anschließen und will nicht erst am Ende feststellen, daß mir noch irgendwas fehlt und ich doch noch irgendein externes Modul brauche.

Vielen Dank für Eure Hilfe schonmal vorab!

 

[Bunbury]

Da kommt mir gerade noch eine Idee:
Da ich mir das PPM-Signal ja eh selbst generiere und die Funke nur 7 Kanäle hat könnte ich natürlich auch die Höheninfo vom Sonar selbst als CH8 einfach direkt ans Receiversignal hinten anhängen. Dann könnte ich die Mix-/Regelfunktion im FC benutzen, könnte aber bei mehreren Sensoren selbst dafür sorgen, daß z.B. immer (nur) das Sonar-Signal mit dem geringsten Bodenabstand verwendet wird. Und ich könnte das auch rel einfach asymmetrisch einspeisen, da bei geringer Flughöhe -1m Höhe sehr viel kritischer ist als +1m

Aber eigentlich müßte ich das PWM-Signal vom Receiver garnicht decodieren um es in PPM umzuwandeln und falls iNav bzw. der FC das einfacher ermöglicht kann ich mir den Aufwand sparen.

 

[fchansa]

Imho verwendet man statt Sonar heute eher LIDAR (bitte verbessert mich falls ich mich irre?)
Sprich FC mit Baro + LIDAR für den Nahbereich.
Anschluss per freiem UART - und iNav macht.
Matek LIDAR hätte ich sogar liegen - bei Bedarf PN.

 

[fchansa]

http://www.mateksys.com/downloads/setup_optic flow_in_INAV_rev1.pdf

 

[Bunbury]

Hmmm... mir soll alles recht sein, was erprobt und einfach zu implementieren ist!
Bei optical flow sensoren hätte ich gedacht, daß das für XY und Gieren eine super Sache ist, für die Z-Achse aber deutlich unempfindlicher und sensibel gegenüber Winkelfehlern durch Nicken/Rollen.

Ich suche erstmal nach Videos und gucke mir das an, sofern ich was finde. Sollte das Ok sein kürze ich ab und mache das so. Danke für den Tipp, melde mich dann ggF.
Schafft es denn so ein System eigentlich allein (ohne GPS) die Position über Grund zu stabilisieren?

Edit: Ja, es kann und die Abstandsmessung läuft gar nicht über Optical Flow sondern einen separaten IR-Laserabstandssensor, was 1. meine Befürchtungen entkräftet und mir 2. schon auf Grund meines Berufes lieber ist als Schall. In Videos sieht es auch so aus, als ob der LIDAR-Sensor vernünftig mit diffusen Oberflächen wie Gras usw. klar käme, jedenfalls nicht schlechter als USchall.
Super dokumentiert ist die Implementierung auch, so daß ich Euch hier garnicht viel nerven muß...
So mache ich das!
Danke für den Tipp!