/* Natural alt change for rapid pilots. It's temporary switch OFF the althold when throttle stick is out of deadband defined with ALT_HOLD_THROTTLE_NEUTRAL_ZONE
* but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). It's slowly increase/decrease
* altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms)
*/
#define ALTHOLD_FAST_THROTTLE_CHANGE
scrat wrote:You have compile all files.
dramida wrote:Good finding Wilco! How do you fell about the rate of climb? I would prefer to have a wider range of climb rates.
Takeoff 10
Wait 5
Head 320
GoTo 120
While VBAT >14.6 do {crazy stuff :)}
RTH 30
LAND
Crashpilot1000 wrote:1. In baromode it is not possible to arm/disarm the copter or turn off the flightregulation completely.
2. Entering the Baromode. On activation of Baromode the althold is engaged immediately but the code waits for the pilot to reach the throttlestick centerzone before it accepts any change of targethight relative to centerposition.
Two ways of exiting the Baromode:
A) (#define Rapid_Exit_Barologic2) Turn OFF the baroswitch IN THE AIR and althold is disengaged immediately. So the current throttlestickposition is the real gas immediately.
B) Turn OFF the baroswitch IN THE AIR and althold KEEPS ON RUNNING UNTIL YOU REACH THE CURRENT VIRTUAL THROTTLE WITH YOUR THROTTLESTICK - then you take over. The "Alt PIDs" must be already tuned for this, otherwise it is potentially dangerous of course. Once tuned it is very comfortable and save way to disengage althold.
#if defined(VARIO_ALT_CHANGE)
#define VARIO_P 20
#define VARIO_D 10
int16_t throttleDiff = rcCommand[THROTTLE]-initialThrottleHold;
if (abs(throttleDiff) > ALT_HOLD_THROTTLE_NEUTRAL_ZONE) {
int16_t targetVel = throttleDiff - ((rcCommand[THROTTLE] > initialThrottleHold) ? ALT_HOLD_THROTTLE_NEUTRAL_ZONE : -ALT_HOLD_THROTTLE_NEUTRAL_ZONE);
int16_t velError = constrain(targetVel - vel, -300, 300);
static float accScale = 980.665f / acc_1G; // don't worry, it's calculated only one time because it's static init ;)
//rcCommand[THROTTLE] = initialThrottleHold + VARIO_P*velError/20 - VARIO_D*accZ*accScale/40;
rcCommand[THROTTLE] = initialThrottleHold + constrain((VARIO_P*velError/20 - VARIO_D*accZ*accScale/40), -300, 300);
isAltHoldChanged = 1;
debug[0] = VARIO_P*velError/20;
debug[1] = VARIO_D*accZ*accScale/40;
debug[3] = rcCommand[THROTTLE] - initialThrottleHold;
} else {
if (isAltHoldChanged) {
// much usefull to use BaroAlt instead of EstAlt because it has less delay value when alt hold activated during the vertical movement
AltHold = BaroAlt;
errorAltitudeI = 0;
isAltHoldChanged = 0;
}
rcCommand[THROTTLE] = initialThrottleHold+ BaroPID;
}
#endif
mahowik wrote:I'm going to add this code to my branch soon...
/* In this mode, throttle stick position gives a desired vario. Regulation is divided into two parts, when throttle stick is inside ALT_HOLD_THROTTLE_NEUTRAL_ZONE,
* the current althold regulation is used. When throttle stick is out of deadband, it ascend or descend with a desired vario.
*
* but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos).
* It's slowly increase/decrease altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms).
*/
#define VARIO_ALT_CHANGE
#define VARIO_P 20 // it's force to get desired vario
#define VARIO_D 7 // regulate the speed of vario change and prevent oscillations of PID controller, e.g. if VARIO_D=0 it means that speed to get desired vario (by throttle stick) will be max
/* Predefined initial throttle for AltHold will be calculated from MID (middle/hover) point of expo throttle from GUI
* (BUT not taken from current throttle value on AltHold activation).
* I.e. pls. use GUI to set MID point of throttle expo as initial throttle.
* Note: Value specified by define it's additional compensation for battery consumption
*/
//#define INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT 50
vpb wrote:now alt hold is very good in AP mode (ALTHOLD_FAST_THROTTLE_CHANGE commented out) but it's very slow to control height with throttle stick outside deadband.
// Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +50 cm in 1 second with cycle time about 3-4ms)
AltHoldCorr+= rcCommand[THROTTLE] - initialThrottleHold;
if(abs(AltHoldCorr) > 500) {
AltHold += AltHoldCorr/500;
AltHoldCorr %= 500;
}
// Slowly increase/decrease AltHold proportional to stick movement ( +100 throttle gives ~ +100 cm in 1 second with cycle time about 3-4ms)
AltHoldCorr+= rcCommand[THROTTLE] - initialThrottleHold;
if(abs(AltHoldCorr) > 250) {
AltHold += AltHoldCorr/250;
AltHoldCorr %= 250;
}
vpb wrote:And can I merge this code to my current r1177?
mahowik wrote:mahowik wrote:I'm going to add this code to my branch soon...
Done:
1) Vario PID controller implementation.
- Code: Select all
/* In this mode, throttle stick position gives a desired vario. Regulation is divided into two parts, when throttle stick is inside ALT_HOLD_THROTTLE_NEUTRAL_ZONE,
* the current althold regulation is used. When throttle stick is out of deadband, it ascend or descend with a desired vario.
*
* but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos).
* It's slowly increase/decrease altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms).
*/
#define VARIO_ALT_CHANGE
#define VARIO_P 20 // it's force to get desired vario
#define VARIO_D 7 // regulate the speed of vario change and prevent oscillations of PID controller, e.g. if VARIO_D=0 it means that speed to get desired vario (by throttle stick) will be max
Try to play with VARIO_P and VARIO_D...
Max vertical speed limited about +/-3m/s. But I suppose you can get 4-5m/s because calculated vario (vertical velocity) based on accZ with deadband and during integration acceleration to velocity "part of that" will be lost and actually measured 100cm/s equal to real 130..160cm/s. Where algorithm works with the measured values with defined limitation of 3m/s which can be equal to real 4-5m/s...
I also added useful feature: when you activate the althold, initial throttle taken from stick (or calculated from INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT, see below), but actually it's not precised throttle for hovering... after one-two second it's become stabilized by althold PID regulator and BaroPID it's correction for initial throttle... And when we start regulate altitude, initial throttle will be corrected for hovering...
- Code: Select all
if (!isAltChanged) {
// apply real initial throttle hover (it's stabilized when alt hold activated) here before changing the altitude
initialThrottleHoldOutput = initialThrottleHoldOutput + BaroPID;
isAltChanged = 1;
}
And some features from my last B[x]-releases:
2) possibility to set predefined initial throttle for AltHold from GUI by setting MID (middle/hover) point of expo throttle.
- Code: Select all
/* Predefined initial throttle for AltHold will be calculated from MID (middle/hover) point of expo throttle from GUI
* (BUT not taken from current throttle value on AltHold activation).
* I.e. pls. use GUI to set MID point of throttle expo as initial throttle.
* Note: Value specified by define it's additional compensation for battery consumption
*/
//#define INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT 50
3) protection from ARM if BARO activated
4) condition to keep "I" parts on throttle less then MINCHECK for acc, gyro if BARO activated. To avoid lost of the stability accumulated by "I" part of PID controller... It's related to stability of heading, acro, stable modes...
Pls. note that is not tested on the fly yet. Only some initial GUI night testing... So keep your finger on the switch...
svn revision: http://code.google.com/p/multiwii/source/detail?r=1257
prepared archive: http://multiwii.googlecode.com/svn/bran ... _r1248.zip
thx-
Alex
diyboy wrote:mahowik wrote:svn revision: http://code.google.com/p/multiwii/source/detail?r=1257
prepared archive: http://multiwii.googlecode.com/svn/bran ... _r1248.zip
Today I tested the r1248 with my 330frame X4 the BARO working fine.
dramida wrote:I just tested the latest archive release with vario. It works very good with default pids. The video will post this night. A must se video with gps hold and vario baro mode and autolanding.
copterrichie wrote:Now it is time for waypoints. Nice..
dramida wrote:And here is the video in witch the variation of altitude is controlled by throttle stick position
mahowik wrote:diyboy wrote:mahowik wrote:svn revision: http://code.google.com/p/multiwii/source/detail?r=1257
prepared archive: http://multiwii.googlecode.com/svn/bran ... _r1248.zip
Today I tested the r1248 with my 330frame X4 the BARO working fine.
Many thanks! I think you was first
I hope you are talking about testing "prepared archive" or "svn revision" from links above? i.e. not just r1248, because it hasn't latest changes...
Also could you tell more details or probably you have video how VARIO controlled altitude change works?
thx-
Alex
Crashpilot1000 wrote:I wonder if your solution will do a decent job on keeping the altitude during movement (real flying).
So long
Kraut Rob
Crashpilot1000 wrote:I wonder if your solution will do a decent job on keeping the altitude during movement (real flying).
vpb wrote:I use Mahowik alt-hold 100% the time I fly arround, solid height holding, I just use left stick to yaw.
dramida wrote:I tested in-flight altitude hold and in does a far better job than previous R1170. For me was good enough the altitude hold behavior during fast flight. I can see it compensate the throttle when leaning also.
Improvement: setting hower throttle to the point where Alt Hold is activated is strange , i prefer 50% throttle. (or at least a define)
Why? because i want to know it keeps its altitude even if it's far above and i can't say if it is climbing or not and after some ups and downs you may be loosing the alt hold spot on your remote.... (aerial photos)
#define VBAT // uncomment this line to activate the vbat code
#define VBATSCALE 58 // change this value if readed Battery voltage is different than real voltage
#define VBATNOMINAL 168 //
#define VBATLEVEL1_3S 140 //
#define VBATLEVEL2_3S 132 //
#define VBATLEVEL3_3S 125 //
#define VBATLEVEL4_3S 120 // if vbat ever goes below this value, permanent alarm is triggered
#define NO_VBAT 60 // Avoid beeping without any battery
dramida wrote:It works fine that release. One point to mention, i observed in this last version that arming the copter with yaw right in not always working.
Sometimes when i try to arm the copter, i hear a very short beep and green led from Crius AIOP blinks also shortly. Nothing happens after. After several atempts, copter arms. I checked all EPA of remote and the signals are right, between 1000 and 1100us for left and 1900 and 2000us for right yaw.
Needless to say that when i upload old R1177, things comes back to normal. Anyone has the same issue?
mahowik wrote:dramida wrote:It works fine that release. One point to mention, i observed in this last version that arming the copter with yaw right in not always working.
Sometimes when i try to arm the copter, i hear a very short beep and green led from Crius AIOP blinks also shortly. Nothing happens after. After several atempts, copter arms. I checked all EPA of remote and the signals are right, between 1000 and 1100us for left and 1900 and 2000us for right yaw.
Needless to say that when i upload old R1177, things comes back to normal. Anyone has the same issue?
Probably because of 3rd point from viewtopic.php?f=8&t=2371&start=320#p26473![]()
i.e.:
3) protection from ARM if BARO activated
dramida wrote:I think something works not as expected in this protection routine, i can assure i wasn't in baro mode and all i had to do was to try a few times and then armed...
dramida wrote:It works fine that release. One point to mention, i observed in this last version that arming the copter with yaw right in not always working.
Sometimes when i try to arm the copter, i hear a very short beep and green led from Crius AIOP blinks also shortly. Nothing happens after. After several atempts, copter arms. I checked all EPA of remote and the signals are right, between 1000 and 1100us for left and 1900 and 2000us for right yaw.
Needless to say that when i upload old R1177, things comes back to normal. Anyone has the same issue?
mahowik wrote:dramida wrote:I tested in-flight altitude hold and in does a far better job than previous R1170. For me was good enough the altitude hold behavior during fast flight. I can see it compensate the throttle when leaning also.
Improvement: setting hower throttle to the point where Alt Hold is activated is strange , i prefer 50% throttle. (or at least a define)
Why? because i want to know it keeps its altitude even if it's far above and i can't say if it is climbing or not and after some ups and downs you may be loosing the alt hold spot on your remote.... (aerial photos)
In first attempt the main goal was to check VARIO pid controller works or not. And of course now we can improve and add some features there
Let's discuss and sort out possible solutions, because i have too much points in my mind on this
Current implementation:
(+) when you activate the althold it will keep altitude immediately, i.e. it can be used to safe your copter during the activation
(+) initial throttle, i.e. throttle for hovering is taken as current throttle value on althold activation
(-) center is not 50% throttle, but if you need to have this in center, you can just reactivate the althold. I.e. just set the throttle stick to desired position and turn off/on the switch of althold quickly.
(-) as for now, predefined "throttle expo curve" also used for setting desired rate/vario and it's good if you activate the althold at the MID expo point (it's set in GUI and in right tuned config it equals to hover point, i.e. value of the initial throttle for hovering)
BUT if althold activated in point of throttle which in diff with MID expo point, it will be not usefull for vario regulation, e.g. MID_expo=40% and althold_activation=60%, it means ascending will be too fast, descending will be too low, because you are not in the center of expo curve...
Desired implementation:
1) center is 50% throttle
2) max rate/vario set with define
3) to have a beeps/light signaling during ascend/descend altitude OR best choice to have feedback/telemetry from flight controller to pilot (i'm experimenting with frsky downlink telemetry to have beeps on my TX)
4) need to predefine own expo curve with 50% center OR probably we don't need expo for rate/vario stick controlling at all, if all range about +/-3..5m/s?
5) (not obligatory but nice to have) safe function when althold deactivated... e.g. when you turn off the althold, throttle will be changed smoothly (in 2-3 seconds) from last althold's throttle to current throttle value to have time to react and adapt throttle after althold deactivation...
(+) proportional stick movement to have the same ascend/descend rate
(-) you need to tune initial throttle, i.e. throttle for hovering, because with this approach you should have possibility to activate althold with any thottle stick position. E.g. with #define INITIAL_THROTTLE_HOLD_FROM_MID_EXPO_POINT (Predefined initial throttle for AltHold will be calculated from MID (middle/hover) point of expo throttle from GUI).
But probable it has more advantage than disadvantage
(-) visible disadvantage - it will required to move stick to center after activation
Pls. provide you thoughts on this. I.e. we need to collect requirements before the next implementation step
Please check
thx-
Alex
dramida wrote:Right now i have issues with arming the copter ...i wrote earlier about this.
mahowik wrote:dramida wrote:Right now i have issues with arming the copter ...i wrote earlier about this.
I have not reproduced this issue with my AIO...
Return to Software development
Users browsing this forum: No registered users and 0 guests