Multiwii 2.3 - altHold + Sonar

#1
Moin...

Da ich mich schon lange nicht mehr mit Multiwii beschäftigt habe, wollte ich mal die neue Version testen. Ich hab dann mal in meiner Wühlkiste gekramt und noch n HC-SR04 und ein I2C-GPS-Adapterboard incl. MTK-GPS gefunden.
Das I2C-GPS lief auf anhieb. Nun musste ich noch das Sonar ans rennen kriegen. Also an Pin A2, A3 (Echo, Trigger) noch Lackdraht dran & fertig. Nachdem ich die I2C-GPS & Multiwii Config.h angepasst hatte wurde mir auch in der GUI angezeigt das er ein Sonar gefunden hat.
Man kann auch höhren, daß das Sonar triggert.

So... Jetzt meine Fragen:

Wie finde ich raus on das Sonar auch funktioniert?
Kann ich mir in der GUI die Sonarwerte anzeigen lassen?
Ist das Sonar immer aktiv?

Wenn ich den Kopter auf AltHold schalte hält er so ungefähr die Höhe (10-20cm).
Bekomme ich das noch besser hin (so wie bei Megapirates)?

Technische Daten des Kopters:
QuadX, 10DOF GY-86 (MPU6050, HMC5883L, MS5611), I2C-GPS incl. Sonar, Atmel 328

Danke

Nenno
 
Zuletzt bearbeitet:

Jörn

Erfahrener Benutzer
#2
Habe auch noch so ein HK Sonar rumliegen. Wäre auch daran interessiert, ob das mit MW 2.3 wirklich unterstützt wird.
 
#4
Moin nochmal...

... scheinbar werden die Sonarwerte nur angezeigt und haben keinen einfluss auf altHold.

q: sorry for the noob question, but does this means that I can use a src04 sonar for low altitude accuracy?
a: no, currently, it's only for a more accurate altitude display
Das einzige wofür man das Sonar wohl benutzen kann sind die Landinglights:

Code:
/*******************************    Landing lights    *********************************/
  /* Landing lights
     Use an output pin to control landing lights.
     They can be switched automatically when used in conjunction
     with altitude data from a sonar unit. */
    //#define LANDING_LIGHTS_DDR DDRC
    //#define LANDING_LIGHTS_PORT PORTC
    //#define LANDING_LIGHTS_BIT PORTC0
    //#define LANDING_LIGHTS_INVERT

    /* altitude above ground (in cm) as reported by sonar */
    //#define LANDING_LIGHTS_AUTO_ALTITUDE 50

    /* adopt the flasher pattern for landing light LEDs */
    //#define LANDING_LIGHTS_ADOPT_LED_FLASHER_PATTERN
Nenno
 
Zuletzt bearbeitet:

Roberto

Erfahrener Benutzer
#5
Ja, am Sonar macht mwii jetzt schon 2 Jahre herum. Eigentlich ist das an einem Wochenende erledigt, wenn man weiss, was man will, und realisiert was das Sonar kann und was eben nicht. Ein Sonar kann immer nur einen RELATIVEN Abstand messen und NIEMALS eine absolute Höhe i.S von MSL(mean sea level kann das GPS und das aktuell mit ungefähr +-10m Ungenauigkeit, und der Baro) - d.h. ein Ansatz wie Arducopter, Mahowik u.a muss in der Grundannahme schon mal falsch sein (ABSOLUTE Höhe) - und werden deshalb auch gefährlich im Flug. Ein Sonarkontakt kann man daher nicht immer dem Bodenkontakt gleich setzen (Baum/Berg/ Stein-Terassenboden/ Landewiese). Deswegen sind viele open source Sonarcodes an der Sensor-Realität vorbei und auch noch gefährlich.

Was kann ein Sonar?
- Den relativen Abstand zu einem Hindernis messen, sofern es Schall reflektiert (Grass/Stein)
- Schallgeschwindigkeit/Temp Abhängigkeit: Temperaturunterschiede sind mathematisch zu vernachlässigen (es sei denn, man fliegt in Regionen, wo +35C und -10C sich abwechseln - z.B Kühlhaus und Gewächshaus im Wechsel - das Flugfeld möchte ich gerne sehen) Bemerkung: Für die barometrische Höhenmessung ist die Lufttemp dagegen sehr wichtig.
Vergleich:
+35 C 102 CM
+20 C 100 CM
-10 C 95 CM
d.h. 45 Grad Unterschied machen 7 cm (auf einen Meter) beim Sonar aus - schönen Gruss an Armazilla(github), wo dieser Unterschied - THEORETISCH - berücksichtigt ist - der Rest des Codes ist unbrauchbar und bestenfalls eine billige "Harakiri "Kopie.
- Das Sonar kann kurz den "Kontakt" verlieren (z.B billiger Sensoren wie das HC SR04)
- Das Sonar hat nur einen eingeschränken, verwertbaren Messbereich, der i.d.R die HÄLFTE des beworbenen maximal range beträgt.
- Je nach dem wo das Sonar montiert ist, kann es durch Verkippung des Fluggerätes (Copter?) zu einer künstlichen Veränderung des gemessenen (sonar)Abststandes kommen. Das ist in verschiedenen open source codes überschätzt und mit cos Funtionen bedient. In Realität macht die Verkippung KAUM einen Unterschied zwischen Sonar gemessenem Abstand und tatsächlichem Abstand.

