*** 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)
- 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
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 combined with acc values (control relevant for "ALT I", influenced by accz_vel_cf)Alt - PID - TuningALT 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.
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
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
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_MTK16gps_type = 3
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 WPnav_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 & 2failsafe_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 landingAdress all ESC simultaneously / or control each ESC separatelyfeature 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
RobGoogle/EDIT Translation of Harakiri10publicBeta
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 adjustedAltered 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 184.108.40.206 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. ***