Bixler2 mit MultiWii-Autopilot & RTH

Chriss_:)

Erfahrener Benutzer
#61
Hi Rangarid,

wow, das sieht ja klasse aus! :) Schön kompakt! Bin mal auf die Empfangseigenschaften gespannt! ;)

Schöne Grüße aus dem Sauerland!
Chriss
 

Teddytimo

Erfahrener Benutzer
#62
Als nächstes folgen die Anpassungen für das Nav-Board. Die Datei ist hier zu finden: "V:\MultiWii\Firmware\MultiWii_AP_RTH\140204\I2C_GPS_Pactched\I2C_GPS_v2_2\config.h"

Z11 => "#define FIXEDWING" aktivieren!
Z14 => "#define GPS_SERIAL_SPEED 115200" Baudrate einstellen (wenn ihr später die "u-blox-config.ublox.txt" nutzt, 115200 eingeben).
Z28 => "#define UBLOX" aktivieren!
Z41 => "//#define SONAR" deaktivieren!
Hallo Chriss,

ich würde gern dein Projekt mit einer CRIUS_AIO_PRO_V1 FC machen und mein u-Blox CN-06 GPS seriell anschliessen.
Geht das?

Teddytimo
 

Chriss_:)

Erfahrener Benutzer
#63
Hi Teddytimo,

japp, das würde auch gehen! Dazu brauchst du den ganzen Code für das i2c-Nav-Board nicht. Einfach in der MultiWii-Config GPS aktivieren! ;)

Schöne Grüße aus dem Sauerland!
Chriss
 

Rangarid

Erfahrener Benutzer
#64
Wenn du das AIO Pro hast würde ich dir ArduplaneNG empfehlen, das ist von der Entwicklung her viel erprobter, viel mehr getestet usw. Das Multiwii RTH lohnt sich ja nur mit den kleinen Boards auf denen ein Atmega328 drauf ist.

Ansonsten musst du folgendes einstellen

Hier den Port eintragen wo das GPS drankommt
#define GPS_SERIAL 2

hier die Geschwindigkeit vom GPS eintragen
#define GPS_BAUD 38500

#define UBLOX oder NMEA
je nachdem wie dein GPS eingestellt ist


Hier das Flashtool für ArduplaneNG:
http://docs.megapirateng.com/documentation/flashtool

Und dann einfach mit dem APM Planner alles einstellen.
 

Teddytimo

Erfahrener Benutzer
#65
Wenn du das AIO Pro hast würde ich dir ArduplaneNG empfehlen, das ist von der Entwicklung her viel erprobter, viel mehr getestet usw. Das Multiwii RTH lohnt sich ja nur mit den kleinen Boards auf denen ein Atmega328 drauf ist.
hm, da ist was dran. Ich habe noch nie mit ArduplaneNG / Megapirat usw. gespielt aber vielleicht probiere ich das einfach mal.
Und du meinst es ist viel erprobter für Flächenflieger als die MultiWii Sache?
 

Rangarid

Erfahrener Benutzer
#66
Naja Arduplane gibt es seit über 5 Jahren... Alles was das Regeln usw. betrifft ist auch ähnlich oder gleich wie beim Arducopter und zumindest der ist sehr erprobt.
 

Chriss_:)

Erfahrener Benutzer
#67
Na toll... :(
Hab wahrscheinlich mein Crius kaputt gemacht... :( Wollte das Team KV MinimOSD anklemmen und habe Tx und/oder Rx vom FTDI auf GND gelegt, sollte eigentlich nicht schlimm sein, aber seit dem reagiert die Crius weder auf den FTDI Adapter, noch auf eine BT-Verbindung!

Hat jemand eine Idee, ob man da noch was retten kann? Stabilisieren tut die Crius noch und reagiert auf alle Steuerbefehle, aber ohne Seriellen Port iwie nicht mehr gut zu nutzen...

Schöne Grüße aus dem Sauerland!
Chriss
 

seeers

Erfahrener Benutzer
#68
Hi Chriss, jetzt wollte ich schon sagen einen Arduino Seriell Beispiel Sketch auf das Board laden, aber das geht ja ohne UART nicht :)
Falls wirklich der Atmega328 Defekt ist, kann ich dir anbieten einen neuen drauf zu löten...
Gruß
Daniel
 

Chriss_:)

