FPV-Treff.de

Das unabhängige Forum von und für FPV-Piloten
Aktuelle Zeit: Do 8. Dez 2016, 07:56

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]




Ein neues Thema erstellen Auf das Thema antworten  [ 3457 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5 ... 173  Nächste
Autor Nachricht
 Betreff des Beitrags: Naze32 CodeEcke
BeitragVerfasst: Mo 25. Feb 2013, 23:55 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
Hi!
Hier wollte ich mal eine kleine Code-Ecke zum Naze eröffnen. Mittlerweile ist ganz schön etwas an Änderungen zusammengekommen. Hier im ersten Post soll eine Linkliste zu den aktuellen Versionen stehen. Im 2.Post dann eine Anleitung, soweit es drin sitzt....
Woher der Name Harakiri?
Als ich anfing aus einem Multiwiiprojekt heraus mich mit dem Naze als 32 Bit Platform zu beschäftigen, hatte ich noch keine Hardware vorliegen, aber dennoch eine Umsetzung gewagt. Da die Hardware aus Japan kommt und der Ausgang eines Testfluges ungewiss war, entstand der Name Harakiri. Die erste Version hatte direkt eine Endlosschleife und flog daher überhaupt nicht, der zweite Anlauf flog zwar, machte seinem Namen aber alle Ehre und kostete Propeller (sorry dafür..). Mit Eintreffen der Hardware hatte sich das dann schlagartig geändert. Normalerweise ist der gepostete Code probegeflogen, sonst steht eine entsprechende Warnung dabei.
Viel Spass beim Mittesten - natürlich auf eigene Gefahr.
Rückmeldungen können auch ruhig OT sein. Wenn es zuviel wird, ist es allerdings besser einen neuen Thread zu starten...

LG
Rob

*** WARNUNG ***
Bei feature pass zuerst die Fernsteuerung einschalten!! Sonst können die Motoren "volle Pulle" loslaufen. Niemals ohne gültiges RC Signal einschalten! Propeller besser entfernen! Blutige Finger möglich! Aktuelle Versionen sind nicht mehr betroffen, trotzdem kann es zu einem kurzen Zucken der Props kommen!
*** WARNUNG ***


*** Grundsätzlich ist das Testen alternativer FW immer auf eigene Gefahr. ****

Versionsübersicht:

Spezielle Airplane Variante von Johannes:
Aktuelle Airplane Version:
viewtopic.php?f=18&t=1368&start=2160#p36733
Passendes Hexfile: https://github.com/slashphotos/harakiri ... nnes_1/obj
Ältere Airplane Version:
viewtopic.php?f=18&t=1368&start=1380#p31448

Die aktuelle Version findet Ihr im Anhang mit Hinweisen.

Und sonst so:
Post #2 Anleitung / English Doc: viewtopic.php?f=18&t=1368&p=20580#p20580
Post #3 Tipps, Tricks und Links: viewtopic.php?f=18&t=1368&p=20578#p20578
Post #4 Videosammlung viewtopic.php?f=18&t=1368&p=20578#p20579

"Historische" Links
Sie (die 9b) ist identisch mit der 9er Version hier:
viewtopic.php?f=18&t=1368&p=21111#p21111
Bei der 9a ist nur der Ublox Teil verändert, bei wem es bislang mit ublox und der 9er lief, braucht eigentlich nicht die 9a. Das Feature Pass lässt sich jetzt auch auf einzelne Motoren beschränken.

Im Anhang ist immer der aktuelle Snapshot des "Tages"..

Github: https://github.com/Crashpilot1000
Github maintained by "slashphotos" https://github.com/slashphotos/harakiri
Atavistic Gui Links:
Just for the spirit of open source: https://github.com/Crashpilot1000/LastK ... flightGUI2


Dateianhänge:
Dateikommentar: Altered/Improved mwii core parts. Hex included. Both Pid controllers tested, Althold tested, PH tested. Not tested: Sonar (unchanged code), RTL (unchanged code). The rest of the code is unchanged. The improved core leads more precise action. During acc calibration you will see the gui going bersek displaying values that tilt out at 1000 with original gui - that is normal due to the better calibration. After calibration the naze will reset itself and everything will be back to normal. Accz is normalized to 512 for the sake of mwii...
feature ppm is preset in that hexfile.
Here the changelog:
Naze32 Harakiri10 Summer Games2.5
=================================
- Experimental IMU Changes. Better MPU Gyro usage. All acc scaled to "512" for 1G
- Precision improved ACC/Gyro calibration.
- MPU6050 "single shot" readout like suggested by Sebbi
- Changed MPU Acc setting from 8G to 4G, increasing resolution without observing saturation effect (right now...).
- Experimental IMU Change for GPS
- gyro_cmpf_factor changed to 1000 (from 400)
- Added vario data transmission within MSP_ALTITUDE

BUG FOUND: SONAR ON PWM56 IS NOT INITIALIZED (so not working :( )
EDIT: SONAR REPAIRED VERSION IS HERE
http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=43967#p43967
You will only need this, if you have a Sonar attached.

Source081513-2215Uhr.zip [930.04 KiB]
2154-mal heruntergeladen
Dateikommentar: - Hex/Bin included PH/RTL Tested.

Naze32 Harakiri10 Summer Games2.4 WITH EXPERIMENTAL LOGGING
===========================================================
- LLIGHTS & LEDMAX Deleted (Had no use in BF anyway)

// Logging don't expect anything of it yet
// - Introduced some "GPS LOG Box" will record when armed, only one log possible. So restarting logging will delete old log.
// - Introduced gpslog in cli to show dataset(s)
// - GPS Logging for 19,5 Minutes for LAT/LON/ALT/HEADING at 0.5 HZ (every 2 sec new dataset)
// - Logging precision is slightly decreased for compression reasons, one Dataset needs just 4 Bytes, so 2,3KB can store 20Min flight
// - Flightstats couldn't display negative alt, basic stats can be saved now. When doing a general save on eeprom (like save in cli or write in gui, or if logging anyway)
// - Flightstats will be cleared at power up with the default stat_clear = 1. With 0 the last saved stats will be taken into account concerning max speed/hight etc..

Core changes:
- Reintroduced old, (t)rusty MTK parser.
- Removed the fix acc_1G value from multiwii and calculate real acc_1G during calibration. So you will not see that fix "512" for mpu any more. On the first run altitude will show a flatline until ACC calibrated (wait a little for save) and FC repowered
- Moved Gyro calibration, angle calculation to float point calculations.
- INS FACTORS WILL HAVE TO BE RETUNED - OMG. gps_ins_vel reduced to 0.6. nav_slew_rate set to 20 now (reducing, increases strength). accz_vel_cf untouched seems to fit.
- gps_tbe_speed deleted was of limited use
- PH/RTL Bug fixed (actual position could be ignored esp. on RTH)
- PosrI put to work (and scaled further down by /100) but just with the velocity error that is calculated from position error (posP). So will hopefully have effect now without circeling. Default 0.Untested.
- Stay away from the feature inflightcalibration it will probably kill INS/ACC functions because it isn't affecting the trims but the real acc calibration. - Outdated mwii code.
- Reworked MsBaroDriver a little (probably slight resolution increase)

Source280713-2000Uhr.zip [1008.43 KiB]
1641-mal heruntergeladen
Dateikommentar: Naze32 Harakiri10 Summer Games2.3
- Hex/Bin included
- Little update just concerning ublox parser. Some people reportet uBLox 6M didn't show Lat/Lon but satcount.
- So ublox parser is redone here and it is a mixture of current BF/Mwii and Arducopter driver
- I hope it resolves that issue. Works the same on my rig than the old one
- Reduced the defaultPIDs, because the correct controller is more aggressive
http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=41339#p41339

Source210713-1920Uhr.zip [924.21 KiB]
1903-mal heruntergeladen
Dateikommentar: Naze32 Harakiri10 Summer Games2.2
- NOTE: RE - UPLOADED because 7Zip was set to some compression mode some pc systems didn't understand.
- Hex/Bin included
- Just updated main PID controller (mainpidctrl = 1 (default)) according to BRM's suggestions here: http://www.multiwii.com/forum/viewtopic.php?f=23&t=3524&start=150#p38927
- So WARNING: Your current PIDs for nick /roll/yaw/level will be more aggressive!!
- Relaxed timings on ublox startup configuration
- Minor mavlink changes

Source190713-1945Uhr.zip [598.24 KiB]
906-mal heruntergeladen
Dateikommentar: Naze32 Harakiri10 Summer Games2.1
Hex & Bin included.
That version is identical to Harakiri10 Summer Games2
Except for the bearing calculation for RTH.
The original "arduino style" plain earth model is removed and replaced by a more STM like approach for that. In the result the copter steers a more correct line to the targetpoint. See readme for the link to the used formula.
"gps_tbe_speed" is turned off now (set to "0")
GER details here: http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=40827#p40827

Source160713-2300Uhr.zip [978.87 KiB]
447-mal heruntergeladen
Dateikommentar: Harakiri10 Summer Games2
HEX & BIN included. Test flown.
Basic Mavlinksupport.
Many changes. Detailed Readme included!
Nothing more to say here....
http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=40623#p40623

Source140713-2300Uhr.zip [967.4 KiB]
596-mal heruntergeladen
Dateikommentar: Harakiri 10 "Summer Games".
Hex & Bin included. Testflown esp PH and RTH.
Many changes (most of them internally) some new cli extensions like status displays now some stats of the flight (max/min hight, max Speed in cm/s & Km/h) - just a gimmick those stats are currently not saved. Cli Option to comfortably edit the aux channels just in case you have more than 4 and only linux. Some variables removed and some new :) .
Parameters are flown and *work* with 450 Quad and ublox.
Mavlink not included in this release, it is planned as an alternative protocol so minimOSD works directly. The basic functions work but Mavlink needs more work to be done on my side.
See here for details. And please look in config.c for detailed description of parameters.
http://fpv-treff.de/viewtopic.php?f=18&t=1368&start=2640#p39884

Source070713-0700Uhr.zip [675.26 KiB]
609-mal heruntergeladen
Dateikommentar: HEX INCLUDED. STILL EXPERIMENTAL!! Just a very good update on the baro part of "Source230613-2250Uhr.zip". The rest is unchanged.
Maximized the accuracy of BMP085 (rewrote parts of the driver). Retested speedup for BMP but it is a sacrifice in accuracy with low speedgain - so not done. With this driver BMP is working on its' limits speed and accuracy wise. I see no headroom on the driverside for BMP anymore.
Reorganized parts of the Barostuff (reducing variables etc) and improved the responsiveness of the throttlestick in althold. I had the chance to take it for a short baro only spin ..... that is a must have you will have to see for yourself!

Source240613-1440Uhr.zip [249.34 KiB]
435-mal heruntergeladen
Dateikommentar: HEX INCLUDED, but EXPERIMENTAL!! GPS Partly tested (weather). MS Baroreadout sped up (37Hz to 50Hz) by taking new Temp. every 2nd read. Baro Timebasecalculation changed. MS althold works slightly better now. Taking Temp every 4th read (like APM) reduces accuracy too much. Testing suggests that BMP readout suffers by this regarding accuracy - so not enabled for BMP, BMP Althold minimal improved due to better timebase.
Redone MainPidcontroller, adjustable cutoff freq for pt1emelent. yaw rate factor not scaled down yet. Timebase corrected. Original controllers deleted.
mainpidctrl = 1 or 2 // 1 = OriginalMwiiPid pimped, 2 = New mwii controller pimped
(experimental some parameters need to be scaled)
New/rewritten GPS "D" part. To hopefully work better together with acc data. Imax and Dmax(new) set to half max gps angle. So only I and D together can outperform GPS P. "Deadband" for gps D removed for now. Currently partly tested, seem to be beneficial. PosR I re-introduced and put to work.
passgps made a little more informative/communicative and userfriendly concerning nmea and mtk gps.

Source230613-2250Uhr.zip [249.6 KiB]
374-mal heruntergeladen
Dateikommentar: It' Sunday! This version is right for a show - off in the field! HEX included.

Infos:http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=37490#p37490

RTL (with nav_controls_heading = 0 "come back as you are") & PH tested. This version also includes the Oled extensions mainly done by Johannes but pushed further by Carsten. Don't know if that works I am not planning to buy that stuff. A new cli option makes ublox configuration possible without extra serial adapter. It has some caveats you should know about but basically it works.

Source160613-0650Uhr.zip [602.17 KiB]
447-mal heruntergeladen
Dateikommentar: Hex included. Last Version deleted (had no hex and did permanent reset on the gps system ...).

This Version is tested concerning Acro / Angle / Horizon / Althold / Sonar / Headfree / Pos Hold.
The mag driver has been debugged and working around 70 Hz now (was 10Hz before). Implemented the Patch for horizon mode that was introduced much earlier but slipped my attention (i don't fly horizon ... )
Have Fun testing !!!

Hier sind die Parameter erklärt:
http://fpv-treff.de/viewtopic.php?f=18&t=1368&p=36759#p36759

Source100613-1750Uhr.zip [230.23 KiB]
461-mal heruntergeladen
Source160413-1615Uhr.zip [206.72 KiB]
1002-mal heruntergeladen

_________________
while(!understand) readmanual();


Zuletzt geändert von Roberto am Sa 7. Sep 2013, 20:57, insgesamt 172-mal geändert.
Nach oben
 Profil  
 
 Betreff des Beitrags: Anleitung
BeitragVerfasst: Mo 25. Feb 2013, 23:56 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
*** DIESER TEXT DARF NICHT VON ANDEREN KOPIERT WERDEN, AUCH NICHT AUSZUGSWEISE, OHNE MEINE ZUSTIMMUNG ***

Übersicht über die Änderungen / Funktionen
Die Lageregelung (PID Kontroller) ist gegenüber der Originalversion deutlich verbessert. Das fällt vor allem durch eine mögliche "P" Erhöhung für Roll und Nick auf. Die Flugstabilität ist jedoch auch beim senkrechten Abstieg erhöht. Acromanöver/Loopings: Es kann durchaus sein, dass man dadurch die "Rate" erhöhen muss.
Die übrigen Funktionen/Änderungen sind zum grossen Teil auf die Fusion der Accelerometerdaten mit anderen Sensoren (Barometer / GPS) zurück zu führen.
- Höhehalten relativ zur Gasknüppelmitte (ACC)
- Autolandung & Motoraus
- Return to Home mit definierbarer Mindesthöhe und Autolandung
- Verschiedene Failsave Optionen, je nach vorhanden Sensoren und GPS Funktion
- Deutlich überarbeiteter und beschleunigter GPS und Magnetometer Teil (ACC, MTK3329 Module) Berechnet aktuell mit ca 300 Hz (Mwii 5-10Hz, Arducopter 25-50Hz)
- Alle ESC gleichzeitig "einlernen"
- Led Invertierung für die Status LEDs (JinGej hatte einen Treibertransistor für eine 12V LED-Zeile an den Ausgang des STM gehängt. Da der Ausgang mit Negativ-Logik arbeitet, ist sonst ein weiterer Transistor erforderlich.)

Bekannte Baustellen:
- MS Baro Treiber "zählt" noch manchmal die Höhe hoch viewtopic.php?f=18&t=1368&start=60#p21624
- Passende/bessere Acc/GPS Integrationswerte finden. INS verbessern.

Grundsätzlich ist das Testen alternativer FW immer auf eigene Gefahr.

Funktion und Einstellung des Höhehaltens ("Althold")
Funktion:
Bei Einschalten des Baros wird die Höhe gehalten und es wird gewartet, bis der Pilot die Gasknüppelmitte erreicht hat, erst ab dann kann relativ zur Gasknüppelmitte die Höhe geändert werden. Dabei bestimmt der Pilot die Steig/Sinkrate (ca +-5m/s). Baro-Schalter-aus bewirkt das Ausschalten der Barofunktion und es liegt sofort wieder das echte Knüppelgas an. Die Autolandung kann beim Flug im Baromodus durch Bewegen des Gasknüppels ganz nach unten ausgelöst werden. Dabei wird zunächst die Höhe für 2 Sekunden gehalten und dann der Abstieg mit ca. 40cm/Sek gestartet. Wenn die Motoren für 3 Sekunden ununterbrochen auf Standgas laufen, wird von einer Landung ausgegangen und der Copter abgeschaltet. Das Althold ist sowohl im Gyro, als auch in den Acc-abhängigen Flugmodi zuschaltbar. Sinnvoll erscheint mir allerdings die Kombination von Althold und "Angle"Modus. Wird der Copter, bei eingeschaltetem AltHold, durch irgend etwas auf den Rücken geworfen (Propellerbruch etc), wird das Althold während des "Rückenfluges" deaktiviert. Den Naze gibt es mit 2 verschiedenen Baros (BMP085 und MS5611) - oder ohne Baro. Mit dem BMP ist ein gut brauchbares Althold realisierbar, der MS Baro ist in seiner Genauigkeit, Reaktionszeit und in seinem Signal/Rauschabstand besser.

Zum Verständnis der Accelerometer & Baro Datenfusion:
Für die Fusion von Baro und ACC muss der ACC Teil gute Werte liefern. Da der ACC vibrationsempfindlich ist, kann man die Stärke eines speziellen Lowpassfilters ("LPF") einstellen. So viel wie nötig, so wenig wie möglich ist dabei die Devise, da dieser das Nutzsignal dämpft und in der Reaktion verzögert. Eigentlich sind die voreingestellten Werte gut und man sollte sie nicht verändern müssen. Sollte es dennoch erforderlich sein, die Werte zu verschlechtern, liegen zu viele Vibrationen vor. Die Logik ist bei weitem nicht so empfindlich wie die Arducopter Umsetzung.
acc_lpf_for_velocity = 10 Eine weitere Erhöhung erscheint problematisch (s.o). Eine Verkleinerung des Wertes verbessert die Funktion, soweit es der Vibrationspegel des Copters zu lässt.
Die Fusion der Acc Daten mit den Barometerwerten erfolgt in zwei Schritten. Ein Accelerometer kann nur Beschleunigungen registrieren. Summiert man diese über die Zeit, kann man auf eine Geschwindigkeit schliessen. Betrachtet man diese über eine Zeit, kann man auf eine Wegstrecke (hier Höhenänderung) schliessen. Durch die Summation läuft natürlich schnell ein grosser Fehler auf, der durch das Barometer korrigiert werden muss. Dafür sind zwei Parameter verantwortlich, die man eigentlich in Ruhe lassen sollte...
accz_vel_cf = 0.985 Bestimmt, wie stark das Accelerometer die gemessene Geschwindigkeit bestimmt
accz_alt_cf = 0.940 Bestimmt, wie stark das Accelerometer die gemessene Höhe bestimmt.
Diesen Wert kann man z.B ändern (erhöhen), und damit die "Barokurve" weiter bügeln, allerdings kann auch die acc Höhe "weglaufen", wenn die Barokorrektur zu klein wird.
Damit man auch sehen kann, was man macht gibt es "nazedebug".
nazedebug = 0 Mit dem Wert 1 kann man sich in den Debugfenstern (von li nach re) folgende Werte anzeigen lassen:
- Barohöhe*10 cm
- Höhe fusioniert mit acc Wert*10 cm (Regelungsrelevant für "Alt P", beeinflusst von accz_alt_cf)
- BaroClimbRate
- BaroClimbRate fusioniert mit acc Werten (Regelungsrelevant für "Alt I",beeinflusst von accz_vel_cf)

Alt - PID - Tuning
ALT P: NUR das P kennt die tatsächliche Zielhöhe. D.h wenn er die Höhe nicht hält ist dieser Wert unter Garantie zu klein.
ALT I: Kennt die Zielhöhe NICHT! Es ist die Variometerbremse, d.h. es bremst das Pendeln, das durch "P" verursacht wird. D.h die Luft wird quasi "dicker", als wenn der Copter in Öl fliegen würde.
ALT D: Ist die "Gasvoreilung" bei Verkippung. Bei dem Horizontalflug sackt der Kopter durch, da die Änderung zu spät von acc und insbes. Baro erkannt wird. Für den Horizontalflug ist eine Verkippung des Kopters erforderlich, deswegen kann man hier einstellen wieviel Gas, abhängig zum Kippwinkel, schon mal mehr gegeben wird um das Absacken zu reduzieren/unterdrücken.

Mögliches Vorgehen zur Einstellung. Ich würde die Voreinstellungen als Ausgangsbasis vorschlagen. Das Barometer muss vor Zugluft geschützt und lichtdicht (!) verpackt sein. Nicht leitender Schaumstoff hat sich z.B bewährt.
1. Im Schweben das P hochdrehen, so dass die Höhe auch richtig gehalten wird. P ruhig etw. zu hoch, also nicht wie sonst, wo man das P eher etwas erniedrigt.
2. Dann die Variometerbremse "I" anpassen, bis Oszillationen minimiert/weg sind. Das "I" macht die Luft dicker.
3. Das Abfallen im Flug mit "D" kompensieren. Ganz bekommt man es sicher nicht weg, aber es dürfte schon recht erträglich sein.
Wichtig: Ein zu hohes Standgas verschlechtert die Altholdfunktion. Dadurch wird der Regelungsbereich eingeschränkt. Auf "10" braucht man da nicht zu achten, aber im unfreiwilligen Selbstversuch waren "70" zuviel gegenüber dem tatsächlichen Standgas definitv kontraproduktiv. Deswegen sollte man das "minthrottle" nur so hoch einstellen, dass sich alle Motoren sicher drehen.

GPS und Magnetometer
Der GPS Teil ist noch eine Baustelle und muss noch weiter getestet und parametriert werden. Um von Punkt A zu Punkt B zu kommen, muss die Ausrichtung der "Copternase" bekannt sein, das wird mit dem Magnetometer erledigt. Feature GPS muss natürlich aktiviert sein. Beim Einschalten eines GPS modus habe ich in der GUI auch gleichzeitig das Mag an.

Magnetometer
Die Genauigkeit und Abfragegeschwindigkeit wurde drastisch erhöht. Die Einstellarbeiten am Magnetometer selbst sind eher gering, der Aufwand zur Vermeidung von elektromagnetischen Störungen des Kopters eher hoch. Neben dem Verdrillen der ESC Stromkabel und möglichst grosser Entfernung von Störquellen zum Mag, sind nicht magnetische Metallplatten zur Abschirmung ratsam (z.B Alu, Kupfer). Vor der Mag Kalibration ist es ratsam, vorher das ACC zu kalibrieren und die Mag Declination (s.u) einzugeben. Die Kalibrierungszeit ist auf 60 Sek erweitert. Wichtig ist auch, ihn u.a auf dem Kopf um die Hochachse zu drehen. Wenn N und S nicht genau gegenüber liegen, wiederholt bitte die Kalibration. Mit der Mag Declination ist es bei dem Naze etwas anders als bei der Multiwii, da man jetzt die Werte nicht mehr umrechnen muss.
Beispiel:http://magnetic-declination.com/ aufrufen. Das:
Code:
You are here*NUREMBERG BAYERN
Latitude: 49° 26' 52" N
Longitude: 11° 4' 6" E
Magnetic declination: 2° 19' EAST  <----- Das ist wichtig!
Declination is POSITIVE            <----- Das ist wichtig!

würde diesen Befehl im cli erfordern: set mag_declination = 219 (natürlich "save" nicht vergessen). Es ist also nicht wie bei der Multiwii, wo man selbst die Winkelminuten in Grad umrechnen muss.
8 Grad wären z.b 800, 8 Grad und 5 Minuten wären z.B 805.

GPS
Anmerkung: GPS muss natürlich auch eingeschaltet sein: "feature gps"
Das GPS braucht "freie Sicht" nach oben, sollte möglichst zentral auf dem Copter sitzen, eine Abschirmplatte nach unten hin kann den Empfang verbessern. Die Ausrichtung ist der Antenne ist egal. Bemerkung zum Anschluss: Die Datenübertragung erfolgt seriell (TTL - also keine USB Variante kaufen, falls man doch eine USB Variante haben sollte, gibt es hier eine Umlötanleitung, die auch auf das ublox 6 zutrifft: http://stichw.at/UFO/ARM/GPS/Index.html). RX und TX müssen gekreuzt angeschlossen werden. Der Naze serielle Eingang verkraftet nur 3.3V. Bei MTK Modulen empfiehlt es sich, diese direkt auf 3.3V laufen zu lassen, Ublox brauchen zur Funktion allerdings 5V, ihr Ausgang hat 3.3V. Dieses bitte bei jedem Modul vor Anschluss überprüfen! Spektrum Satelliten lassen sich nicht gleichzeitig mit einem GPS betreiben. Die "gängigen" Pinouts sind im Anhang.
Allgemein gibt es im Hobbybereich verschiedene GPS Produkte und Übertragungsprotokolle. Es gibt natürlich auch Profi - GPS Produkte für mehrere Tausend Euro, die die komplette Navigation erledigen und entsprechend ausgestattet sind incl. eigener Gyroskope, Beschleunigungssensoren, Magnetometer und Barometer. Zur genauen GPS Funktion (Satellite Based Augmentation System, Störungen durch die Atmosphäre, Gebäude, "GPS Wetter", Sonnenstürme etc) bitte Wiki/Google anwerfen, es ist schon wichtig die Grenzen eines Systems zu kennen. Das ist auch ein guter Startpunkt: http://autoquad.org/wiki/wiki/flying/gp ... ion-notes/. Grundsätzlich muss jedes GPS System die genaue Position seiner empfangenen Satelliten kennen, damit es aus den Laufzeitunterschieden die aktuelle Position bestimmen kann. Diese Information ist der sog. Almanach. Dieses Telefonbuch muss immer wieder neu empfangen werden, oder kann zwischengespeichert werden ("Pufferbatterie"), muss aber auch alle paar Wochen aktualisiert werden. Die Positionsberechnungen sind so komplex, dass unsere Hobby-GPS mit ihrer onboard CPU (ARM7?) aktuell nicht in der Lage sind mit mehr als 5HZ korrekte Daten zu senden. Werbesprüche mit 10Hz Updaterate sind aktuell Augenwischerei und für die Funktion kontraproduktiv - nicht selten wird noch eine geheimnisvolle 10Hz Firmware unterschwellig dem potentiellen Käufer unter geschoben.
So, die meisten Hobby GPS sind von den Herstellern MTK oder Ublox. Beide können eigene Binärprotokolle, da gibt es keinen herstellerübergreifenden Standard. Der einzige Standard der für GPS existiert, ist der NMEA Standard. Mit "gps_type" wird im Cli das passende GPS ausgewählt. Ein Autodetect ist z.Zt nicht vorgesehen, man muss schon wissen, was man hat.

gps_type = 0 (default) Definiert ein GPS im NMEA Standard. Es muss eine passende gps_baudrate selbst eingestellt werden, entsprechend der Konfiguration des GPS/seiner FW. Es empfehlen sich FW mit 5Hz Updaterate und 57600 oder 115200 Baud. Es müssen mindestens GGA und RMC Frame übertragen werden (-> google). Der NMEA Modus ist die letzte Wahl, da in der aktuellen Umsetzung (auch das GPS selbst) die letzte Stelle von Lat/Lon nicht übertragen/ausgelesen wird. Prinzipiell kann jedes GPS in diesem Modus verwendet werden.

gps_type = 1 GPS_UBLOX
Benutzt das Ublox Binärprotokoll. Empfehlung: Die APM Konfigurationsdatei mit dem Ublox center einspielen ( http://ardupilot-mega.googlecode.com/gi ... -Ublox.txt) und dann gps_type = 1 verwenden. Dabei wird ein Konfigurationsblock an das Ublox gesendet. Dieser konfiguriert eigentlich auch schon ausreichend (Binärprotokoll wird eingeschaltet, 5Hz Datenrate, Waas/Egnos usw.) Wahrscheinlich, brauch man die 3DR-Ublox.txt Datei nicht, egal ich habs mal so gemacht und läuft. gps_baudrate sollte mindestens 38400 sein. Läuft aktuell bei mir auch auf gps_baudrate = 38400. Mögliche Werte sind: 38400, 57600, 115200. Das ublox modul wird dann automatisch umgestellt. Nachtrag: Harakiri9a ist mit ublox und 115200 Baud getestet, das hatte ich erst Zuhause gemerkt, dass ich gps_baudrate nicht auf 38400 gestellt hatte.

gps_type = 4 GPS_UBLOX_DUMB
Benutzt das Ublox Binärprotokoll. Hier geht allerdings nichts mehr automatisch. D.h. es MUSS eine passende Konfig-Datei geladen werden. Und es muss die Baudrate des GPS selbst voreingestellt worden sein oder bekannt sein, damit man weiss, was bei gps_baudrate einzutragen ist. In dem Zusammenhang würde ich JinGej's zip hier: viewtopic.php?f=18&t=1368&p=20577#p20712 als Ausgangsbasis empfehlen, da es gleich auf 5Hz stellt. Die 3DR-Ublox.txt stellt zunächst nur auf 4Hz. Folgende Datenpakete werden ausgewertet und müssen übertragen werden: MSG_POSLLH, MSG_SOL, MSG_VELNED. MSG_STATUS wird seit Harakiri9a nicht mehr ausgewertet. Ein serial "Passthrough", damit man nicht auf ein FTDI Adapter umkabeln muss, wäre schon wünschenswert, ist aber von mir nicht umgesetzt, da es doch kompliziert ist (Bootloader,CLI und Mwii config laufen über den USB)

gps_type = 2 GPS_MTK16
Für GPS Module MTK3329 mit dem GlobalTop-Branding gibt es eine FW für den spezielle Arducopter Binärmodus. Die Arducopter MTK16 FW ist allerdings veraltet, da sie die letzte Stelle "verschluckt", wie im NMEA Modus. Ausserdem werden Positionsänderungen sehr langsam durchgegeben. Also langsam und ungenau. Wer noch ein MTK 3329 mit dieser FW besitzt und es nicht umflashen kann/möchte, sollte diesen Modus auswählen. Die Konfiguration ist dann voll automatisch, d.h. es braucht keine gps_baudrate mehr angegeben zu werden. Diese würde auch ignoriert.

gps_type = 3 GPS_MTK19
Für diesen Modus gilt das gleiche wie für gps type 2. Es wird eine volle Autokonfiguration durchgeführt. Die APM MTK FW 1.9 ist genauer und schneller und daher der 1.6 deutlich überlegen. Beide Firmwares mit Flashutility gibt es hier: http://diydrones.com/forum/topics/pleas ... my-apm-2-0
Warnung: Wer ein MTK 3339 besitzt, darf nicht diese APM FW flashen, das macht das Modul sofort unbrauchbar. Eine Reparaturmöglichkeit ist mir nicht bekannt. Warum die Fa. Globaltop nicht eine MTK1.9 FW für die 3339 Module bringt, ist technisch nicht zu erklären. Vielleicht müsste Drotek da mal Druck machen? MTK 3339 Besitzer müssen derzeit NMEA verwenden.

GPS und ACC Datenfusion
Bislang wurde immer auf neue GPS Daten gewartet, und dann entsprechend eine Navigationsantwort generiert. Die gemeldete GPS Position ist dabei immer älter als die aktuelle Position. In den Ausleselöchern passierte bislang nichts. Beim Arducopter gibt es einen sog. leadfilter, der aus der bisherigen Bewegung des Kopters heraus versucht, dieses Zeitloch zu stopfen. Mit dem Accelerometer kann man jetzt versuchen, dieses Zeitloch mit aktuellen Bewegungsdaten sinnvoller zu füllen. Analog der Vorgehensweise beim Baro geschieht nun folgendes. Die GPS Daten Latitude und Longitude beziehen sich immer auf den Kompass. Daher werden die acc gemessenen Beschleunigungen entsprechend dem Magnetometer (und der mag declination) gedreht und summiert (Nord- und Ostrichtung). Der auftretende Fehler wird durch GPS Daten korrigiert. Wie beim Baro ergeben sich also zwei Korrekturfaktoren. Einer für die Geschwindigkeit (gps_ins_vel) und einer für die absolute Position im Raum (gps_ins_pos). Darüber hinaus kann auch ein eigener lowpassfilter für die ACC Daten in Bezug auf die acc - gps Integration definiert werden (gps_acc_lpf).
gps_ins_vel = 0.600 EDIT: BITTE AUF 0 STELLEN bei Harakiri9a
Je höher dieser Wert ist (näher an "1"), desto stärker bestimmt das acc die gemessene Geschwindigkeit.
gps_ins_pos = 0.400 EDIT: BITTE AUF 1 STELLEN bei Harakiri9a
Je kleiner dieser Wert ist (näher an "0"), desto stärker bestimmt das acc die angenommene Position.
Gute Werte sind noch unbekannt, aber ein gps_ins_pos von 0.1 ist schon sehr knapp. Ich denke in dem Bereich kann man noch viel machen und verbessern (andere acc Kalibration usw), aber vom Ansatz her funktioniert die Sache schon mal recht ansprechend und die GPS Schleife läuft unabhängig von neuen GPS Daten mit 300Hz durch. Wenn für 0.5s keine neuen GPS Daten anliegen, wird die Acc Summation "resettet" d.h. auf 0 gesetzt, damit nicht eine verrückte Summe auftaucht und der Copter nach Bonanza fliegt.
gps_acc_lpf = 1 EDIT: BITTE AUF 10 STELLEN
Das ist der erwähnte Lowpassfilter. Ein Wert von 1 schaltet ihn ab (default). Er funktioniert genau so wie bei der Althold - Sache. Allerdings ist da ein Wert von 10 m.E schon zu hoch (EDIT: Denkste!).

Allgemeines zur GPS Einstellung
Grundsätzlich finde ich es eine schwer überschaubare Parameterflut. Erst mal die Defaultwerte testen. Die besonderen gps-acc Werte würde ich erst mal so lassen, die sind konservativ eingestellt. Die Einstellungsanleitung von EOS Bandi hier: http://i2c-gps-nav.googlecode.com/files ... tation.pdf ist weiterhin richtig. Wollez hatte das Ding mal hier: http://www.wii-copter.de/forum/download ... l&df_id=24 übersetzt.
Ich schalte immer GPSfunktion zusammen mit Mag und Baro ein. Das Mag sollte schon ein "P" von "8-10" haben, "4" sind auf jeden Fall zu wenig. Allerdings darf man das Mag P auch nicht zu hoch wählen, weil dann z.B bei einem RTL der copter zu schnell gedreht wird und sich ein Aufschwingen der Hauptsteuerung ergeben kann. (Dank an mbrak und upapa für den Hinweis!). Bei allen "Harakiris" hier wird automatisch im GPS Modus der Anglemodus aktiv und ggf. ein Horizonmodus deaktiviert. Man kann natürlich noch zusätzlich die "Kästchen" in der GUI setzen.

Werte von denen man sich nicht ins Boxhorn jagen lassen sollte:
gps_wp_radius = 200 Ist für das PH irrelevant. Dieser Wert bestimmt den Abstand (hier:2m) ab wann ein Wegpunkt als erreicht gilt. Den Wert würde ich nicht kleiner machen, da das Wegpunktfinden für den Copter sonst zur Tortur werden kann.

nav_speed_min = 100 // nav_speed_max = 200 Ist auch für das PH irrelevant. Das sind "nur" die Geschwindigkeiten, die bei der Wegpunkt Navigation (aktuell nur RTH) relevant sind. Nachtrag: Auch ich hatte die Annahme, dass ein Wert von 200 bei nav_speed_max für das langsame RTL verantwortlich wäre, das ist aber nur bedingt so, und im konkreten Fall einfach falsch. Testweise habe ich das max auf 350 erhöht und er wurde nicht schneller. D.h. die Geschwindigkeitsbegrenzung hat ihn nicht gestoppt, sondern die Nav PID waren zu niedrig, also insbesondere das Nav P.

nav_slew_rate = 30 Ist ein Lowpassfilter für die ausgegebenen GPS Steuerbefehle an die Hauptsteuerung. Er befindet sich also im letzten Schritt, glättet und verzögert die Steuerbefehle. Das betrifft alle GPS Modi. Die voreingestellten "30" (EosBandi/BF Default) sind für meinen grossen Copter OK. Mit dem Parameter habe ich noch zu wenig herumgespielt, aber man kann ihn ruhig mal testweise (EDIT) verändern und schauen, ob es dann zappelig wird. Je HÖHER der Wert, desto geringer die Wirkung! Ein Wert von "0" schaltet ihn ab. Das ist von der Logik her etwas paradox...

Im Gegensatz zu gps_baudrate = X, hat serial_baudrate = X nichts mit dem GPS zu tun! Damit wird nur die Geschwindigkeit am USB/Telemetrieport eingestellt!

Erkennen der empfangenen Satanzahl mit Blinkcodes:
Helste hatte da eine gute Idee, die rote LED sollte einem die Sat-Anzahl vorblinken. Diese Idee wurde von "Hinkel" aufgegriffen und erweitert d.h es wird erst ab 5 Sats zum Mitzählen geblinkt. Das funktioniert so:
Normalerweise zeigt die rote LED den Flug im angle/horizon Modus an. Das macht sie auch weiterhin. Ist ein GPS angeschlossen und werden 5 Sats empfangen ändert sich ihre Funktion. Es wird die Sat-Anzahl ab 5 Sats vorgeblinkt mit jeweils 2Sek. Pause nach einem durchgeblinkten Block. Also 1 mal blinken = 5 Sats, 2mal blinken = 6 Sats usw....
Version 10Beta blinkt nur die Sats, wenn auch ein "SatFix" (2D oder 3D) vorliegt. Normalerweise liegt bei 5 Sats auch ein Fix vor, unter schwierigen Bedingungen (Gebäude usw) kann das anders sein, dann fragt es sich allerdings auch, ob das Benutzen einer GPS Funktion überhaupt sinnvoll ist. Die Benutzung von Headfree und/oder GPS in urbanen Gebieten ist m.E absolut nicht zu empfehlen.
Warum sollte man überhaupt wissen, wieviel Sats empfangen werden?
Die Homeposition wird ab 5 Sats gesetzt, wenn der Copter scharf geschaltet wird ("arm"). Fliegt man mit z.B mit 4 Sats los, dann wird irgendwo in der Luft plötzlich die Homeposition gesetzt, wenn er 5 Sats hat. Ein return to launch wird dann natürlich zur Lotterie. Wenn man z.B mit dem "armen" am Boden wartet bis 7 Sats da sind, hat man mit Sicherheit eine anständige Startposition gesetzt.

Aktuelle (Harakiri9+) Umsetzung des PH:
Grundsätzlich wird jetzt in jedem GPS Modus automatisch der Angle Modus aktiviert. Ich habe in der GUI PH und Baro kombiniert.
Der eigentliche PH Kontroller ist nicht überarbeitet. Natürlich wird er mit acc/gps Daten gefüttert. Da könnte man noch mehr machen, also neu schreiben....
Das PH funktioniert erst ab 7 Sats, da es eine Luxusfunktion ist. Ausnahme: Failsave PH schon ab 5 Sats.
Fällt im PH die Satanzahl unter 7 wird das PH ausgeschaltet. Man kann auch im PH herumfliegen. Sobald man stehen bleibt, wird die aktuelle Position für das PH genommen. Das funktioniert nur, wenn man langsam im PH den Copter durch die Gegend schiebt.

Aktuelle (Harakiri9+) Umsetzung des RTL:
Grundsätzlich wird jetzt in jedem GPS Modus automatisch der Angle Modus aktiviert.
Return to Launch ist kombiniert mit einer Mindesthöhe und einer Autolandung bei Erreichen der Heimatposition.
gps_rtl_minhight = 20 Gibt die Mindestrückkehrhöhe in ganzzahligen Metern an. gps_rtl_minhight = 0 schaltet es aus.
Erweitertes RTL sieht dann so aus:
1. Althold und PH für 2 Sek (In dem Fall ist PosHold schon ab 5 Sats möglich)
2. Checken auf Mindesthöhe (voreingestellt sind 20m: "gps_rtl_minhight = 20") und ggf. steigen. D.h. wenn ein RTL bei 30m ausgelöst wurde, fällt er nicht. Wird ein RTL bei 5m ausgelöst wird auf 20m gestiegen.
3. Return to launch wird ausgeführt (voreingestellt: Nose in für FPV Rückkehr, nav_controls_heading = 1(default), bei einem Wert von 0 kommt der copter zurück, wie er grade steht.)
4. PH wird wieder aktiv und die Nase in die ehemalige Startrichtung gedreht.
5. Nach 2 Sek wird die Autolandung ausgeführt, im PH Modus.
Wenn es keinen Baro gibt, dann wird ein RTL mit dem anliegenden Gas ausgeführt.

So, das solls jetzt erst mal zum GPS gewesen sein.


Erweiterte Failsave Funktionen:
feature FAILSAFE muss natürlich aktiviert sein.
Abhängig von der Naze Hardware gibt es 4 Fälle:
Dabei ist/sind folgende Parameter relevant (die Defaultwerte sind dargestellt):
failsafe_delay = 10 (1sec) Bestimmt die Zeit des Senderausfalls, bis das Failsafe ausgelöst wird. Für alle 4 Fälle relevant.
failsafe_off_delay = 200 (20sec) Bestimmt die Zeit, ab wann die Motoren ausgeschaltet werden. Relevant für Fall 1 & 2
failsafe_throttle = 1200 Bestimmt die Gasvorwahl bei Senderausfall. Relevant für Fall 1 & 2
Roll/Nick und Gier Knüppel werden auf Mittenposition gebracht, Angle Modus (level) wird eingeschaltet Horizon Modus wird ausgeschaltet.
1: Keine extra Sensoren -> FS wie immer
2: Nur GPS -> RTL wird eingeleitet, wenn keine Homepos bekannt, versuche PH. Gasvorwahl und Motorauszeit wie bei Fall 1.
3: Baro -> Führe Baro Autolandung aus. (failsafe_off_delay irrelevant)
4: BARO & GPS (failsafe_off_delay irrelevant)
4a: Homeposition bekannt: RTL mit Autolandung
4b: Homeposition unbekannt: Führe Baro Autolandung aus, versuche dabei PH.
4c: Nur noch 4 Sats -> Autolandung


Alle ESC gleichzeitig einlernen/ansteuern:
feature pass (Ausschalten feature -pass) Schleift den Gaskanal direkt an die ESC durch (VORHER, in der Gui prüfen ob die Throttlewerte auch passen, also z.B 1000-2000). IN DEM MODUS NICHT FLIEGEN - ich sags nur nochmal. Zur Warnung blinken die rote und grüne LED im Wechsel. Genaue Funktion: Die ganze Initialisierung der Sensoren wird übersprungen (acc/gyro/gps/mag/sonar) es wird nur Fernsteuerung, der Mischer und das CLI initialisiert. D.h. man muss natürlich den passenden Coptertyp eingestellt haben. Wenn ein QuadX (Voreinstellung) belassen wird, aber z.B ein Octo vorliegt, werden natürlich nur 4 Motoren angesprochen. Minthrottle/maxthrottle oder auch mincheck/maxcheck werden ignoriert. Das Signal wird unbearbeitet durchgereicht, man kann es auch in der GUI sehen. Die ESC werden mit der voreingestellten PWM Frequenz angesprochen (motor_pwm_rate = 400).
passmotor = 0 Seit Harakiri9a kann man mit diesem Parameter den Motor auswählen. Mit 0 sind alle Motoren ausgewählt. Sonst entspricht die Zahl der Motornummer aus der BF Anleitung. Das funktioniert natürlich nur, wenn feature pass eingeschaltet ist. Beim ändern der Motornummer z.B mit "set passmotor = 1" muss man nicht noch extra "save" eintippen, die Änderung wirkt sofort.
Anmerkung aus aktuellem Anlass: viewtopic.php?f=18&t=1418#p22143
WARNUNG Bei feature pass zuerst die Fernsteuerung einschalten!! Sonst können die Motoren "volle Pulle" loslaufen. Niemals ohne gültiges RC Signal einschalten! Propeller besser entfernen! Blutige Finger möglich! Die 10beta hat dieses Problem nicht.

Pegelinvertierung der roten und grünen LED:
led_invert = 0: Invertieren des logischen Pegels der LED 0 & 1. Default ist 0 d.h. alles wie immer. Mit led_invert = 1 wird invertiert. Das LED - Blinken bei Initialisierung der Harware ist nicht gändert, d.h. es betrifft nur den laufenden Betrieb, nicht die powerup Phase.

Fortsetzung folgt...., aber das sollte es erst mal gewesen sein :)

Kommende Funktionen, nicht in der 9a
Sonar Anschluss / Anzeige. Die eigentliche Funktion muss noch programmiert werden: viewtopic.php?f=18&t=1368&start=260#p23867

Zusatz LED: viewtopic.php?f=18&t=1368&start=260#p23867


LG
Rob

*** DIESER TEXT DARF NICHT VON ANDEREN KOPIERT WERDEN, AUCH NICHT AUSZUGSWEISE, OHNE MEINE ZUSTIMMUNG ***


Dateianhänge:
SonarPinOuts.png
SonarPinOuts.png [ 121.18 KiB | 77979-mal betrachtet ]
NazeRC-Anschluss.jpg
NazeRC-Anschluss.jpg [ 168.76 KiB | 80818-mal betrachtet ]
drotek_ublox.JPG
drotek_ublox.JPG [ 36.2 KiB | 81730-mal betrachtet ]
naze32-gps.jpg
naze32-gps.jpg [ 85.83 KiB | 81950-mal betrachtet ]
Pinouts.jpg
Pinouts.jpg [ 85.16 KiB | 84209-mal betrachtet ]

_________________
while(!understand) readmanual();


Zuletzt geändert von Roberto am Sa 7. Sep 2013, 02:19, insgesamt 109-mal geändert.
Nach oben
 Profil  
 
 Betreff des Beitrags: Tipps und Tricks
BeitragVerfasst: Mo 25. Feb 2013, 23:56 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
*** DIESER TEXT DARF NICHT VON ANDEREN KOPIERT WERDEN, AUCH NICHT AUSZUGSWEISE, OHNE MEINE ZUSTIMMUNG ***

Tipps, Tricks und Links:

Generelle Hilfe // General HELP
Ich habe Harakiri geflashed und ich bekomme meinen Copter nicht gearmt usw. - HILFE! // I flashed my board with Harakiri and can't get my copter armed - HELP!.
Ganz einfach, das Original flashen und Deinen Händler mit Deinem Problem nerven !!
"Harakiri" ist KEIN Anfängerprojekt, die Coptertechnik muss beherrscht werden !!
Simply flash with original baseflight and bother your retailer with your problem !!
"Harakiri" is NO newbieproject, you will have to know your copterstuff !!
Allgemeine Setup Tips Prädikat: "Sehenswert"
http://www.youtube.com/watch?v=33Tl_rjhQEE

OSD am Naze
Ein Minimosd/Clone funktioniert z.B mit dieser Software: http://www.multiwii.com/forum/viewtopic.php?f=8&t=2918
Allerdings muss man noch folgendes einstellen: viewtopic.php?f=18&t=1368&start=640#p26442
Der Thread dazu: viewtopic.php?f=18&t=2202

Andere, alternative Naze Projekte:
http://fpvlab.com/forums/showthread.php ... -FC-for-25
http://www.rcgroups.com/forums/showthread.php?t=1778845
https://github.com/lilvinz/OpenPilot/wiki
Hier hat "joergrohde" den Naze auf Openpilot umgeflasht, sehr interessant !
http://fpv-community.de/showthread.php? ... r-Software
http://witespyquad.gostorego.com/flight ... 2-249.html

Gute Seiten zum Naze in DE:
http://www.fdings.de/
http://lazyzero.de/modellbau

Offizielle Anleitungen:
Original Timecop
http://www.abusemark.com/downloads/naze32_rev2.pdf
http://flyduino.net/documents/MW32_Kurzanleitung.pdf
http://madetofly.com.au/files/spiritfly_manual_rev1.pdf
Grundsätzlich Vorsicht bei absolut unnötigen, kostenaufwändigen Optionen.
Hier nochmal der Link zu den Stick Befehlen http://code.google.com/p/multiwii/sourc ... FHamburger
Multiwii Wiki http://www.multiwii.com/wiki/index.php?title=Main_Page

Gimbal Funktion
Hier gibts Erläuterungen:
http://www.multiwii.com/forum/viewtopic ... 758#p38241
viewtopic.php?f=18&t=1368&start=260#p23857

Selbstkompilieren:
Die Anleitungen sind hier im Anhang.
Hier ist übrigens die "Mutter" der Baseflight Compilierungsanleitungen: http://www.rcgroups.com/forums/showthread.php?t=1695379. Diese wird durch JinGeis' Anleitung sinnvoll ergänzt.

Alternative GUI's (nur open source)
Grundsätzlich Vorsicht bzgl. der Kompatibilität! Terminalprogramm (z.B Realterm) & MwiiGui 2.1 sind verlässlich.
http://fpv-community.de/showthread.php? ... nd-Windows
http://www.multiwii.com/forum/viewtopic.php?f=8&t=3414
http://www.rcgroups.com/forums/member.php?u=342216
http://www.rcgroups.com/forums/showthread.php?t=1667516


FAQ

GPS
Warum brauche ich einen Kompass, wenn ich ein GPS habe? GPS reicht doch!
Für das GPS braucht man einen funktionierenden Kompass. Das GPS gibt Lat/Lon Koordinaten aus. Und die ergeben eben nur im Verhältnis zum Nordpol Sinn. Der Copter muss wissen, wie seine Nase steht, damit er in die richtige Richtung kippt/beschleunigt. Ohne Kompass müsste man erst in irgend eine Richtung beschleunigen und schauen, wie sich die GPS Koordinaten ändern, um dann zu wissen, wie denn die richtige Richtung gewesen wäre. Das GPS produziert auch ein "Heading", wie ein Kompass, aber eben erst ab einer gewissen Geschwindigkeit. In der Summe ist das brutal ungenau. Deswegen ist ein ungestört arbeitender Kompass Pflicht. Hier steht das jetzt auch nochmal: viewtopic.php?f=18&t=1368&start=2420#p37934

Wie schliesse ich das GPS an? GPS sucht Anschluss "Crius" "HK ublox" usw..
viewtopic.php?f=18&t=1368&start=60#p21645
viewtopic.php?f=18&t=1368&start=60#p21651
viewtopic.php?f=18&t=1368&start=120#p22362
viewtopic.php?f=18&t=1368&start=120#p22415
Vorsicht, es werden auch mal falsche Kabel mitgeliefert!! viewtopic.php?f=18&t=1663&p=26816#p26813
Warnung viewtopic.php?f=18&t=1368&start=720#p27176

GPS Groundplane/Shield und Entstörung
Gute Info über GPS Entstörung - Englisch: http://diydrones.com/xn/detail/705844:Comment:868946
http://autoquad.org/wiki/wiki/autoquad- ... oundplane/
http://autoquad.org/software-downloads/?did=1
http://diydrones.com/forum/topics/how-to-gps-shield
viewtopic.php?f=18&t=1368&start=200#p23373 (So sieht mein Aufbau aus Version 1)
viewtopic.php?f=18&t=1582#p24224 (So sieht mein Aufbau aus Version 2, der funktioniert deutlich besser als die Version1!)
viewtopic.php?f=18&t=1582&start=40#p24831 (Danke, an "DasWollvieh")

GPS Störungen durch Datenradios und Videosender auf exotischen Frequenzen
http://diydrones.ning.com/xn/detail/705 ... nt:1175591
http://diydrones.ning.com/xn/detail/705 ... nt:1175524
http://diydrones.com/xn/detail/705844:Comment:1178440 (Spektrum TM1000 Telemetrie)
Beispiel: GPS Entstörfilter für div. Sender http://www.electronicarc.com/catalogo/p ... 3da12ba890

Magnetometer
Kalibrationsvideo: http://www.youtube.com/watch?v=DmsueBS0J3E

Wieviele Sats kann ich überhaupt hier um wieviel Uhr empfangen??
Gute Frage, sehr gute Antwort: http://satpredictor.navcomtech.com/

Wie kann ich das ucenter überhaupt benutzen?
Hier ist eigentlich eine gute Anleitung, obwohl nicht alles so übertragbar ist. (z.B die 38K Baud Sache, war eher relevant für Arduino, und SBAS kann man ruhig zuschalten, die GPS Höhe ist sowieso irrelevant)
http://code.google.com/p/ardupirates/wi ... PSTutorial

Sonar
viewtopic.php?f=18&t=2242
Nachtrag: Hier steht: http://diydrones.com/xn/detail/705844:Comment:1332799, dass das Maxbotix 1200XL nix taugt am Arducopter und auch sonst für Copter ungeeignet wäre. Tja, bei mir läufts auf jeden Fall sehr gut am Naze. Vielleicht liegt es daran, dass Arducopter es nur analog auswertet und einen ganz anderen Sonarteil/Code hat... Wie dem auch sei, man kann natürlich auch MB1240 verwenden bzw. andere Maxbotix, solange sie über einen PWM Anschluss verfügen.

Spezielle Coptertypen
Wie setze ich einen Octocopter mit dem Naze auf ?
viewtopic.php?f=18&t=1431&p=22002#p21864


Wie setze ich einen Custom Mixer mit dem Naze auf ?
http://www.multiwii.com/forum/viewtopic ... =20#p22264

OSD
Das funktioniert: http://code.google.com/p/rush-osd-development/ als Hardwarebasis wird ein minimosd/clon verwendet.
Noch eine wichtige Info zum Setup: viewtopic.php?f=18&t=1368&start=640#p26442

Sonstiges
Flash fehlgeschlagen, es "leuchtet nur noch blau", "Büroklammer" geht nicht, ist alles defekt?
Dieser Fehler tritt auf, wenn man z.B beim Flashen die Romgrösse falsch eingibt/übernimmt (also z.B 64K statt 128K). Er kann allerdings auch durch ein defektes Hexfile auftreten!
Der eigentliche Bootlader lässt sich nur mit einem JTAG Programmer (extra Hardware) ändern oder zerstören. Mit der onboard USB Schnittstelle geht das nicht! Der Naze ist daher nicht defekt! Der eigentliche Defekt ist die Büroklammer! Einfach Kabel anlöten (oder vergleichbare Methode) die man kurzzeitig verbinden kann, damit der Bootlader angesprungen wird. Ich habe die Kabel angelötet gelassen und mit Schrumpfschlauch überzogen, so dass neben dem Naze ein Stummel heraus schaut. Dadurch kann ich im Notfall wieder "den Büroklammertrick" durchführen, ohne den Naze ausbauen zu müssen.

Scharfschalten über Roll funktioniert nicht // Arming with roll doesn't work
Das ist von "Timecop" per default abgeschaltet und muss erst mit dem charmanten Befehl "set retarded_arm =1" im CLI wieder aktiviert werden. Der Nachteil: Eine Rolle und Gas ganz weg: Copter "disarmt" in der Luft...
"Timecop" disabled that for a good reason, otherwise a "disarm" in the air is possible. To re-enable that "set retarded_arm =1".

Telemetrie am Naze // Telemetry & Naze
Frsky Telemtrieanschluss: http://fpv-community.de/showthread.php? ... -am-NAZE32

Wi232 868 Funkmodule light // Info on rare BT alternative modules
viewtopic.php?f=18&t=1719#p26603

Bluetooth am Naze32 // BT & Naze
viewtopic.php?f=18&t=2556#p39923
http://fpv-community.de/showthread.php? ... post135996

Sensorausrichtungen ändern // Change sensor orientation
Es müssen GYRO, ACC, MAG berücksichtigt werden! // You have to take care of GYRO, ACC and MAG
Allgemeines zu den MWII Wirkrichtungen: http://www.multiwii.com/wiki/index.php? ... rientation
RC groups post: http://www.rcgroups.com/forums/showpost ... tcount=323
So hat es Bamfax gemacht: http://fpv-community.de/showthread.php? ... post276950
http://www.fdings.de/?q=content/naze-ko ... figurieren

Alternativer JTAG Debugger // Alternative JTAG Debugger
viewtopic.php?f=18&t=1368&start=500#p25598
(Hinweis: Ist für den normalen Betrieb nicht erforderlich // Note: Not necessary for normal operation)

Basteltipp // Hobby Tip
Wie baue ich einen Logik Level Converter (LLC)? // How do i build an LLC?
(Ein LLC wandelt I2C 5V Pegel in 3.3V Pegel und umgekehrt // A LLC converts an I2C Bus of 3.3V to 5V and vice versa)
viewtopic.php?f=18&t=1368&p=33983#p33983
CPU Austausch // Change CPU
http://fpv-community.de/showthread.php? ... sorwechsel

*** DIESER TEXT DARF NICHT VON ANDEREN KOPIERT WERDEN, AUCH NICHT AUSZUGSWEISE, OHNE MEINE ZUSTIMMUNG ***


Dateianhänge:
Dateikommentar: Herzlichen Dank an JinGej!
http://fpv-treff.de/viewtopic.php?f=18&t=1368&start=80#p21816

JinGejs' Eclipse Anleitung.zip [1.79 KiB]
569-mal heruntergeladen
KeiluVisionKompilierungsanleitung.zip [1.39 KiB]
1116-mal heruntergeladen

_________________
while(!understand) readmanual();


Zuletzt geändert von Roberto am Sa 14. Sep 2013, 23:44, insgesamt 88-mal geändert.
Nach oben
 Profil  
 
 Betreff des Beitrags: Video - Linksammlung
BeitragVerfasst: Mo 25. Feb 2013, 23:56 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
Video - Linksammlung:

Harakiri10Beta4: (Nicht "offiziell" released, das ist die 2130Uhr Version aus Post 1)
http://www.fpv-treff.de/viewtopic.php?f ... 880#p28290

Harakiri10Beta2: (Nicht "offiziell" released, das ist die 1615Uhr Version aus Post 1)
viewtopic.php?f=18&t=1368&p=27604#p27565
viewtopic.php?f=18&t=1368&p=27604#p27567

Harakiri10Beta1:
http://vimeo.com/62699780 viewtopic.php?f=18&t=1368&start=340#p24692 (Danke, Hinkel!)
http://www.youtube.com/watch?feature=pl ... MgBrFph2R8
viewtopic.php?f=18&t=1368&start=720#p27250

Harakiri9:
viewtopic.php?f=18&t=1368&start=40#p21395

_________________
while(!understand) readmanual();


Zuletzt geändert von Roberto am Di 23. Apr 2013, 14:23, insgesamt 7-mal geändert.

Nach oben
 Profil  
 
 Betreff des Beitrags: English Manual
BeitragVerfasst: Di 26. Feb 2013, 00:01 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
*** THIS TEXT IS NOT ALLOWED TO BE COPIED, EVEN PARTLY WITHOUT MY CONSENT. ***

A translation of the guide by google translator and some editing....

Overview of the changes / features
The main PID controller is a clear improvement over the original version. You will see that it is possible to increase "P" for roll and pitch. Flight stability is also increased when vertical descent. For doing Acro / Loops it might need an increase of RC Rate.
The other features / changes are in large part due to sensorfusion (acc & baro, acc & gps)
- Altitude Hold relative to throttlestick middle
- Automatic landing and disarm
- Return to Home (RTH) / Return to Launch (RTL) with definable minimum height and auto landing
- Various failsafe options, depending on the available sensors and GPS function
- Significantly revised and accelerated GPS and magnetometer part (ACC, MTK3329, Ublox). Calculated currently with approximately 300 Hz (Mwii 5-10Hz, Arducopter 25-50Hz)
- Easy ESC setup. "Learning In" all ESC simultaneously or adressing a single ESC
- Led inversion for the status LEDs ("JinGej" had put a driving transistor for a 12V LED array to the output of STM, since the output works with negative logic it would have required another transistor for inverting the signal)

Known problems:
- MS Baro driver sometimes "counts up" the measured altitude, but that seems only to happen with some MS Baros. viewtopic.php?f=18&t=1368&start=60#p21624

ToDo:
Finding the better Acc / GPS integration values ​​-. INS improve.
Waypointflying, Circleflying with pointing inwards etc....

Basically, the testing of an alternative firmware is on your own risk.

Function and adjustment of height keeping ("Althold")
Function / Usage:
When switching on Althold the copter will immediately hold the hight and wait for the pilot to reach the mid-throttlestick position. Then the pilot can change the copterhight relative to the throttle mid point. The pilot can adjust the climb / descent rate (about +-5 m/s). When Althold is switched off the actual throttlestick - input will be used again.
The Autolanding function is triggered by moving the throttle stick all the way down while flying in Althold mode. First, the hight is held for 2 seconds and then the descent starts with about 40cm/sec. When the engines run continuously for 3 seconds at idle, it will assume a landing and the copter is turned off. The Althold is usable in Acro/gyro as well as in the Acc-dependent flight modes. In my opinion the combination of Althold and "Angle" mode is the most useful one. If the Copter in AltHold is thrown by anything onto its back (propeller breakage, etc), the Althold is disabled during the "back flight." The Naze is available with 2 different Baros (BMP085 and MS5611) - or without Baro. Althold with the BMP is usable, but the MS Baro is better in its accuracy, response time and in its s/n ratio.

Understand the accelerometer & Baro data fusion:
For the fusion of Baro and ACC, the ACC part has to deliver good values. Since the ACC is sensitive to vibrations, you can adjust the strength of a particular Lowpassfilter ("LPF"). As much as necessary, as little as possible is the motto because it attenuates the signal and delays the response. The default values ​​are actually good and you should not need to change them. If it should be necessary to degrade the values ​you have probably too much vibrations going on. The logic is not nearly as sensitive as the Arducopter implementation.
acc_lpf_for_velocity = 10 A further increase is problematic (see above). A reduction of the value may improve the function. This depends on the vibration level of the copter.
The integration of the Acc data with the barometer values is done ​​in two steps. An accelerometer can only register accelerations. Summing this over time, you get the speed. Registering speed over time will get you a distance (here height variation). By the summation of course runs quickly on a big mistake that must be corrected by the barometer. Two parameters are responsible for this, you should really leave them alone ...
accz_vel_cf = 0985 Determines how much the accelerometer determines the measured velocity.
accz_alt_cf = 0940 Determines how much the accelerometer determines the measured height.
With increasing this value you can flatten out your Barograph further but you are risking a "runaway" of accelerometer hight with a too low correction of the Barometer.
You can also see what you're doing there "nazedebug".
nazedebug = 0 A value of 1 will show you the following values in the debug windows:
- Barometric hight x 10 cm
- Combined hight of Baro&ACC x 10 cm (control relevant for "ALT P" influenced by accz_alt_cf)
- BaroClimbRate
- BaroClimbRate combined with acc values ​​(control relevant for "ALT I", influenced by accz_vel_cf)

Alt - PID - Tuning
ALT P: ONLY the P knows the actual target height. Ie if it can not keep the height this value is guaranteed to be too small.
ALT I: Does not know the target height at all! It is the variometer brake, ie braking the oscillation, which is caused by "P". So the "I" makes the air thicker, as if the copter would fly in oil.
ALT D: Gives throttle in advance on tilt. In the horizontal flight the copter can drop, as the hightchange is detected too late by acc and especially Baro. For level flight tilting the copter is required, so you can adjust how much gas here, depending on the tilt angle, ever more will be given to reduce the hightdrop.

Possible procedure for the setting. I would suggest the presets as a starting point. The barometer should be protected from wind and sunlight. Non-conductive foam has proven useful.
1. Increase P in hovering so that the height is maintained properly. Set P a little too high. The swinging will be reduced in the next step.
2. Then adjust the vertical speed brake "I", to minimize oscillations. The "I" makes the air thicker.
3. Check for hightdrop in forward flight and increase "D" if necessary. You will probably not eliminate the hightdrop completely, but it would be quite bearable.
Important: Too high idle motorspeed deteriorates Altholdfunction. Thus the control range is limited. It is advised to set "minthrottle" correctly.

GPS and Magnetometer
The GPS part is still under construction and need to be further tested and configured. To get from point A to point B, the alignment of the "Copternose" has to be known and that is done by the magnetometer. For all GPS functions the "GPS feature" must be enabled in the cli. When turning on a GPS mode I have the MAG activated at the same time in the GUI.

Magnetometer
The accuracy and query speed increased dramatically. The adjustments on the magnetometer itself is rather low, the mechanical effort to prevent electromagnetic interference is relatively high. In addition to the twisting of the ESC power cables and the greatest possible distance from sources of interference to the mag, are non-magnetic metal plates (eg, aluminum, copper) to shield advisable. Before Mag calibration, it is advisable to calibrate the ACC and set the mag declination (see below). The calibration period is extended to 60 sec. If N and S are not exactly opposite, please repeat the calibration. With the mag declination is at the Naze somewhat different than the Multiwii because you now no longer have convert the values.
Example:http://magnetic-declination.com/
This:
Code:
You are here*NUREMBERG BAYERN
Latitude: 49° 26' 52" N
Longitude: 11° 4' 6" E
Magnetic declination: 2° 19' EAST  <----- Important!
Declination is POSITIVE            <----- Important!

would require this command in the cli: set mag_declination = 219 (don't forget "save" afterwards). So it's not like the Multiwii where you have to convert the degrees to decimals.
Another example: 8 degree would be "800", 8 degree and 5 minutes would be "805".

GPS
Just for the record: GPS must be activated in cli with: "feature gps"
The GPS needs a "clear view" to the top, should sit as centrally as possible on the copter, a shield downward can improve reception. Note for connection: Data is transferred serially (TTL - so don't buy the USB version, but if you should have a USB version, here is a guide, which also applies to the uBlox 6: http://stichw.at/UFO/ARM/GPS/Index.html ). TX and RX must be connected crossed. The Naze serial input copes only with 3.3V. In MTK modules, it is recommended to run them directly with 3.3V, uBlox need 5V to function, however, their output is 3.3V. Please check this for each module before connecting! Spektrum satellites can not be run simultaneously with a GPS. The "standard" pin-outs are in the appendix.
Generally, there are various GPS products and transmission protocols. There are also professional - GPS products for several thousand Euros that do the complete navigation and are equipped accordingly incl. own gyroscopes, accelerometers, magnetometers and barometers. For accurate GPS function (Satellite Based Augmentation System, interference from the atmosphere, building, "GPS weather", solar storms etc) please wiki / fire up Google, it's been important to know the limits of a system. In principle, each GPS system has to know the exact position of its satellites to gather the current position. This information is called the almanac. This directory has to be freshly received on powerup, or can be cached ("battery"), but must also be updated every few weeks. The position calculations are so complex that our hobby GPS with their onboard CPU (ARM7?) are currently not able to deliver a good position beyond 5Hz datarate. Slogans with 10Hz update rate are currently eyewash and counterproductive to the function - often is still a mysterious 10Hz firmware subliminally pushed under the prospective buyer.
So, most of the manufacturers are hobby GPS MTK or uBlox. Both use their own binary protocols, because there is no cross-vendor standard. The only standard that exists for GPS is the NMEA standard. With "gps_type" in the CLI the right GPS is selected. Autodetect is not implemented so you have to know what you've got.

gps_type = 0 (default) Defines a standard GPS NMEA. A matching gps_baudrate must be set according to the configuration of the GPS or its FW. A FW is recommend with 5Hz update rate and 57600 or 115200 baud. At least GGA and RMC frame transmitted (-> google). The NMEA mode is the last choice because the last decimal is not transmitted like in binary mode.

gps_type = 1 GPS_UBLOX
Uses the uBlox binary protocol. I put the APM configuration file ( http://ardupilot-mega.googlecode.com/gi ... -Ublox.txt ) on my uBlox before but i don't think it is necessary because when using gps_type = 1 a configuration "block" is send on powerup anyway (binary protocol is turned on, data rate 5Hz, WAAS / EGNOS, etc.). gps_baudrate should be at least the 38400 Baud. Possible values ​​are: 38400, 57600, 115200. The uBlox module is set to the baudrate automatically. I use 38400 Baud with my ublox.

gps_type = 4 GPS_UBLOX_DUMB
Uses the uBlox binary protocol . Here, however, nothing is automatic anymore. Ie, it MUST be setup by you completely. I would recommend JinGej's zip here: viewtopic.php?f=18&t=1368&p=20577#p20712 as a starting point, since it is already set to 5Hz. The 3DR-Ublox.txt will set only 4Hz. The following data packets must be transmitted: MSG_POSLLH, MSG_SOL, MSG_VELNED. MSG_STATUS is no longer needed since Harakiri9a.

gps_type = 2 GPS_MTK16
gps_type = 3 GPS_MTK19
Binary mode for GPS modules with MTK3329 GlobalTop-branding and the 3drobotics 1.6 or 1.9 MTK FW. MTK16 is obsolete and only here for historical reasons. The configuration is done automatically. No need to set gps_baudrate. This would be ignored anyway. FW are available here: http://diydrones.com/forum/topics/pleas ... my-apm-2-0
Warning: Flashing a MTK 3329 FW on a MTK 3339 will brick it. But that's not a real problem because than you have the chance to buy a real, ublox GPS.

GPS - ACC data fusion
The old code was waiting for new GPS data, and then generates a corresponding navigation response. The reported GPS location is always older than the current position. In the time between the reads nothing happened. Arducopter uses a so-called "lead filter" that attempts to predict the current motion/position from the last GPS datasets. With the accelerometer we can now try to fill this gap with real motion data derieved from the ACC instead of predicting stuff. The method used is basically the same as for the Baro - Acc sensorfusion. The latitude and longitude GPS data always refer to the compass. Therefore, the accelerations are measured and rotated according to the magnetometer and summed (North and East) up. The errors will be corrected by GPS data. As with Baro, there are then two correction factors. One for the velocity (gps_ins_vel) and one for the absolute position in space (gps_ins_pos). Moreover, also a separate low pass filter for the data GPS - acc datafusion can be set (gps_acc_lpf).
gps_ins_vel = 0.600 EDIT: PLEASE SET TO "0" with "Harakiri9a"
The higher this value is (closer to "1"), the more the acc influences the measured velocity.
gps_ins_pos = 0.400 EDIT: PLEASE SET TO "1" with "Harakiri9a"
The smaller this value is (closer to "0"), the more the acc influences the assumed position.
Good values ​​are still unknown, but HarakiriBeta10 has a better ACC Fusion at play.
The GPS loop runs independently by new GPS data with 300Hz. When there are no new GPS data for 0.5s, the Acc summation is "reset" to avoid "breakouts".
gps_acc_lpf = 1 EDIT: PLEASE SET TO "10"
This is the low-pass filters mentioned. A value of 1 turns it off. It works just like the Althold - thing.

General information on the GPS setting
Up to Harakiri9a the EOS Bandi manual here: http://i2c-gps-nav.googlecode.com/files ... tation.pdf is still important. Harakiri10Beta has a different PH controller (2 Parameters).

I always turn on GPSfunctions with Mag and Baro. The mag should already have a usable "P" of "8-10", "4" is definitely not enough. Beware of a too high MAG P, because it can lead to wobbels of the copter when doing an automatic turn for RTL etc. For all "Harakiris" here the GPS mode is automatically combined with the Angle mode (Horizon is deactivated).

Values that should not confuse you:
gps_wp_radius = 200 is irrelevant for PH. This value determines the distance (here: 2m) from when a waypoint is considered reached. I wouldn't recommend lowering this value otherwise the copter can have a hard time reaching a WP

nav_speed_min = 100 / / nav_speed_max = 300 Is also irrelevant for PH. They are "only" the speedlimits relevant for waypoint navigation (currently only RTH). For speedier navigation check "Nav P" in the first place.

nav_slew_rate = 30 (default Harakiri9a, 0 Default Harakiri10)
is a lowpass filter for the whole GPS-logic output. The higher the value, the lower the filtering is but "0" disables it. This sounds paradox...

Unlike gps_baudrate = X the serial_baudrate = X has nothing to do with the GPS! Only the speed at USB / telemetry port is set with this command!

Recognizing the received number of GPS Sats with blink codes:
Normally, the red LED will indicate that the FC is in angle / horizontal mode. When there is a GPS attached to the FC and it is receiving 5 or more Sats, the red LED will start blinking the Satnumbers by starting with 5 doing one blink, 6 doing two blinks etc.... there is a 2sec break between each blinking block. 10Beta version needs 5 Sats and a SatFix to start blinking.
Why would you want to know how much Sats are received?
The home position is set from 5 Sats when the copter is armed ("arm"). If you fly with 4 Sats, it will set "HOME" somewhere in the air when it has 5 Sats and a Fix. RTL is a lottery then. If you wait for 7 Sats before arming, you are sure to have a good homeposition set.

Current (Harakiri9a) implementation of PH:
In each GPS mode the Angle mode is automatically activated. I combined the PH with the Baro. The actual PH controller is not revised in Harakiri9a but in Harakiri10. Of course it is fed with acc / gps data. The PH only works from 7 Sats, as it is a luxury feature. Exception: Failsave PH from 5 Sats possible.
When during PH the Satnumber drops below 7 the GPS is disengaged. You can also fly around in PH. This works only if you fly slow in PH. Edit: Harakiri10 has a "prebrake" available.

Current (Harakiri9b) implementation of RTL:
In each GPS mode the Angle mode is automatically activated. Return to Launch is combined with a minimum return height and autolanding on reaching the home position.
gps_rtl_minhight = 20 Specifies the minimum amount of return in integer meters. gps_rtl_minhight = 0 it turns off.
Extended RTL looks like this:
1. Althold and PH for 2 seconds (in the case PosHold possible from 5 Sats)
2. Check for minimum height (20m are preset: "gps_rtl_minhight = 20") and may rise. Ie if an RTL was triggered at 30m, it does not descent. If an RTL is triggered at 5m is will climb to 20m.
3. Return to launch runs (Nose in return for FPV, nav_controls_heading = 1 (default), at a value of 0 returns the copter as it is .)
4. PH is active again and the copter turnes his nose into the former starting direction.
5. After 2 seconds the autolanding is performed in PH mode.
If there is no barometer, then RTL is running with the adjacent gas.

This is a rough overview over GPS functions of Harakiri9a, Harakiri10 has some changes/improvements in this area.


Advanced failsafe functions:
feature FAILSAFE must of course be enabled...
Depending on the Naze hardware, there are 4 cases:
Here is / are the following relevant parameters (the default values ​​are shown):
failsafe_delay = 10 (1 sec) Sets the time of the loss of signal occur until the failsafe is triggered. Relevant for all 4 cases.
failsafe_off_delay = 200 (20 sec) Sets the time from when the engines are turned off. Relevant for case 1 & 2
failsafe_throttle = 1200 Sets the throttle on transmitter failure. Relevant for case 1 & 2
Roll / pitch and yaw stick are brought to the center position, Angle mode (level) will be engaged and Horizon mode switched off.
1: No extra sensors -> FS as always
2: Only GPS -> RTL is initiated when no known HOMEPOS, try PH. Failsafethrottle & Timeout like in case 1
3: Baro -> Baro Autolanding. (Failsafe_off_delay, failsafe_throttle irrelevant)
4: BARO & GPS (failsafe_off_delay, failsafe_throttle irrelevant)
4: Home position known: RTL with auto landing
4b: Home location unknown: Make Baro autolanding, while trying PH.
4c: Only 4 Sats -> auto landing


Adress all ESC simultaneously / or control each ESC separately
feature pas (off feature -pass) Gives the throttle channel directly to the ESC (check your throttlerange BEFORE in your GUI, eg 1000-2000). DO NOT FLY IN THIS MODE. As a warning, the red and green LEDs flash alternately. Exact function: The whole initialization of sensors is skipped (acc / gyro / gps / mag / sonar) it is only remote control, the mixer and the CLI initialized. That is of course you have the right Coptertype selected. When a QUADX (default) is left, but there is an Octo, of course, only 4 motors are addressed. Minthrottle / maxthrottle or mincheck / maxcheck are ignored. The signal is passed through unprocessed, you can also see it in the GUI. The ESC will be addressed at the preset frequency PWM (motor_pwm_rate = 400).
passmotor = 0 Since Harakiri9a you can select a specific motor with this parameter. With "0", all engines are selected. Otherwise, the number will match the engine number in the original BF instruction.
WARNING For feature pass first turn on remote control! Otherwise, the engines start running "full blast". Never turn on without a valid RC signal! Remove propeller! Possible bloody fingers! The 10beta has no such problem.

Level inversion of the red and green LED:
led_invert = 0: inverting the logic level of the LED 0 & 1 The default is 0 ie everything as always. With led_invert = 1 it is inverted. The LED - flashes upon initialization has not changed. It only affects the operation, not the powerup phase.

To Be Continued .... :)

Upcoming functions, not in 9a
Sonar Connection / display. The actual function still needs to be programmed: viewtopic.php?f=18&t=1368&start=260#p23867

Additional LED: viewtopic.php?f=18&t=1368&start=260#p23867

Cheers
Rob


Google/EDIT Translation of Harakiri10publicBeta

Hi!

Here is the public beta of version 10. It is beta because many things are NOT tested.
Overview of the changes:

- Carstens (cGiesen) - Aux channel extensions: Status: tested. Ppsum normal Frsky and Graupner
- Carstens LED pin. Status: does not work yet
- Carstens sonar display. Status: EDIT: tested
- "feature pass" is now safe, even without RC signal. Status: Tested
- Better / functioning GPS - ACC part. Status: tested. Parameters can still be optimized
- Altered PH Controller: Status: tested (more on that later)
- RTL is not changed (same like Harakiri 9a). Status: tested
- RTL return orientation (tail / nose) can be adjusted. Status: tested
- PosHold Minsat can be adjusted. Status: tested
- GPS pre - brake. Status: untested. (Is turned off by default)
- "nav Slew rate" is turned off by default, a spike filter is doing its work. Status: tested
- Changed GPS function parameters: PosHold P and I
- Changed some GPS parameter presets
- Maximum GPS - angle can be adjusted

Altered PH controller
For the actual setting of PH are only 2 values ​​required PosHold P and I.
The default is 1.0 in both cases. The PosHold I will, however, be shown by Carstens Gui as "10.0". EDIT: Since GUI Version 2.0.18.0 it is also shown as 1.0.
PosHold P: Only PosHold P "knows" the absolute position
PosHold I: Fights all relative motion, that makes the air "thicker" in X / Y direction and acts as a kind of brake (the "pre - brake" is a separate function with its own parameters. See below..)
Setting: I scaled the values ​​to 1.0, because these values work for me. That is not to say that it fits all Copters, but it's a starting point. Maximum values ​​for both parameters are "2.5" each.
When setting you can set these two parameters separately, ie set the uninteresting to 0 and fiddle with the other.
I would start with PosHold "I", because it is the most important. With PosHold I you can set how much angle is applied to the copter depending on its speed to brake its movement. Actually, you can get a passable PH only with that parameter. The absolute position is not known to the "I" so drift is possible. Now you can dail in a PosHold P coming from 0 in "0.5" steps. As I said, you can of course also test the "P" alone by setting "I" to 0.

Special GPS / ACC parameters:
The "integration factors" of GPS and ACC are changed because the ACC part works better now. The parameters are "gps_ins_pos = 0.7" (control relevant to PosHold P) and gps_ins_vel = 0.8 (Control relevant to PosHold I). gps_ins_pos is also dependent on gps_ins_vel. Ie if you want to work with these values ​​(and you can certainly do something there), you should start with gps_ins_vel. EDIT: A high yaw rate can currently confuse the ACC integration. So don't yaw too fast in PH with the 10Beta. To make it even more complicated, you adjust the overall quality of the ACC data with gps_acc_lpf. The value of 10 seems to me very useful. Turning off the LPF resulted in a significantly worse control, just as too high values of eg "50". My assumptions / recommendations for the value ranges are valid but no longer for the 10er version. The nav_slew_rate is now set to 0 (= off, before "30"). At the output of every GPS calculation, there is a tiltangle in N-S or E-W direction. This output is processed by a spikefilter now (low/no latency). If it's too rough though, the slew rate can be changed/dailed in again (-> manual above). Gps_acc_lpf, gps_ins_vel, gps_ins_pos and PosHold P / I affect the reaction speed/behaviour.

nav_tail_first = 0 [0 or 1] This allows you to set with which "body part" the Copter returns on RTL. Only works if nav_controls_heading is enabled, like this: nav_controls_heading = 1 (default).

gps_ph_minsat = 7 [5-10] Here you can choose how many satellites are required for PH (idea: Schachti). The PH in RTL or in an emergency is still possible with 5 Sats.

gps_maxangle = 25 [10-40] Sets the maximum tilt angle caused by all GPS functions on the copter. This is an integer degree value (here 25 degrees). Clue: Arm-O-Copter has 25 degrees, Mwii / BF / APM have a 30 degree limit.

nav_slow = 0 [0 or 1] Determines the speed of navigation (RTL or upcoming WP navigation). The default was 1 ie, the rate was halved. Since the RTL works very slowly, I set nav_slow off with "0" now. Success: untested.

Prebrake / Brake before doing further GPS stuff
Before a GPS function is executed, you can perform depending on the flight speed (GPS speed cm / s) a pre-braking. Furthermore, this is determined by the brake angle and the braking period. Is one of the parameter is 0, no pre-braking is performed. The braking is terminated either falls below the target speed or the braking period exspired.
gps_brakeangle = 0 [0-40] is the integer number of degrees the copter braked with (eg 15)
gps_brakespeed = 400 [0-900] velocity in cm/s. If actual speed is higher, a pre-brake is performed. (100 = 3.6 km/h)
gps_braketime = 2 [0-200] Maximum time in seconds that can be braked at all.

Other Changes
The satellite number is now only blinked by the red LED, if a satellite fix is ​​present (and 5 Sats).

*** THIS TEXT IS NOT ALLOWED TO BE COPIED, EVEN PARTLY WITHOUT MY CONSENT. ***

_________________
while(!understand) readmanual();


Zuletzt geändert von Roberto am Sa 13. Apr 2013, 20:55, insgesamt 35-mal geändert.

Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Di 26. Feb 2013, 18:56 
Offline
Pilot
Benutzeravatar

Registriert: Do 11. Okt 2012, 19:02
Beiträge: 443
Wohnort: Hamburg St. Pauli
Name: Andre
Im Moment dudel ich noch mit einem MW Mega2560 rum, aber das Naze reizt mich schon lange. Bei Gelegenheit werde ich deinen code mal testen, das liest sich zumindest alles sehr verlockend :) :daumenhoch:

_________________
I´m not just hard.. I´m NP hard...
Zephyr II, BIXLER 2, TBS Discovery, Mini H 250er CLone, Attitude SD


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Di 26. Feb 2013, 19:53 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
Hi, trailblazer!
Bei der APM darf man allerdings nicht vergessen, dass es ein komplettes Konzept mit osd und missionplaner ist, so ein komplettes Paket gibt es noch nicht in dieser Form auf mwii basierten Systemen, wie dem naze. Mit einem Mega2560 - Schlitten kannst Du auch die kommende Arducopter version laufen lassen (Megapirates NG), das wäre zumindest ein Versuch wert, denn wer weiss, bis zum Sommer gibt es vielleicht auch da eine gute Version? Zum Herumbolzen und Herumprobieren ist der Naze auf jeden Fall zu gebrauchen :)

LG
Rob

_________________
while(!understand) readmanual();


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Di 26. Feb 2013, 20:46 
Offline
Cowboy
Benutzeravatar

Registriert: Di 26. Jun 2012, 11:13
Beiträge: 2046
Wohnort: berlin
so geil,

endlich mal was viel versprechendes in meiner sprache :lachen:

meist du es gibt die möglichkeit einen mag extern am naze laufen zu lassen?
so was hab ich noch hier zu liegen http://www.drotek.fr/shop/en/25-hmc5883l-magnetometer-compass-sensor.html

_________________
BildBildBildBild


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Di 26. Feb 2013, 21:10 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
Hi, Schachti!

Deutsch liesst sich doch flüssiger, als dieses ewige Denglisch :). Leider ist es noch nicht fertig, es ist doch aufwändiger als vermutet, aber auch gleichzeitig eine gute Möglichkeit nochmal alles zusammen zu tragen und zu überdenken.
Ein externes Mag ist natürlich die beste Lösung. Dein Drotek Mag ist genau das, was auch im naze steckt (HMC5883L). D.h. die Treiberunterstützung ist primär vorhanden. Wahrscheinlich werden aber dann beide Mags auf der gleichen I2C Adresse herumdödeln und das geht nicht. Dafür gibt es dann 2 Lösungen, bei denen man allerdings von Datenblättern und Elektronik Ahnung haben muss (die fehlt mir...auch...).
Lösung 1: Dafür sorgen, dass das externe Mag eine andere I2C Adresse hat und dann entsprechend in dem Treiber die neue Adresse eintragen. Bei manchen Chips kann man durch die Beschaltung die Adresse wählen (Drahtbrücke o.ä).
Lösung 2: Das onboard Mag abschalten.
2a: Irgendwie mit dem Lötkolben
2b: Brutal mit dem Schraubenzieher das Teil zerstören und von der Platine entfernen
Das würde mir so einfallen...

LG
Rob

_________________
while(!understand) readmanual();


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Di 26. Feb 2013, 21:23 
Offline
Pilot
Benutzeravatar

Registriert: Mi 27. Jun 2012, 19:38
Beiträge: 311
Wohnort: BERLIN
2b: ist ganz nach meinem Geschmack ;-)


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 10:53 
Offline
FPV Profi
Benutzeravatar

Registriert: Di 26. Jun 2012, 13:10
Beiträge: 587
Wohnort: Berlin
Ich habe eine µ-Blox Konfigurations-Datei gefunden, die man im µ-Blox-Center einspielen kann, damit scheint das GPS sehr gut zu funktionieren (man muss dann eben in der FC set GPS_TYPE=4 wählen) zumindest hab ich es damit geschafft sogar IM Zimmer, ca 1m vom Fenster entfernt einen 3D-Fix und eine um nur max. ca 2m langsam schwankende Position ohne Sprünge zu bekommen, innerhalb nur weniger Minuten, was sonst nur sehr schwer bis garnicht direkt im Fenster möglich war. (geht mit den µ-Blox 6 Modulen - Crius, HK.....)
Datei im Anhang.


Dateianhänge:
u-config-v2.zip [898 Bytes]
758-mal heruntergeladen

_________________
Gruß,
Jin'
Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 10:55 
Offline
FPV Profi
Benutzeravatar

Registriert: Di 26. Jun 2012, 13:10
Beiträge: 587
Wohnort: Berlin
...RX und TX müssen gekreuzt angeschlossen werden. ...

logisch, man redet ja beim Telefon auch nicht in den Lautsprecher und lauscht am Mikrofon :lol:

_________________
Gruß,
Jin'


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 11:48 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
@Jin'Gej: Besten Dank für die ublox config! Das scheint eine geänderte 3drobotics config zu sein!

_________________
while(!understand) readmanual();


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 12:00 
Offline
FPV Profi
Benutzeravatar

Registriert: Di 26. Jun 2012, 13:10
Beiträge: 587
Wohnort: Berlin
ja, kann sein, ich weiß nicht mehr genau wo ich die her hab
eventuell kannst du damit was anfangen und die in das naze direkt reinmachen, dass die geladen wird bei Type=1

_________________
Gruß,
Jin'


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 12:12 
Offline
Cowboy
Benutzeravatar

Registriert: Di 26. Jun 2012, 11:13
Beiträge: 2046
Wohnort: berlin
oder type 1.2 damit man testen und vergleichen kann

_________________
BildBildBildBild


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 17:45 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
Muss man Jin'Gej's Konfigblock denn immer neu einspielen? Wird der nicht auf dem Ublox gespeichert? Es wäre ja ungeschickt, wenn man nacher 10 verschiedene Konfigblöcke im nazecode vorhalten müsste..

_________________
while(!understand) readmanual();


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 17:54 
Offline
FPV Profi
Benutzeravatar

Registriert: Di 26. Jun 2012, 13:10
Beiträge: 587
Wohnort: Berlin
normalerweise sollte das GPS mit dem eeprom das halten....
also, so kenne ich zumindest die funktionsweise eines eeproms

_________________
Gruß,
Jin'


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 18:21 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
@Jin: Ich denke auch, das ublox "dumb" erstmal bei zu behalten für alle "Selbstmacher". Deine Config werde ich auf jeden Fall auch abchecken, dann gibts evtl. noch ein ublox_jin! Mein ublox ist da, leider ist das Kabel nicht mitgekommen :( - irgendwas ist ja immer. Mittlerweile verzweifle ich an den APM GPS Routinen beim Herumgooglen bin ich genau auf eine Lösung gestossen, wie ich sie mir vorstelle: http://www.armokopter.at/wiki/doku.php? ... gps-regler. Armokopter scheint aber nicht einsehbar oder "open" zu sein? All zu tragisch ist das auch nicht, da ich mittlerweile recht gut weiss, welchen softwarebaukasten man braucht. Viele Legobausteine sind schon da :). Die APM - GPS - Sache wird man wohl komplett neu schreiben müssen. Weniger Gesamtparameter werden es wahrscheinlich nicht werden, dafür aber vielleicht weniger, die man tatsächlich einstellen muss. Zu viel Zeit werde ich auf die APM Lösung, in dieser Form nicht mehr verballern. Wenigstens lernt man ungewollt, beim Ärgern über den Code und die eigene Beschränktheit etwas über die Funktionsweise einer copter-gps-Navigation.
LG
Rob

_________________
while(!understand) readmanual();


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 18:33 
Offline
FPV Profi

Registriert: Di 27. Nov 2012, 11:29
Beiträge: 964
Wohnort: Burgenland
Name: Helmut
Was willst Du überhaupt an der APM Steuerung ändern?
Ich finde das lohnt sich nicht.
Die 2.8.1 fliegt gut und ist völlig ausreichend in Bezug auf Loiter und Wegpunkte samt RTL.
Das würde ich einfach mal als Final lassen und die APM mit 2.8.1 als Endprodukt sehen. Meine APMs bleiben jedenfalls so, bzw. werden die verkauft oder in Flächen mit Arduplane FW verbaut.
Momentan ist die Naze Geschichte deutlich spannender. Arducopter kriegt bei mir wieder eine Chance, wenn das auf PX4 oder was ähnlichem läuft und dort längere gute Erfahrungen vorliegen.

_________________
LG
Helmut


Nach oben
 Profil  
 
 Betreff des Beitrags: Re: Naze32 CodeEcke
BeitragVerfasst: Mi 27. Feb 2013, 18:57 
Offline
FPV Profi
Benutzeravatar

Registriert: So 27. Jan 2013, 02:15
Beiträge: 801
Hi, Helmut!

An der APM 2.8.1 Steuerung will ich nichts ändern - die bleibt auf meiner APM auch als "final". Nur die jetzige Umsetzung auf dem Naze, besonders im Hinblick auf die ACC Integration und die schnellere Durchlaufzeit ist noch bescheiden. Die APM benutzt da einige merkwürdige "Vereinfachungen". Da wird z.B im PH Pidkontroller eine Geschwindigkeit (cm/s) einfach direkt, ohne Zeitfaktor mit einer Strecke verrechnet, dabei ist die "Strecke" noch in puren Grad, d.h. noch nicht mal auf cm heruntergerechnet. Vielleicht interpretiere ich das auch falsch, aber dieser PH Codeteil ist zumindest SEHR merkwürdig für mich. Mit ein paar Hertz mag das vielleicht noch gut laufen, aber bei 300Hz mit acc und relativ genauen Geschwindigkeiten, erscheint mir das überholungsbedürftig.

LG
Rob

_________________
while(!understand) readmanual();


Nach oben
 Profil  
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 3457 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5 ... 173  Nächste

Alle Zeiten sind UTC + 1 Stunde [ Sommerzeit ]


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
Impressum und Kontakt

Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de