Flying Wing - development done?
Re: Flying Wing - development done?
I have been looking over the 2.0 code for the flying wing before trying it on my FPV funjet....I have a couple of questions:
1. To avoid accidentally disarming the board when gliding and doing aerobatics I need to use the AUX channel BOXARM feature correct? doesn't this disable stick arming and disarming?
2. I know Hamburger added center trim values in the Config.h file....can you use the normal TX trims initially in passthru mode, then rewrite the CONFIG file later?
What impact does trimming the wing while in flying in gryo mode have? I do it on my multicopters, then tweak the ACC cal...or is this just for coarse trims in setting up the model?
3. Does the problems noted above in the thread of using the I terms still exist? there should be no throttle interaction into the PID operation should there (except for PID gain,if that feature is used)?
4.I notice that in the regular code, the I error terms are zerod every time you idle the throttle, which is fine for a multi that does not glide...but what happens in the plane when gliding...seems this kills the I term corrections while gliding...any work around aside from keeping throttle above 1100?
5. It seems that the altitude hold would work on a wing also if set up correctly...anyone tired this? what PID values? on my Funjet, it might be better to use the BaroPID term to modify (in a constrained manner) the pitch outputs while leaving the throttle constant...small elevator changes would easily correct for altitude changes...this is the way some RTH capable OSDs manage altitude hold...
thanks for the help....great job guys!
1. To avoid accidentally disarming the board when gliding and doing aerobatics I need to use the AUX channel BOXARM feature correct? doesn't this disable stick arming and disarming?
2. I know Hamburger added center trim values in the Config.h file....can you use the normal TX trims initially in passthru mode, then rewrite the CONFIG file later?
What impact does trimming the wing while in flying in gryo mode have? I do it on my multicopters, then tweak the ACC cal...or is this just for coarse trims in setting up the model?
3. Does the problems noted above in the thread of using the I terms still exist? there should be no throttle interaction into the PID operation should there (except for PID gain,if that feature is used)?
4.I notice that in the regular code, the I error terms are zerod every time you idle the throttle, which is fine for a multi that does not glide...but what happens in the plane when gliding...seems this kills the I term corrections while gliding...any work around aside from keeping throttle above 1100?
5. It seems that the altitude hold would work on a wing also if set up correctly...anyone tired this? what PID values? on my Funjet, it might be better to use the BaroPID term to modify (in a constrained manner) the pitch outputs while leaving the throttle constant...small elevator changes would easily correct for altitude changes...this is the way some RTH capable OSDs manage altitude hold...
thanks for the help....great job guys!
Re: Flying Wing - development done?
1. as long as motor is running at more than minthrottle you cannot disarm with TX sticks
2. yes, but TX trims only work in passtrhough mode as expected. In other modes (acro/level) the MWii wll try and correct to what it thinks is level
3. not sure what you mean by I term problem
4. not sure, you may be right. Try it out and report back
5. sounds like it could work - I have only gyro+acc in the plank, so no experience.
Currently in level mode I find the algorithm is missing one tuning option. The TX stick inputs and measured angles are always treated equal. Imho this deserves a tunable proportional factor. Example: when tilting forward I want the MWii to produce more up-pitch for correction. Changing Level-P does this but also changes interpretation of stick input proportions. Maybe you can avoid this shortcoming by adjusting pushrods.
Please report back your findings.
2. yes, but TX trims only work in passtrhough mode as expected. In other modes (acro/level) the MWii wll try and correct to what it thinks is level
3. not sure what you mean by I term problem
4. not sure, you may be right. Try it out and report back
5. sounds like it could work - I have only gyro+acc in the plank, so no experience.
Currently in level mode I find the algorithm is missing one tuning option. The TX stick inputs and measured angles are always treated equal. Imho this deserves a tunable proportional factor. Example: when tilting forward I want the MWii to produce more up-pitch for correction. Changing Level-P does this but also changes interpretation of stick input proportions. Maybe you can avoid this shortcoming by adjusting pushrods.
Please report back your findings.
Re: Flying Wing - development done?
Hamburger wrote:1. as long as motor is running at more than minthrottle you cannot disarm with TX sticks
actually, Ias I interpret the code, it is as long as the throttle is above MINCHECK (1100 default)...and thats my point exactly...gliding by definition is zerod throttle...does using the ARM box, prevent stick disarming?if I am following the nested else ifs correctly, it does...but I would like independent confirmation...
2. yes, but TX trims only work in passtrhough mode as expected. In other modes (acro/level) the MWii wll try and correct to what it thinks is level
so they act like normal...ie changing trim from WING_x_MID is interpreted as control input...so you could change trims in flight to even trim level in level mode, but that would be mistrimmed in gyro mode....I actually use this...my flight mode (gyro, gyro+ACC, etc.) each one has a different trim memory on the TX, so I can tweak each mode independently...I was concerned there was some other impact I wasn't aware of...
3. not sure what you mean by I term problem
see post by Gagarien on 11/12/2011 in this thread...
4. not sure, you may be right. Try it out and report back
what would be the impact of only zeroing the I terms when in passthru mode each loop?I could add a conditional that would only zero in passthru...since I always powerup and launch in passthru, then I terms would only be accumulating when in nonpassthru mode later in the air...I understand that if you don't zero them when non-airbourne, that they would saturate...hence the zeroing at throttle below MINCHECK on the RC link...
thanks
Re: Flying Wing - development done?
1. yes, with using arm boxes, you should be safe.
4. PID terms have no impact in passthrough mode. Only thing MWii does in passThrough is mixing aileron+elevator RX inputs and enforcing min/mid/max servo travels
4. PID terms have no impact in passthrough mode. Only thing MWii does in passThrough is mixing aileron+elevator RX inputs and enforcing min/mid/max servo travels
Re: Flying Wing - development done?
thanks....I think you misunderstood my question in #4....the I term error accumulators are initialized to zero every loop if the throttle is less than MINCHECK...my question was what if I added code that only forced them to zero each loop IF passthru was active INSTEAD of if throttle was below MINCHECK....this would allow the terms to be reset to zero when on the ground (when in passthru prior to and after takeoff) or in the air when the LEVEL and/or gyro functions weren't being used to control the roll and pitch axes...this would keep the terms from saturating since they are not in control of the axes...but allow full PID loop control when gliding...
I may have answered my own question about #3....if you are flying around in passthru, the I error terms would max out since they have no effect on attitude...switching out of passthru would give a jump due to those maxed terms....and may explain Gagarien's issue...so it would seem beneficial to have the error terms ALL zeroed out while in passthru mode to avoid jumps when exiting that mode...I think I will modify that code accordingly..
also, you idea of a term for stick gain is good and used in KK controller code....have you found that the stick sensitivity is too low or too high in: gryo mode? level mode? perhaps there should be a "stick gain" term for both modes?
I may have answered my own question about #3....if you are flying around in passthru, the I error terms would max out since they have no effect on attitude...switching out of passthru would give a jump due to those maxed terms....and may explain Gagarien's issue...so it would seem beneficial to have the error terms ALL zeroed out while in passthru mode to avoid jumps when exiting that mode...I think I will modify that code accordingly..
also, you idea of a term for stick gain is good and used in KK controller code....have you found that the stick sensitivity is too low or too high in: gryo mode? level mode? perhaps there should be a "stick gain" term for both modes?
Re: Flying Wing - development done?
Well, I mocked up a system with servos and the config program and experimented a bunch and confirmed that zeroing throttle changes the way the PID loops work by dumping the I term error accumulators totally...something you don't want in a plane application (ie during a glide)....so I made a fix for that....
if (rcData[THROTTLE] < MINCHECK) {
#ifndef FLYING_WING
errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI[YAW] = 0;
errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
#endif .......
and
if (rcOptions[BOXPASSTHRU]) {
passThruMode = 1;
errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI[YAW] = 0;
errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
}
I also saw no reason to have to ARM the system in a plane application and you dont want stick disarming while gliding doing aerobatics....so another small change for that...now if it powers up with an ARM check box active it will arm...you dont have to toggle the option with the TX...you can still disARM and ARM from TX, it just will immediately ARM if it power up with an ARM box active
if (rcOptions[BOXARM] == 0) okToArm = 1;
#ifdef FLYING_WING
okToArm = 1; //arm even if RC option to ARM is active on power up
#endif
will try to flight test later this week...
thanks
if (rcData[THROTTLE] < MINCHECK) {
#ifndef FLYING_WING
errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI[YAW] = 0;
errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
#endif .......
and
if (rcOptions[BOXPASSTHRU]) {
passThruMode = 1;
errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI[YAW] = 0;
errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
}
I also saw no reason to have to ARM the system in a plane application and you dont want stick disarming while gliding doing aerobatics....so another small change for that...now if it powers up with an ARM check box active it will arm...you dont have to toggle the option with the TX...you can still disARM and ARM from TX, it just will immediately ARM if it power up with an ARM box active
if (rcOptions[BOXARM] == 0) okToArm = 1;
#ifdef FLYING_WING
okToArm = 1; //arm even if RC option to ARM is active on power up
#endif
will try to flight test later this week...
thanks
Re: Flying Wing - development done?
Easiest way to always keep it ARMED....
Check all ARM boxes on one of the AUX channels.(low,mid,high)
Then it will always be armed
Check all ARM boxes on one of the AUX channels.(low,mid,high)
Then it will always be armed
Re: Flying Wing - development done?
not on power up...unless you make the change above, it wont ever arm that way! the existing code requires that it not have a BOXARM option active for at least one loop...
Re: Flying Wing - development done?
You have to lower throttle below minthrottle before it Arms.
Re: Flying Wing - development done?
Sorry but you are incorrect....try it...I have many times...
Re: Flying Wing - development done?
Been flying it several times....I started with default PIDs for gyro and I got tiny, sporadic, low magnitude, very fast roll oscillations...at first I thought it was vibration, but it increased with increased airspeed, even with throttle idle(ie dives)...so its PID loop gain...reduced I and D to 0, and P to 2 and it got better, but still was there occasionally at a lower magnitude and the plane is definitely not as "locked in" like it was in turbulence....I am now raising D back again....starting tomorrow at 20...
should I try the gryo smoothing, even if there isn't vibration? I want to get the P gain back up higher for more "locked in", but I want to dampen the loop response time...should I go real high on D? like 50 or more? with P=3 and I=0?
should I try the gryo smoothing, even if there isn't vibration? I want to get the P gain back up higher for more "locked in", but I want to dampen the loop response time...should I go real high on D? like 50 or more? with P=3 and I=0?
Re: Flying Wing - development done?
when it worked for my small 50cm flying wing (deceased now), it ran GYRO-SMOOTHING=15,15,5 P=2.8 I=0.08 D=10 for roll and pitch.
Re: Flying Wing - development done?
And if you have oscilations at Hihgspeed.
You can use Throttle PID attenuation in the gui.
It's a dynamic PID dampener active between half and full throttle.
If you set ex. 0.40 it will deduce PID effect with 40% att full throttle.
You can use Throttle PID attenuation in the gui.
It's a dynamic PID dampener active between half and full throttle.
If you set ex. 0.40 it will deduce PID effect with 40% att full throttle.
- Attachments
-
- TrroPID.png
- (10.97 KiB) Not downloaded yet
Re: Flying Wing - development done?
okay, I've tweaked to the best of my ability on the Funjet....working OK....but not as good as I want or as good as ET guardian or RVOSD stabilization...
the Funjet is setup as a "lite" version with a smaller motor for endurance (I get 20+mins at 1/2 throttle cruising at 45mph)
Vibration is not an issue...currently running gyro averaging (15,15,who cares) and no changes of significance noted but kept it in anyway...nor when I tried LPFs..
here are my PIDs
Pitch 4-0-0
Roll 4-0-20 (remember on a plane pitch axis is inherently stable, roll axis is zero stability)
in gyro mode I still get some microwobbles (see video) but it works
Level 9-010-25
Level works really weird.....it SLOWLY corrects pitch...it quickly corrects ROLL (remember pitch is inherently stable..) but here is the wierd part...if I bank into a turn and hold it a sec, then let go, it stays banked and even CORRECTs to hold that bank...pitch works like usual...slow but it does correct.
I have a video that shows all of this....the staying banked part is really weird...and with those PIDS I occasionally get a ROLL oscillation at higher than cruise speeds...again see the video...I have not isolated it to the gyro loop or the level loop, but if I increase LEVEL P or D it gets worse...
I would like suggestions on:
1. how to eliminate the microwobbles in roll...really would like more roll damping but current is okay...tried higher P and D and got more sporadic micro wobbles more often, although never a major oscillation
2. get the LEVEL loop to lock in the roll axis more and/or eliminate the non bank correction after a turn is released...remember, it actually behaves as if its trying to hold that new bank angle
here is the link to the video of all these things:
http://youtu.be/4o02qMuCe2Y
I have high hopes for this as a wing stabilizer...almost there...
thanks
the Funjet is setup as a "lite" version with a smaller motor for endurance (I get 20+mins at 1/2 throttle cruising at 45mph)
Vibration is not an issue...currently running gyro averaging (15,15,who cares) and no changes of significance noted but kept it in anyway...nor when I tried LPFs..
here are my PIDs
Pitch 4-0-0
Roll 4-0-20 (remember on a plane pitch axis is inherently stable, roll axis is zero stability)
in gyro mode I still get some microwobbles (see video) but it works
Level 9-010-25
Level works really weird.....it SLOWLY corrects pitch...it quickly corrects ROLL (remember pitch is inherently stable..) but here is the wierd part...if I bank into a turn and hold it a sec, then let go, it stays banked and even CORRECTs to hold that bank...pitch works like usual...slow but it does correct.
I have a video that shows all of this....the staying banked part is really weird...and with those PIDS I occasionally get a ROLL oscillation at higher than cruise speeds...again see the video...I have not isolated it to the gyro loop or the level loop, but if I increase LEVEL P or D it gets worse...
I would like suggestions on:
1. how to eliminate the microwobbles in roll...really would like more roll damping but current is okay...tried higher P and D and got more sporadic micro wobbles more often, although never a major oscillation
2. get the LEVEL loop to lock in the roll axis more and/or eliminate the non bank correction after a turn is released...remember, it actually behaves as if its trying to hold that new bank angle
here is the link to the video of all these things:
http://youtu.be/4o02qMuCe2Y
I have high hopes for this as a wing stabilizer...almost there...
thanks
Re: Flying Wing - development done?
Level I can cause drift
Set Level I=0.0
Do a desktopTest.
Run the motor thru the whole register to see if you get vibrations from it.
GYRO-SMOOTHING=15,15,x Can be rised up to 60,60,x
Also try to decrease P to make smaller corrections.
and increase D to make corrections slower.
Set Level I=0.0
Do a desktopTest.
Run the motor thru the whole register to see if you get vibrations from it.
GYRO-SMOOTHING=15,15,x Can be rised up to 60,60,x
Also try to decrease P to make smaller corrections.
and increase D to make corrections slower.
Re: Flying Wing - development done?
Thanks...I have tried all those combos including desktop runup...except higher averaging values...but why would it try to actually hold the new bank angle in level???
Re: Flying Wing - development done?
Alex released a new Dev today.
It contains Acc smooting and some other fixes.
It contains Acc smooting and some other fixes.
Re: Flying Wing - development done?
I am sure that my issues are not vibration related...but thanks anyway...
studying the code I have determined a couple of things:
1. Level D term value is not a derivative gain term...its a max value cap on the Level error input to the inner gyro loop...it has no derivative effect on angle errors...lowering it just reduces max stick input sensitivity and max error correction in the level loop...probably should be 100 in most cases
2. When the level mode is active, the gyro I terms are not used...only the level I term
I am not sure that gyro I terms have much use in plane applications(perhaps that is what you were referring to above)...I don't think that there is any attitude dependent steady state forces in play like in a multi (ie when tipped forward in FF in a multi, the CG is (usually) below the thrust plane and tends to pull the copter back to level...hence you need an I term in gyro mode to prevent movement back to level in FF to counteract that constant force...I cant think of an analogous one in a plane like this)
and after reviewing all the tuning videos I made, I note that the big oscillation in level mode at high speed continues for a while after I switch to gyro only mode...hence I think my Gyro settings need tweaking...I probably need a lot more gain in the LEVEL loop (the perceived pitch returns to level probably were inherent stability) and need more D gain in the roll gyro loop to get rid of the microwobbles and stop the oscillations at high airspeed...will start the tuning process over again with these insights...
one other note...I believe the gyro smoothing formula has an error....adding 1 to the weighted sum puts a +1 bias into the gyro data...the equation settles to +1 instead of 0 with long term 0 gyro input...it should be removed...not critical though since it just adds +1 to all the gyro data which is the smallest error possible...but I can find no reason for it being in the equation...just confused me for a while till I came to the conclusion its an error...
once I get this settled, I want to work on changing the alt hold to a pitch based correction rather than throttle...more suitable to planes
studying the code I have determined a couple of things:
1. Level D term value is not a derivative gain term...its a max value cap on the Level error input to the inner gyro loop...it has no derivative effect on angle errors...lowering it just reduces max stick input sensitivity and max error correction in the level loop...probably should be 100 in most cases
2. When the level mode is active, the gyro I terms are not used...only the level I term
I am not sure that gyro I terms have much use in plane applications(perhaps that is what you were referring to above)...I don't think that there is any attitude dependent steady state forces in play like in a multi (ie when tipped forward in FF in a multi, the CG is (usually) below the thrust plane and tends to pull the copter back to level...hence you need an I term in gyro mode to prevent movement back to level in FF to counteract that constant force...I cant think of an analogous one in a plane like this)
and after reviewing all the tuning videos I made, I note that the big oscillation in level mode at high speed continues for a while after I switch to gyro only mode...hence I think my Gyro settings need tweaking...I probably need a lot more gain in the LEVEL loop (the perceived pitch returns to level probably were inherent stability) and need more D gain in the roll gyro loop to get rid of the microwobbles and stop the oscillations at high airspeed...will start the tuning process over again with these insights...
one other note...I believe the gyro smoothing formula has an error....adding 1 to the weighted sum puts a +1 bias into the gyro data...the equation settles to +1 instead of 0 with long term 0 gyro input...it should be removed...not critical though since it just adds +1 to all the gyro data which is the smallest error possible...but I can find no reason for it being in the equation...just confused me for a while till I came to the conclusion its an error...
once I get this settled, I want to work on changing the alt hold to a pitch based correction rather than throttle...more suitable to planes
Re: Flying Wing - development done?
the +1 was meant to give the correct rounding with integers used. I think it would have to be (divisor/2) instead of 1 but like you said it does not seem to matter too much.
When I was running MWii on my Flying Wing (not delta) the Pitch axis was not auto stable. Now with the current pitcheron it looks different as it behaves more like a conventional plane.
@hwurzburg, Patrik
from your studies and past experience I think the PID algo both for Acro and Level needs some changes for fixed wing flying. Tweaking the PID values does not seem to be sufficient.
For starters, in Level mode the LevelP value influences the impact of both stick input and angle simultaneously with a fixed ratio. simplified: Pterm=LevelP*(2*rxStick+angleFromSensors). If you want full stick control in level mode, you must set levelP to about 9. That may make the correction influence of the measured angleFromSensors to be too much or too little. In my experiments I introduced another configurable factor LevelS to separate the two like Pterm=LevelP*2*rxStick+LevelS*angleFromSensors.
What do you think? Should we try and come up with a revised PID algorithm for Acro and Level for fixed wings?
When I was running MWii on my Flying Wing (not delta) the Pitch axis was not auto stable. Now with the current pitcheron it looks different as it behaves more like a conventional plane.
@hwurzburg, Patrik
from your studies and past experience I think the PID algo both for Acro and Level needs some changes for fixed wing flying. Tweaking the PID values does not seem to be sufficient.
For starters, in Level mode the LevelP value influences the impact of both stick input and angle simultaneously with a fixed ratio. simplified: Pterm=LevelP*(2*rxStick+angleFromSensors). If you want full stick control in level mode, you must set levelP to about 9. That may make the correction influence of the measured angleFromSensors to be too much or too little. In my experiments I introduced another configurable factor LevelS to separate the two like Pterm=LevelP*2*rxStick+LevelS*angleFromSensors.
What do you think? Should we try and come up with a revised PID algorithm for Acro and Level for fixed wings?
Re: Flying Wing - development done?
today result is I still have roll micro wobbles, but no sustained oscillations in gyro mode with roll 3-0-25....tried more D,up to 40...just oscillations at high speed..
-next outing I will lower Roll P some more....but I dont want to lose the gyro smoothing in turbulent wind (this week is 12mph gusts to 17 every day)...may have to try throttle PID also, but limit it to only the inner gyro loop...but that wont work if I keep throttle at cruise and dive...so it may only be a partial solution..
-level is now 5-0-100, so I have SOME rc control at P=5, but it still does not return to level from a bank...this is driving me nuts...I let it fly in circles for 2 minutes and it never came back to level???? what is going on? on the bench I get working leveling correction, ie surface deflection...but in the air, nothing...do this imply that I may need a gain of like 20 or 30 on the P?!
@hamburger
I think its a good idea, although RVOSD and ET Guardian also de-sensitize the rc commands in level or fly-by-wire modes...but I also think that since the Pitch and Roll axis are so different in stability in a plane, that we may also need separate LEVEL pid controls, both the above stabilizers do (although you cant tell for sure if they affect the inner or outer loops PID or both, since they dont have a gyro only mode)...
there is no reason why we cant perform as well as the other stabilizers...heck, even the $15 KK board is working well in gyro mode as a stabilizer (OpenAero)..
-next outing I will lower Roll P some more....but I dont want to lose the gyro smoothing in turbulent wind (this week is 12mph gusts to 17 every day)...may have to try throttle PID also, but limit it to only the inner gyro loop...but that wont work if I keep throttle at cruise and dive...so it may only be a partial solution..
-level is now 5-0-100, so I have SOME rc control at P=5, but it still does not return to level from a bank...this is driving me nuts...I let it fly in circles for 2 minutes and it never came back to level???? what is going on? on the bench I get working leveling correction, ie surface deflection...but in the air, nothing...do this imply that I may need a gain of like 20 or 30 on the P?!
@hamburger
I think its a good idea, although RVOSD and ET Guardian also de-sensitize the rc commands in level or fly-by-wire modes...but I also think that since the Pitch and Roll axis are so different in stability in a plane, that we may also need separate LEVEL pid controls, both the above stabilizers do (although you cant tell for sure if they affect the inner or outer loops PID or both, since they dont have a gyro only mode)...
there is no reason why we cant perform as well as the other stabilizers...heck, even the $15 KK board is working well in gyro mode as a stabilizer (OpenAero)..
-
- Posts: 506
- Joined: Thu May 05, 2011 8:13 am
- Location: Slovenia
Re: Flying Wing - development done?
hwurzburg wrote: it stays banked and even CORRECTs to hold that bank...pitch works like usual...slow but it does correct.
thanks
Hello!
Your observations can be explained with the fact that banked airplane gets into balanced (coordinated) turn in which the G force have same direction as when flying unbanked (last picture in 1). So the electronics only keeps that position!
1. http://selair.selkirk.ca/Training/Aerod ... n-lift.htm
Regards
Andrej
Re: Flying Wing - development done?
duh! I'm a full scale pilot ! I should have guessed that from my unusual attitude training! if my inner ear cant tell when I'm in a mild coordinated turn, then this board sure cant either......then how in the world do the other stabilizers manage it? my RVOSD in fly by wire mode will level the wings after I release the sticks from a coordinated turn....guess they use the heading info from the gps after stick release to zero the rate of turn....okay, I can live with the level as it is...I do think that we should have different P values for roll and pitch in autolevel mode...
flew again this afternoon....lowered the P on roll gyro down to 2-0-15 and microwobbles almost gone....raised level PID to 10-0-100 and got some wobble...backed down to 9-0-100 and its more manageable....roll is aggressively leveled....pitch is pretty puny...hence the need for more P on pitch than roll...I tried to modify the code from:
// 50 degrees max inclination
errorAngle = constrain(2*rcCommand[axis] - GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
#ifdef LEVEL_PDF
PTerm = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;
#else
PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100; // 32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768 16 bits is ok for result
#endif
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
to
// 50 degrees max inclination
errorAngle = constrain(2*rcCommand[axis] - GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
#ifdef LEVEL_PDF
PTerm = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;
#else
if (axis=0) PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/200; // 32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768 16 bits is ok for result
else PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
#endif
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
and it compiles okay but locks up when running on the board and switching to level mode...my C coding skills are over a decade in the past, so I probably screwed something up...but it would be nice to be able to change the roll to be some fraction of the LEVEL P term so that the pitch axis could get more correction than roll since its inherently stable and less sensitive to stick/PID inputs...
flew again this afternoon....lowered the P on roll gyro down to 2-0-15 and microwobbles almost gone....raised level PID to 10-0-100 and got some wobble...backed down to 9-0-100 and its more manageable....roll is aggressively leveled....pitch is pretty puny...hence the need for more P on pitch than roll...I tried to modify the code from:
// 50 degrees max inclination
errorAngle = constrain(2*rcCommand[axis] - GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
#ifdef LEVEL_PDF
PTerm = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;
#else
PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100; // 32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768 16 bits is ok for result
#endif
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
to
// 50 degrees max inclination
errorAngle = constrain(2*rcCommand[axis] - GPS_angle[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
#ifdef LEVEL_PDF
PTerm = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;
#else
if (axis=0) PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/200; // 32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768 16 bits is ok for result
else PTerm = (int32_t)errorAngle*P8[PIDLEVEL]/100;
#endif
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
and it compiles okay but locks up when running on the board and switching to level mode...my C coding skills are over a decade in the past, so I probably screwed something up...but it would be nice to be able to change the roll to be some fraction of the LEVEL P term so that the pitch axis could get more correction than roll since its inherently stable and less sensitive to stick/PID inputs...
Re: Flying Wing - development done?
So in fact the Acc thinks its level because the G-force is balanced?
Kind of if you spin a bucket of water...
And the solution of is to check if the heading is changing?. (Mag or Gps)
If you use Maghold to keep the heading it could break the coordinated turn.
Kind of if you spin a bucket of water...
And the solution of is to check if the heading is changing?. (Mag or Gps)
If you use Maghold to keep the heading it could break the coordinated turn.
Re: Flying Wing - development done?
I think I needed to use if (axis==0)....duh...told you its been years..
Re: Flying Wing - development done?
Surely this has been noted on the multis also somewhere? running autolevel..doing FF, make a smooth turn with bank and yaw and it does level? however, on a multi you would need to keep feeding yaw for coordination after releasing the stick...not likely....immediately you would start slipping in the turn and ACCs would notice and start leveling...
-
- Posts: 506
- Joined: Thu May 05, 2011 8:13 am
- Location: Slovenia
Re: Flying Wing - development done?
PatrikE wrote:So in fact the Acc thinks its level because the G-force is balanced?
If you use Maghold to keep the heading it could break the coordinated turn.
That is why Flying wing and delta wing are probably easier to manage electronically because you don't have separate yaw (rudder) and turns are mostly coordinated!?
Re: Flying Wing - development done?
I have a Radjet 800 from Hobbyking somewhere between HK and here.
When it arrives it will be a candidate to test this.
I will put a AIO MONGOOSE1_0 FC in it and experiment using the mag to correct roll at "level" flight.
When it arrives it will be a candidate to test this.
I will put a AIO MONGOOSE1_0 FC in it and experiment using the mag to correct roll at "level" flight.
Re: Flying Wing - development done?
I can se same tendecy on my airplaneMix to.
It's hard to get it to fly level.
It usually want to fly in a 200m wide cirkel .
When i correct it will bank in the other direction.
Once in a cirkel it keep the bank.(Great for failsafe but not FPV)
It's hard to get it to fly level.
It usually want to fly in a 200m wide cirkel .
When i correct it will bank in the other direction.
Once in a cirkel it keep the bank.(Great for failsafe but not FPV)
Re: Flying Wing - development done?
About okToArm
I tested a little.
Set High and Low Box for arm and it will arm when you switch one time and will stay armed.
hwurzburg wrote:Sorry but you are incorrect....try it...I have many times...
I tested a little.
Set High and Low Box for arm and it will arm when you switch one time and will stay armed.
- Attachments
-
- Settings.png
- (4.42 KiB) Not downloaded yet
Re: Flying Wing - development done?
yep, like I said... all my boxes are checked in AUX1...wanted three active flight modes in that AUX...wont arm, unless you make my code change...then it arms without having to toggle to an UNarm box first...and wont disarm by stick command accidentally in the air...
my setup was...AUX1: low= passthru, mid=gyro only (only ARM checked), high= level....ARM checked in all flight modes...so the code change is a must...
later, I moved the ARM boxes to AUX2 and had AUX2: low=nothing checked(I use this to disarm to allow LCD use...via a mix on a another momentary switch to prevent in air disarming by accident), mid=ARM only (my normal power up setting), high=ARM+BARO...so I have alt hold on this switch...but I can disarm for LCD using another switch and I still use the code change so I don't have to TOGGLE anything at power up to get arming...
my experimentation on this controller in planes has come to an abrupt end when my Funjet flew away and was lost...I was at an FPV fly-in, in a valley, and did not realize that I had a treeline behind me that blocked LOS below 15 deg....3Kft out and 1Kft up behind me I lost video...and the plane...
reaffirming my resolve(which failed with regard to the Funjet) never to fly a plane without RTH....so after the new flight components come in over the next three weeks, I am moving to the Cyclops NOVA OSD which has RTH, crude altitude hold during RTH, and IR autoleveling....I will add a KK gyro board also, since I only need gyro stabilization and not autolevel, so I regretfully leave testing the MultiWii in flying wings....at least for several months....
still use em in my Multis though
my setup was...AUX1: low= passthru, mid=gyro only (only ARM checked), high= level....ARM checked in all flight modes...so the code change is a must...
later, I moved the ARM boxes to AUX2 and had AUX2: low=nothing checked(I use this to disarm to allow LCD use...via a mix on a another momentary switch to prevent in air disarming by accident), mid=ARM only (my normal power up setting), high=ARM+BARO...so I have alt hold on this switch...but I can disarm for LCD using another switch and I still use the code change so I don't have to TOGGLE anything at power up to get arming...
my experimentation on this controller in planes has come to an abrupt end when my Funjet flew away and was lost...I was at an FPV fly-in, in a valley, and did not realize that I had a treeline behind me that blocked LOS below 15 deg....3Kft out and 1Kft up behind me I lost video...and the plane...
reaffirming my resolve(which failed with regard to the Funjet) never to fly a plane without RTH....so after the new flight components come in over the next three weeks, I am moving to the Cyclops NOVA OSD which has RTH, crude altitude hold during RTH, and IR autoleveling....I will add a KK gyro board also, since I only need gyro stabilization and not autolevel, so I regretfully leave testing the MultiWii in flying wings....at least for several months....
still use em in my Multis though
Re: Flying Wing - development done?
In a rth situation goverend by gps would this leaning interfere? Should the plane be totally levelled? Do other commercial systems have magneto or is in their case acc sufficient and why?
I've seen videos of some multiwii flying wings that flew levelled fine...
I've seen videos of some multiwii flying wings that flew levelled fine...
Re: Flying Wing - development done?
I loaded MultiWii_dev_20120504.
Now the plane could fly level. (Airplane Mix)
The change to float acc-values in last dev is working great.
All PID's was original MWii.
Now the plane could fly level. (Airplane Mix)
The change to float acc-values in last dev is working great.
All PID's was original MWii.
Re: Flying Wing - development done?
Great news Patrik . you use a nunchuck as a acc right? I would like to use adxl345 as acc.
Re: Flying Wing - development done?
msev wrote:Great news Patrik . you use a nunchuck as a acc right? I would like to use adxl345 as acc.
Yes I use Wmp & NB in the plane.
I have Adxl345 in a Quad and havn't really tested the Dev yet.
I did some tests on my own based on the "error...adxl345..." thread.
It was better but i still had some drift on it.
I added the Shikra mod and the drift was gone.
But i must test it with the new Dev first before i can be sure.
/Patrik
Re: Flying Wing - development done?
Will you test it on the plane also?
Re: Flying Wing - development done?
Sorry about your loss - I can relate...
Re: Flying Wing - development done?
msev wrote:Will you test it on the plane also?
I plan to put it in the RadJet when i get it from HK.
Sent from HK 2 weeks ago.
Re: Flying Wing - development done?
Hi,
is RTH with GPS supported with Flying Wing ( or Air Plane ) ?
Kayle
is RTH with GPS supported with Flying Wing ( or Air Plane ) ?
Kayle
Re: Flying Wing - development done?
+1 It would be cool if that new eosbandi pid style rth code would be integrated since everyone it seems is having good luck with it.
Although here it would be somewhat different since the plane cant be in one spot but has to circle around.
Although here it would be somewhat different since the plane cant be in one spot but has to circle around.
Re: Flying Wing - development done?
Kayle wrote:Hi,
is RTH with GPS supported with Flying Wing ( or Air Plane ) ?
Kayle
No but it should be quite easy to do.
Use direction to home and compare with heading .
Add the diff to rudder or roll with some limitations on Max throw.
/Patrik
Re: Flying Wing - development done?
No but it should be quite easy to do.
Ok ... Do it Joke
First i will test the stable mode and then go further !
Kayle
Re: Flying Wing - development done?
latest code allows to selectively disable the arm/disarm via TX roll and/or yaw stick.
That should prevent accidental disarming while gliding with zero throttle.
(I mix TX roll and nick for the control surfaces. Now I can limit arm/disarm to the TX yaw and avoid accidental disarming)
That should prevent accidental disarming while gliding with zero throttle.
(I mix TX roll and nick for the control surfaces. Now I can limit arm/disarm to the TX yaw and avoid accidental disarming)
- captaingeek
- Posts: 228
- Joined: Fri Jan 28, 2011 6:42 pm
Re: Flying Wing - development done?
the thread I've been looking for!
Adding mwc to this plane its called a peace drone:
http://www.youtube.com/watch?v=488oom90 ... ata_player
https://plus.google.com/app/plus/mp/865 ... view=photo
Adding mwc to this plane its called a peace drone:
http://www.youtube.com/watch?v=488oom90 ... ata_player
https://plus.google.com/app/plus/mp/865 ... view=photo
- captaingeek
- Posts: 228
- Joined: Fri Jan 28, 2011 6:42 pm
Re: Flying Wing - anyone using it and how?
Hamburger wrote:Hi,
I uploaded my working setup to the google repository here http://code.google.com/p/multiwii/source/browse/#svn%2Fbranches%2FHamburger%2Fr252_FlyingWing.
base: r252 (v1.8p1 with some extra features)
added flying wing:
- one motor on pin 9 (optional) with support in GUI
- working mixing options for typical 2 servo mirrored setup (configurable)
- no need to swap servo connectors (as with dumb dx6i elevon mixing)
- servos: mid- and endpoints configurable
- working passthrough option with aux1<1300 - no visual feedback in GUI yet
- works (but difficult to tune PID parameters)
My settings are in wing500.h. Make your changes here or (in config.h and remove include of wing500.h in multiwii.pde). This file layout is my way to safely deal with Alex' changing defaults in development versions.
Cheers, Hamburger
Cheers,
Hi can you let me know the default pinouts??elevon left /right / throttle?
- captaingeek
- Posts: 228
- Joined: Fri Jan 28, 2011 6:42 pm
Re: Flying Wing - development done?
So motor is pin 9, left wing is a0, right wing is a1.
Code: Select all
#elif defined(FLYING_WING)
#define NUMBER_MOTOR 1
#define PRI_SERVO_FROM 1 // use servo from 1 to 2
#define PRI_SERVO_TO 2
#define SERVO_1_PINMODE pinMode(A0,OUTPUT); // TILT_PITCH - WING left
#define SERVO_1_PIN_HIGH PORTC |= 1<<0;
#define SERVO_1_PIN_LOW PORTC &= ~(1<<0);
#define SERVO_2_PINMODE pinMode(A1,OUTPUT); // TILT_ROLL - WING right
#define SERVO_2_PIN_HIGH PORTC |= 1<<1;
#define SERVO_2_PIN_LOW PORTC &= ~(1<<1);
#define SERVO_3_PINMODE pinMode(A2,OUTPUT); //
Re: Flying Wing - development done?
captaingeek wrote:So motor is pin 9, left wing is a0, right wing is a1.
from what code looks like, just right
You know FW support is in the currrent code v2.1, that link you quoted is so outdated.
- captaingeek
- Posts: 228
- Joined: Fri Jan 28, 2011 6:42 pm
Re: Flying Wing - development done?
yea I figured it was the same code in the current version and was just trying to track it down. is it still the same in 2.2? any other notes on setting this up? hoping to test this weekend.
Re: Flying Wing - development done?
Should be fine.
It just worked.
It just worked.
- captaingeek
- Posts: 228
- Joined: Fri Jan 28, 2011 6:42 pm
Re: Flying Wing - development done?
Does PPM sum work for anyone with this?
Re: Flying Wing - development done?
FW and ppm are not related, so if ppm works it will work with FW. On the other hand, FW does nothing to repair a broken ppm.