Erfahrener Benutzer
#70
Hi Maren,

nein, leider nicht, versuche ich den über den ISP auszulesen, sagt mir avrdude "target doesn"t answer.", nehme mal an, den 328 hats gehimmelt... :p

Schöne Grüße aus dem Sauerland!
Chriss
 
#71
inspiriert von diesem schönen Thread, habe ich mein altes Flyduino 1.1 rausgekramt...Ist ja schon ein 1280er drauf...Also das GPS seriell angeschlossen (38400 baud)...Funktioniert auch alles soweit (Ausschläge, Wirkrichtung etc). Das ganze auf einem Teksumo Wing.
Allerdings habe ich das Problem, dass ich das Teil nicht armen kann! Es dauert zwischen 10 und 20 Minuten und dann springt die Anzeige der Multiwii WinGui (Ver. 2.3pre8) auf Passtrough, meistens zumindest ... Nach dem Einschalten steht sie immer auf GPS Home und Angel (wie Failsafe vielleicht aber Funke ist ja an und alle Werte sind größer 1000, von daher sollte das ja nicht sein).
Arm habe ich auf Aux1 gelegt und auf Aux2 (1000-Passthrough 1500-Horizon 2000-GPS Home).
Wenn er endlich mal auf Passtrough gesprungen ist, kann ich per Arm-Schalter den Motor ein und aus schalten. Auch die Modi funktionieren tadellos und machen was sie sollen.
Jemand irgend eine Idee? Ich mein, wo kommt dieses riesige Zeitfenster her? Ach ja, armen per Sticks (Throttle und Roll hab ich im Sketch angepasst, weil ich ja kein Yaw hab) hilft aber auch nicht. Ach ja, Mutliwii RTH aus dem Fixedwing.rar aus dem zweiten Post# 2
 

seeers

Erfahrener Benutzer
#72
Heute konnte ich das RTH testen --> Funktioniert :)
Nur das mit der Höhe scheint nicht zu klappen, mein Bixler steigt beim RTH gefühlt immer weiter.Für PosHoldRate D habe ich 0,01 also 10m ( auch schon mit 0,005 getestet) er steigt trotzdem auf ca. 50m und "kreist" dann über mir. Die FC hat einen Baro der im Sketch aktiviert ist.
Habt ihr eine Idee warum er so hoch steigt?

@Rangarid hast du eigentlich den RTH Code ohne i2c GPS auf dem NanoWii Board zum laufen gebracht?
 
Zuletzt bearbeitet:

Chriss_:)

Erfahrener Benutzer
#73
Hi seeers,

ich meine es gibt eine default-safty-Einstellung, die es nicht zulässt, RTH unter einem bestimmten Wert durchzuführen, werde mir den Code nochmal anschauen, vielleicht finde ich da noch was raus! ;)

PosHoldRate D ist aber richtig.

Japp, Rangarid hat GPS über Serial zum Laufen gebracht, mit der Einschränkung, dass während dessen weder das BT-Modul, noch andere Dinge (OSD, Telemetrie, ...) funktionieren.

@ivanhoes: warum legst du Arm auf einen anderen Stick, wenn du es auf einem Schalter hast? Wenn der Schalter gesetzt ist, funktioniert die Stick-Kombi nicht, also brauchst du da nicht machen! ;) Hast due die RC-Input-Werte in der GUI überprüft? Sonst würde ich nochmal alles runter schweißen und ein EEPROM-Clear machen und nochmal von vorne beginnen! ;)

Schöne Grüße aus dem Sauerland!
Chriss

Edit: @seeers: freue mich schon auf das neue alte Crius-Board! :) Vielen Dank nochmal! ;)
 

Chriss_:)

Erfahrener Benutzer
#75
Hi Rangarid,