Was soll eine Sonar können?
- Nicht das Braometer ersetzen - denn das kann es NIEMALS, weil es eben nur einen relativen Abstand messen kann. Nur das Baro kann die absolute Höhe messen (GPS zu ungenau). Ein Sonar kann NIEMALS (never ever) ein Barometer ersetzen.
- Abstand zu einem Hindernis "halten"
- Keine Hüpfer über Bäume produzieren
- Ungefährlich die ganze Zeit mitlaufen und den Baro unterstützen.

Was soll der Sonar Code daher können?
- Einen RELATIVEN Abstand halten können.
- d.h. z.B Bei Dachinspektionen immer einen konstanten Abstand zum Dach beibehalten.

Wie soll der Sonar/Baro/ACC Code daher aussehen?
- Ein Sonar only Code ist absoluter Schwachsinn (s.o), weil ein Sonar immer nur einer relative, niemals eine absolute Höhe bestimmen kann (im Rahmen seines "Ranges").
- Fehler müssen gebrückt werden - auch ein Disconnect muss erkannt werden.
- Die RELATIVE Höhenänderung des Sonars muss berücksichtigt werden (v.a das billige SR04 - Maxbotix 1200 und höher sind deutlich besser)
- Daher MUSS ein OFFSET zwischen gemessener Barohöhe und der relativen Sonar Höhe (bei Kontakt) gebildet werden.
-> daher sind alle opensource codes, die ich bis jetzt gesehen habe, WENIG sinnvoll....... um es nach meiner Auffassung positiv zu sagen...

Ergebnis?
- Wenn ein vertrauenswürdiger (Definition!) Sonar Kontakt vorliegt, wird die gemeldete, RELATIVE Höhenänderung durch das Sonar mit der ABSOLUTHÖHE des Baro verarbeitet und umgesetzt.
- Kein "hüpfen" über Bäume etc...


Das wollte ich mir mal von der Seele schreiben. Der Sonar Unfug mit absoluten Höhen (ab 4 m mache das blabla etc) ging mir dermassen gegen den Strich, dass ich mir hier mal Luft machen musste (sorry for that). Für (hoffentlich bald preiswert zu kaufende) Radar Sensoren gilt das gleiche: RELATIVE Höhe wird gemessen, niemals die absolute Höhe...
Diesen Unterschied muss man sich immer klar machen, wenn man Anfordeungen an das Sonar stellt.
P.s: Für Autostart und Autolandung ist das SONAR NIEMALS entscheidend !! Das geht auch "nur" mit dem Baro, wenn der Code entsprechend ist....


LG
Rob
 
Zuletzt bearbeitet:

Zuse

Erfahrener Benutzer
#6
hervorragende Zusammenfassung und Erläuterung!
Besten Dank!

Manfred
 

konus123

Erfahrener Benutzer
#8
diese Behauptung ist falsch !
in der Standard 2.3 ist das i2c-gps sehr wohl enthalten. nur in der waypoint-variante der 2.3 ist das rausgenommen, bzw nicht komplett implementiert worden, da diese Version hauptsächlich auf die mega-boards abzielt und da das gps seriell angeschlossen wird.

aus der MultiWi2_3-navi-b5-baro_fix

"//**!*!*!*!*!*!*!*!*!*!* I2C GPS code is NOT finished in this version, please DON'T USE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! "


das sonar ist seit einiger zeit drin, wird aber im sketch mit " no controllcode behind" angegeben. also einkommmentieren kann manns aber hat keine Wirkung auf die Steuerung.

/* Sonar */ // for visualization purpose currently - no control code behind


Alex
 
Zuletzt bearbeitet:
#9
in der Standard 2.3 ist das i2c-gps sehr wohl enthalten. nur in der waypoint-variante der 2.3 ist das rausgenommen, bzw nicht komplett implementiert worden
Danke für die Antwort, dann habe ich das falsch verstanden.
Der zugrundeliegende Thread im MultiWii Forum bezog sich auf GPS allgemein, die Entwickler sprachen explizit von den waypoint Funktionen, das ist richtig.
Das hieße dann, dass ich eine Koptersteuerung mit einem Arduino pro micro, ergänzt um 10DOF und ublox, aufbauen und aktueller 2.3 Version beladen kann und GPS Home nutzbar ist?
 

konus123

Erfahrener Benutzer
#10
nein.
ich zitiere mich hier mal selbst....

in der Standard 2.3 ist das i2c-gps sehr wohl enthalten. nur in der waypoint-variante der 2.3 ist das rausgenommen, bzw nicht komplett implementiert worden, da diese Version hauptsächlich auf die mega-boards abzielt und da das gps seriell angeschlossen wird.

aus der MultiWi2_3-navi-b5-baro_fix

"//**!*!*!*!*!*!*!*!*!*!* I2C GPS code is NOT finished in this version, please DON'T USE !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! "
die funktionen des i2c-gps funktionieren so gut wie nicht. habs selbst kurz probiert und aufgegeben. hier im board wurde auch schon des Öfteren darüber geschrieben, hab noch nix gelesen, dass das mit der i2c Version sauber gelaufen ist.
 
Zuletzt bearbeitet:
FPV1

Banggood

Oben Unten