japp stimmt, hatte ich vergessen! ;)
Leider kann man das OSD und die FrSky-Telemetrie nicht zusammen nutzen... :(

Schöne Grüße aus dem Sauerland!
Chriss
 
#77
@ivanhoes: warum legst du Arm auf einen anderen Stick, wenn du es auf einem Schalter hast? Wenn der Schalter gesetzt ist, funktioniert die Stick-Kombi nicht, also brauchst du da nicht machen! ;) Hast due die RC-Input-Werte in der GUI überprüft? Sonst würde ich nochmal alles runter schweißen und ein EEPROM-Clear machen und nochmal von vorne beginnen! ;)

Hi,

das war eine von unzähligen Maßnahmen...In der "Verzweiflung" probiert man halt irgendwann auch unsinniges... Habs mittlerweile rausgenommen... gleiches Phänomen... Werte in der Gui stimmen alle und auf dem TAB RC-Controll-Settings schaltet auch alles wunderprächtig... aber im Flightdeck eben nicht...Da steht ca. 10 Minuten lang Angle und GPS Home drin...und dann plötzlich ohne mein Zutun: Passtrough! Jetzt funktioniert alles wie gewollt und erwartet, was mich zu der Annahme verleitet, dass ja eigentlich alles ok sein müsste... Und um das ganze noch zu toppen: Nach weitern ca. 10 Minuten springt es wieder zurück in den "Angel und GPS-Home" Modus!!!
Eeprom-Clear teste ich, letzte Hoffnung, spannend.
Danke für die Info!
Grüße aus Mittelhessen!
 
Zuletzt bearbeitet:

seeers

Erfahrener Benutzer
#78
Japp, Rangarid hat GPS über Serial zum Laufen gebracht, mit der Einschränkung, dass während dessen weder das BT-Modul, noch andere Dinge (OSD, Telemetrie, ...) funktionieren.
Das klingt gut, geht das dann nur mit der Atmega32U4 basierenden FC oder auch mit den Atmega328?
@Rangarid würdest du deine angepasste Version hier anhängen?

Grüße Daniel
 

seeers

Erfahrener Benutzer
#79
ich meine es gibt eine default-safty-Einstellung, die es nicht zulässt, RTH unter einem bestimmten Wert durchzuführen, werde mir den Code nochmal anschauen, vielleicht finde ich da noch was raus! ;)
Hi Chriss,

ich bin den Code gerade mal durchgegangen, bezüglich RTH Alt konnte ich das folgende in der GPS.cpp finden:

#define SAFE_NAV_ALT 20 // Safe Altitude during climbouts Wings Level below this Alt. (ex. trees & buildings..)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int16_t RTH_Alt = conf.pid[PIDPOSR].D8;// conf.pid[PIDALT].D8;
~~~~~
// Handles ReSetting RTH alt if rth is enabled to low!
if(f.CLIMBOUT_FW && curr_Alt < RTH_Alt ) { GPS_hold[ALT] = GPS_home[ALT] + RTH_Alt;}

int16_t navTargetAlt = GPS_hold[ALT]-GPS_home[ALT]; // Diff from homeAlt.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// Climb out before RTH
if(f.GPS_HOME_MODE )
{
if(f.CLIMBOUT_FW)
{
GPS_AltErr = - (GPS_MAXCLIMB *10) ; // Max climbAngle
NAV_Thro = CLIMBTHROTTLE; // Max Allowed Throttle
if(curr_Alt < SAFE_NAV_ALT){ navDiff=0; }// Force climb with Level Wings below safe Alt
}

if( (GPS_distanceToHome < SAFE_DECSCEND_ZONE )&& curr_Alt > RTH_Alt){
// Start decend to correct RTH Alt.
GPS_hold[ALT] = GPS_home[ALT] + RTH_Alt;
}
}


Die SAFE_NAV_ALT müsste doch die Untergrenze sein oder?

Wird der Baro (wenn einer angeschlossen ist) überhaupt für die Höhenregelung verwendet? Hier bezieht sich irgendwie alles auf GPS altitude.


Grüße
Daniel
 
Zuletzt bearbeitet:
FPV1

Banggood

Oben Unten