HobbyKing.com New Products Flash Sale
Reply
Thread Tools
Old Feb 02, 2013, 09:29 AM
Registered User
idonasch's Avatar
Germany, Berlin
Joined Jun 2004
73 Posts
Quote:
Originally Posted by Odysis View Post
ideally, all 3 axes are seperate. From heli flybarless controllers, a computer can be used to set PID coefficients, then an overall gain if desired can be set inflight.

Aircraft inertia, stability etc has a huge effect on the PID. A trainer will need a much different setup to a 3D machine. Servo delay, speed and deadband also play a role.
thanks for the feedback, you confirmed what I was expecting but not hoping for.

anyways, did some flight tests today (in 2C/35F) and noticed that:
- the adjustments of D/I had only marginal effect.
- the effect on P was as expected.
- landing in the rotor of the hill was as smooth as silk and almost hands-off with the current setup (boring)!
- the gain for ailerons could be much more aggressive.

My goal is having the plane ride out any gusts and not get into oscillations. I guess I need to widen the D/I range a little bit more to see some real effect. the current range seems to be [-0.015..0.015] for I, [-0.24..+0.24] for D and [-0.12..0.12] for P. the result of the equation should be in the [-500..500] range (usec), with all gains wide open. noobee: please correct me if I'm missing something.

have to think about a computer interface, but don't want to lug a laptop to the hill...
idonasch is offline Find More Posts by idonasch
Last edited by idonasch; Feb 02, 2013 at 10:00 AM.
Reply With Quote
Sign up now
to remove ads between posts
Old Feb 02, 2013, 10:57 AM
Registered User
Joined Dec 2006
1,444 Posts
i have the openlog serial logger (if i can find it) that writes to a microsd card (https://www.sparkfun.com/products/9530), so it can log quite a bit of data. the challenge to avoid causing the serial write operations to block (which it currently will if the tx hardware fifo is full).


Quote:
Originally Posted by Alan Hopper View Post
noobee,
just looked back at some old pid code of mine and discovered I had terms to adjust the proportion of the demand signal used for both p and d terms, I think this is called 'setpoint weighting'. It is all slowly comming back to my cold filled head. In previous goes at similar stuff I added a logging feature to my rx which contiuously stored control state in a circular buffer until a signal was sent from the tx, this then stopped writing so the data could be retrieved at the end of the flight, very handy for inflight testing.

Alan
noobee is offline Find More Posts by noobee
Reply With Quote
Old Feb 02, 2013, 11:04 AM
Registered User
Drezed's Avatar
United States, VA, Spotsylvania
Joined Jun 2009
283 Posts
Programming question

First, let me say thank you to all that have contributed your time to this! I realize the goal is to produce an open source controller, but I have a question regarding the V2 module. Is it possible to use the dual aileron option to use ESC's, as opposed to servos? I am going to be experimenting with a tilt wing, and would like to use the V2 to stabilize the roll axis, using 2 motors/ESC's. As far as programming connections to the board, has anyone come up with a solid method(short of buying the jig sold by HobbyKing)?

Thanks in advance,
Jeff
Drezed is offline Find More Posts by Drezed
Reply With Quote
Old Feb 02, 2013, 11:33 AM
Registered User
Joined Dec 2006
1,444 Posts
GREAT feedback! i will try to address the points and questions below.

- but first, is your plane using normal mix or delta mix?

- and second, the PID parameters are per axis (will describe in a picture later below).

- the one thing to be careful about playing with increasing gains is to make sure that math operations do not overflow. previously, i mentioned that you can increase the sensor range, but i think it might be better to reduce the output attenuation instead to achieve the same thing (and to prevent overflow during the pid compute).

Code:
    for (i=0; i<3; i++) {
      // vr_gain/128, stick_gain/256, master_gain/512
      output[i] = ((((int32_t)output[i] * vr_gain[i] >> 7) * stick_gain[i]) >> 8) * master_gain >> 9;
    }
- right now, the stabilizer is just "dampening" because the setpoint, which is the target roll rate, is fixed at zero, regardless of the stick position. there are 2 ways to let the stick influence the eventual rotation rate. one way is to let the stick control the setpoint as you mentioned, the other way is to mix the pid result with the stick and optionally control the gain through the stick (stick position gain). we are currently using the second method.

- the pid parameters are essentially basic default of 500 at this time. i believe Kp or proportional component is the most dominant. next would be Kd, which helps reduce oscillations even with a more aggressive Kp. finally Ki, which i think is least useful for the dampening case and its impact is also limited by the pid windup limit.

Code:
      sum_iterm[i] = constrain(sum_iterm[i] + ((ki[i] * err) >> PID_KI_SHIFT), -PID_I_WINDUP-1, +PID_I_WINDUP);
- the axis are quite independent, hence the pid parameters for each axis should be tuned independently. in my test with my 3d plane, i can get the roll axis to oscillate easily but not the yaw axis.

- i can answer your last question easily. move south to a warmer climate

- i've attached a picture of the current processing pipeline. some key notes: pid parameters are per axis, setpoint is currently 0 for dampening-only behavour. the VR controls the result of the pid compute, not just the Kp component. the VR also controls the reversing function. master gain affects all 3 axes by the same factor. the VR, STICK, and MASTER gains are all <= 1.0 in magnitude (approx), so they are really attenuation instead. the mixer is an important component - with normal mixing, the relation between rx and servo is straightforward. with delta/vtail, it is somewhat more tricky (be we made it simpler by having the stabilizer accept rx roll, pitch yaw and do the mixing).




Quote:
Originally Posted by idonasch View Post
I did some flight testing yesterday to optimize the PID coefficients. I hacked a version were the pots control P/I/D instead of gain. my sacrificial testbed is an electric combatwing.com XL and this is what I was noticing:
- I can induce oscillations in pitch but not on roll, probably because the plane is less stable around pitch. good, that makes tuning easy!
- if I give it a quick down (pitch) it starts oscillating if I or D are set too high. (I'll update this when I re-test with a little more granual PID setting, oops, programmed the pot scaling wrong...)
- oscillations can be controlled by reducing aux/gain. I could set this in flight from 0-200% (another hack!)
- D seems to control oscillation frequency.

Unfortunately I'm not a control engineer so please forgive me if my questions are stupid or obvious.

Questions:
- inducing oscillations by pitching down is probably because the stick setting is not reflected in the setpoint which is controlling pitch rate. right? I guess noobee is going to address that later. so far it actually helps with the PID evaluation.
- if setpoint is also controlled, should that be scaled by 1/P to match the gyros roll rate value or is that a different coefficient I have to deal with? if yes, can I use gain?
- since the plane has different stability rates on all three axises, do I need to tune all 3 PID coefficients separately or is the gain sufficient? I'm testing only pitch since it makes it so easy.
- are the PID coefficients tuned to the inertia of the plane and servo or to the mems gyro?
- the answers to the last two questions are important for the progress of the project, because in the worst case we need a way to set all 9 PID coefficients separately, that's how the quadcopter folks do it.
- any voodoo hints to get suitable weather condition?

I will keep you updated after more flight testing.
cheers
ingo
noobee is offline Find More Posts by noobee
Reply With Quote
Old Feb 02, 2013, 01:08 PM
Registered User
Joined Dec 2006
1,444 Posts
the impact of the pid parameters will vary across plane types and across axis of the same plane. so we have 9 parameters to adjust K[x][y] for x in [p, i, d] and for y in [roll, pitch, yaw]. in your plane, you need more roll gain. in my plane, i needed to reduce it. i think a good balance would be to enable exponential gain with a higher max value.

my impression is that Kp is most important, followed by Kd and then Ki. in fact, Kp and Kd alone is probably sufficient (for the dampening case). Ki is useful if you want to eliminate "offset" errors, because the error will accumulate, or integrate, over time eventually forcing the output to change. so it is useful in cases like attitude hold for example. if there is an attitude or heading error, then the I term will accumulate until the output correction is large enough to cause a change.

i don't quite understand how you derive the decimal factors like 0.015. is it a ratio or something else? 500 is just the default and nominal scaling factor. it should be unit-less. internally, even though Kp, Ki and Kd are all initialized to 500 as default, they are weighted differently, with the following ratio -- Kp : Ki : Kd == 1/8 : 1/64 : 1/4, so Ki=500 contributes less than kd=500 by a factor of 16.

there are several other factors to consider.
- the input range of gyro and setpoint. right now gyro input is a 16bit value (2000 deg/sec full range) but clamped at [-8192, 8191] to the pid controller.
- the interval between pid compute calls. i believe it is important keep that constant. otherwise, we would need to scale up and down Kd and Ki to match the new time interval. right now, we initiate a compute every 10ms.
- the accumulation of the I term is bounded by the WINDUP define. i don't know how to tune that well, except to start logging and seeing the effect of various limits. but i don't want to turn this into a grad school project
- be careful about bit overflow

the computer interface would be nice, but i doubt we have enough ram space to support it comfortably with the atmega168pa (total 1k sram) without throwing out more arduino lib routines and going straight to avr lib. without serial functions, we have about or atleast 30% free sram. flash is not a problem, though.

thanks for your observations and notes again.


Quote:
Originally Posted by idonasch View Post
thanks for the feedback, you confirmed what I was expecting but not hoping for.

anyways, did some flight tests today (in 2C/35F) and noticed that:
- the adjustments of D/I had only marginal effect.
- the effect on P was as expected.
- landing in the rotor of the hill was as smooth as silk and almost hands-off with the current setup (boring)!
- the gain for ailerons could be much more aggressive.

My goal is having the plane ride out any gusts and not get into oscillations. I guess I need to widen the D/I range a little bit more to see some real effect. the current range seems to be [-0.015..0.015] for I, [-0.24..+0.24] for D and [-0.12..0.12] for P. the result of the equation should be in the [-500..500] range (usec), with all gains wide open. noobee: please correct me if I'm missing something.

have to think about a computer interface, but don't want to lug a laptop to the hill...
noobee is offline Find More Posts by noobee
Reply With Quote
Old Feb 02, 2013, 01:35 PM
Registered User
idonasch's Avatar
Germany, Berlin
Joined Jun 2004
73 Posts
disregard
idonasch is offline Find More Posts by idonasch
Last edited by idonasch; Feb 02, 2013 at 01:50 PM.
Reply With Quote
Old Feb 02, 2013, 01:49 PM
Registered User
idonasch's Avatar
Germany, Berlin
Joined Jun 2004
73 Posts
Quote:
Originally Posted by noobee View Post
...
- but first, is your plane using normal mix or delta mix?

...
Code:
    for (i=0; i<3; i++) {
      // vr_gain/128, stick_gain/256, master_gain/512
      output[i] = ((((int32_t)output[i] * vr_gain[i] >> 7) * stick_gain[i]) >> 8) * master_gain >> 9;
    }
...
thanks for quick reply. well I used to live in florida for 17 years, thats the time of year when I miss it.

I'm using delta mix, zagi type sacrificial plane. took me two days to figure out why your mixing code is actually working and doesn't need center position compensation. well, I "fixed" it with the result that I almost hid my flying buddy... it's backed out now.

remark on the pid computation: don't use shift operators when dealing with signed data, you're doing 1's complement arithmetic. btw, the pid routine take less then 300usec (I measured!) even some long divs are not killing you. the compiler is now also smart enough to figure out then it can use a shift (unsigned value and div by pow^2 or sum of pows^2)

on the way back from lunch I had an idea (hope there was blood left in the brain) we could easily add a self learning feature that calculates roll rate per stick position. these values can then be used for the setpoint caclulation and maybe also for PID tuning. and this is how it should work:
- by adding dual rate to the gain input we can set the gain below/above min/max gain. lets call this learn and save settings.
- in learn mode you wring out the plane (gain is off in this mode), roll it, loop etc. just make sure not to stall it! the unit calculates the ratio between stick input and gyro values (roll rate/stick).
- what we get is:
* direction of movement
* gyro (roll rate) calibration
* plane inertia (lag/slope between servo setting and roll rate)
- then test fly with the newly calculated values by adjusting the gain.
- start-over will erase the values and goes back to learn mode.
- save settings to eeprom in save mode (can be done after landing)
- settings will be applied on powerup.

what do you think? no computer interface needed! I just need help with the math, to cold to test more then one iteration per day

cheers
ingo
idonasch is offline Find More Posts by idonasch
Reply With Quote
Old Feb 02, 2013, 02:14 PM
Registered User
idonasch's Avatar
Germany, Berlin
Joined Jun 2004
73 Posts
Quote:
Originally Posted by noobee View Post
...

i don't quite understand how you derive the decimal factors like 0.015. is it a ratio or something else? 500 is just the default and nominal scaling factor. it should be unit-less. internally, even though Kp, Ki and Kd are all initialized to 500 as default, they are weighted differently, with the following ratio -- Kp : Ki : Kd == 1/8 : 1/64 : 1/4, so Ki=500 contributes less than kd=500 by a factor of 16.
I assumed Kx at max +-1000 and max gain (factor 1). divide 1000 by the shift adjustment (div by 8, 64, 4, resp), at the end the output is scaled by 1/1024 (>>10). that's how I cam up with these numbers. since the output is added to the PPM, it should max out at +-500 usec. (max throw!)

Quote:
there are several other factors to consider.
- the input range of gyro and setpoint. right now gyro input is a 16bit value (2000 deg/sec full range) but clamped at [-8192, 8191] to the pid controller.
I interpreted the data sheet that the number returned is the rate in deg/sec which would be [-2000..2000]
Quote:
...
i don't know how to tune that well, except to start logging and seeing the effect of various limits. but i don't want to turn this into a grad school project
...
I might have to peek into other projects code... ardupilot comes to mind....
Quote:
...
the computer interface would be nice, but i doubt we have enough ram space to support it comfortably with the atmega168pa (total 1k sram) without throwing out more arduino lib routines and going straight to avr lib. without serial functions, we have about or atleast 30% free sram. flash is not a problem, though
....
regarding computer interface, think about my previous reply, learn mode etc....

the arduino libs are not much overhead. the linker optimizes unused stuff out. The only thing I would consider is to use the FastIO library that someone earlier in the thread mentioned, but only for speed, not because of size. code is at 10k right now.
I think I poked my nose enough into the compiler output (avr-objdump -d *.elf). just make sure strings are in the flash, use F() (e.g. Serial.print(F("long and useless string example")); )

happy flying and good night for today
ingo
idonasch is offline Find More Posts by idonasch
Reply With Quote
Old Feb 03, 2013, 11:06 AM
Registered User
Joined Dec 2006
1,444 Posts
hey

unfortunately, the current code does not apply to escs at this time, i think, for two key reasons:

1. we'll need to input the throttle channel, modulate and pass that to the escs.

2. some escs (eg simonk firmware) are capable of higher rates (>> 200Hz) while the current code uses software-based pwm and output at 50-100Hz to drive servos. hence, those systems usually use the hardware pwm engines to drive the escs. i'm not exactly sure if the higher refresh rate is critical to stability, but that seems to be the common practice.





Quote:
Originally Posted by Drezed View Post
First, let me say thank you to all that have contributed your time to this! I realize the goal is to produce an open source controller, but I have a question regarding the V2 module. Is it possible to use the dual aileron option to use ESC's, as opposed to servos? I am going to be experimenting with a tilt wing, and would like to use the V2 to stabilize the roll axis, using 2 motors/ESC's. As far as programming connections to the board, has anyone come up with a solid method(short of buying the jig sold by HobbyKing)?

Thanks in advance,
Jeff
noobee is offline Find More Posts by noobee
Reply With Quote
Old Feb 03, 2013, 11:31 AM
Registered User
Joined Dec 2006
1,444 Posts
Quote:
Originally Posted by idonasch View Post
thanks for quick reply. well I used to live in florida for 17 years, thats the time of year when I miss it.

I'm using delta mix, zagi type sacrificial plane. took me two days to figure out why your mixing code is actually working and doesn't need center position compensation. well, I "fixed" it with the result that I almost hid my flying buddy... it's backed out now.
i do suspect that my delta/vtail mix modes are not optimal still. they seem to result in too little throw, particularly for the corrections. but that may be because i'm not use to delta setups.

Quote:
Originally Posted by idonasch View Post
remark on the pid computation: don't use shift operators when dealing with signed data, you're doing 1's complement arithmetic. btw, the pid routine take less then 300usec (I measured!) even some long divs are not killing you. the compiler is now also smart enough to figure out then it can use a shift (unsigned value and div by pow^2 or sum of pows^2)
ah, this is interesting. i think this is implementation dependent and i believe atmega use the arithmetic shift operation, which should work in this case (otherwise we should see weird behavior early on). when i tried using k / n where n is a power of 2, the compiler keeps generating code to call the div library function, which seems very inefficient. agreed that corner cases are not handled (eg -1 >> 1 is still -1).

Quote:
Originally Posted by idonasch View Post
on the way back from lunch I had an idea (hope there was blood left in the brain) we could easily add a self learning feature that calculates roll rate per stick position. these values can then be used for the setpoint caclulation and maybe also for PID tuning. and this is how it should work:
- by adding dual rate to the gain input we can set the gain below/above min/max gain. lets call this learn and save settings.
- in learn mode you wring out the plane (gain is off in this mode), roll it, loop etc. just make sure not to stall it! the unit calculates the ratio between stick input and gyro values (roll rate/stick).
- what we get is:
* direction of movement
* gyro (roll rate) calibration
* plane inertia (lag/slope between servo setting and roll rate)
- then test fly with the newly calculated values by adjusting the gain.
- start-over will erase the values and goes back to learn mode.
- save settings to eeprom in save mode (can be done after landing)
- settings will be applied on powerup.

what do you think? no computer interface needed! I just need help with the math, to cold to test more then one iteration per day

cheers
ingo
i'll wait for your changes seems quite challenging to me for the system to learn about the dynamics in flight. and i thought that just trying to detect oscillations and back off on the overall gain was a hard-enough problem
noobee is offline Find More Posts by noobee
Reply With Quote
Old Feb 03, 2013, 11:53 AM
Registered User
Joined Dec 2006
1,444 Posts
the pid scaling are quite arbitrary. the key concerns are not to cause an overflow in the intermediate computation still generate enough output range for the servos (the 500 you mentioned).

i read the itg3200 datasheet differently please let me know if this is wrong. i thought
- the adc output is 16bit
- the full scale range is +/- 2000 deg/sec
that means 4000 deg/s change is expressed over 16bits

if the gyro sensitivity is 1 deg/s, then each deg/s change would result in 2**16 / 4000 = 16.384 LSB/(deg/s).

but the datasheet stated the sensitivity as 14.375 LSB/(deg/s). that means the gyro is capable of reporting 14.375/16.384 = 0.877 deg/s changes.

i did clamp the adc output to [-8192, 8191]., that means that any gyro reading greater than +/- 500 deg/s would be treated as 500 deg/s. the reasons are twofold
1. i think it is really hard to induce that high rotation rate in an r/c plane (but i may be wrong after being able to log the gyro readings).
2. i need to reduce the bits needed during the computation.

btw. i managed to get arduino-cmake building on windows (but i'm not sure if the images are good yet), thanks to peeking at your cmake reference files. and thanks for all your other tips too! i'll need to check how to reduce sram usage. do you know how to dump a memory map of the static allocations?


Quote:
Originally Posted by idonasch View Post
I assumed Kx at max +-1000 and max gain (factor 1). divide 1000 by the shift adjustment (div by 8, 64, 4, resp), at the end the output is scaled by 1/1024 (>>10). that's how I cam up with these numbers. since the output is added to the PPM, it should max out at +-500 usec. (max throw!)


I interpreted the data sheet that the number returned is the rate in deg/sec which would be [-2000..2000]

I might have to peek into other projects code... ardupilot comes to mind....

regarding computer interface, think about my previous reply, learn mode etc....

the arduino libs are not much overhead. the linker optimizes unused stuff out. The only thing I would consider is to use the FastIO library that someone earlier in the thread mentioned, but only for speed, not because of size. code is at 10k right now.
I think I poked my nose enough into the compiler output (avr-objdump -d *.elf). just make sure strings are in the flash, use F() (e.g. Serial.print(F("long and useless string example")); )

happy flying and good night for today
ingo
noobee is offline Find More Posts by noobee
Reply With Quote
Old Feb 03, 2013, 12:09 PM
Registered User
Drezed's Avatar
United States, VA, Spotsylvania
Joined Jun 2009
283 Posts
Quote:
Originally Posted by noobee View Post
hey

unfortunately, the current code does not apply to escs at this time, i think, for two key reasons:

1. we'll need to input the throttle channel, modulate and pass that to the escs.

2. some escs (eg simonk firmware) are capable of higher rates (>> 200Hz) while the current code uses software-based pwm and output at 50-100Hz to drive servos. hence, those systems usually use the hardware pwm engines to drive the escs. i'm not exactly sure if the higher refresh rate is critical to stability, but that seems to be the common practice.
Thank you for the reply! If I'm understanding correctly, the issue is with software vs. hardware modulation. If this is the case, does this rule out using this board for multicopter projects?

Jeff
Drezed is offline Find More Posts by Drezed
Reply With Quote
Old Feb 03, 2013, 01:07 PM
Registered User
idonasch's Avatar
Germany, Berlin
Joined Jun 2004
73 Posts
Quote:
Originally Posted by noobee View Post
...
do you know how to dump a memory map of the static allocations?
avr-nm -Cn FlightStab.elf

n option sorts by address, C option demangles the C++ names. The D and B sections are in ram, D is initialized with data, B is zero initialized. see man page, e.g.: http://manpages.ubuntu.com/manpages/.../avr-nm.1.html
...
000025ea A __data_load_start
000025ea T _etext
0000266a A __data_load_end
00800100 D __data_start
00800100 D ail_vr
00800101 D ele_vr
00800102 D rud_vr
00800103 D ail_in
00800105 D ailr_in
...
00800361 b twi_onSlaveTransmit
00800363 b twi_txBuffer
00800383 B __brkval
00800385 B __flp
00800387 B __bss_end
00800387 N __heap_start
00800387 N _end
00810000 N __eeprom_end
idonasch is offline Find More Posts by idonasch
Reply With Quote
Old Feb 03, 2013, 01:32 PM
Registered User
idonasch's Avatar
Germany, Berlin
Joined Jun 2004
73 Posts
Quote:
Originally Posted by Drezed View Post
Thank you for the reply! If I'm understanding correctly, the issue is with software vs. hardware modulation. If this is the case, does this rule out using this board for multicopter projects?

Jeff
possible up to tri-copter, because only 7 IOs are exposed. 4 inputs, 3 outputs

the multicopter boards are probably a better choice for you. e.g. take a look at the multiwii project. first they more pins exposed which gives you more flexibility, secondly there are plenty open source projects out there to take advantage of the cheap hardware. the only reason I like the RX3S is its form factor. most of these run with the same mcu as the RX3S (also same as Arduino).
I just ported the FlightStab to the KKboard from hobbyking, no big deal if you know your ways around embedded programming. you're probably need to look for firmware that is aerobatic capable. the unknown part is the transition to winged flight and back (even boeing had there problems with it...). make sure your choice can be configured in the field, e.g. with laptop or LCD. a tilt-rotor is new territory and you need to tweak the parameter a lot.

I would start with a tri-copter in Y configuration where the outputs for the front esc's control the rotors and the output for the back rotor effect the swivel servo to keep the fuse horizontal. on 2nd thought, you need to tweak the firmware anyways because the swivel servos should not be influenced by the throttle.

multiwii supports these configurations:
//#define GIMBAL
//#define BI
//#define TRI
//#define QUADP
//#define QUADX
//#define Y4
//#define Y6
//#define HEX6
//#define HEX6X
//#define HEX6H // New Model
//#define OCTOX8
//#define OCTOFLATP
//#define OCTOFLATX
//#define FLYING_WING
//#define VTAIL4
#define AIRPLANE
//#define SINGLECOPTER
//#define DUALCOPTER
//#define HELI_120_CCPM
//#define HELI_90_DEG



ingo
idonasch is offline Find More Posts by idonasch
Reply With Quote
Old Feb 03, 2013, 02:05 PM
Registered User
Drezed's Avatar
United States, VA, Spotsylvania
Joined Jun 2009
283 Posts
Quote:
Originally Posted by idonasch View Post
. you're probably need to look for firmware that is aerobatic capable. the unknown part is the transition to winged flight and back (even boeing had there problems with it...). make sure your choice can be configured in the field, e.g. with laptop or LCD. a tilt-rotor is new territory and you need to tweak the parameter a lot.
Thank you for the input! My goal right now, is just to stabilize the roll axis, and had thought with the ability to have dual aileron input with "flaperon" capability that it would just be a matter of adjusting the center and endpoints for ESC use(showing my ignorance ). I am still considering a true FC board, but this board is fulfilling my need to "tinker". I'll continue to follow progress, as in any event I'll still find some use for the RX3S.

Thanks again,
Jeff
Drezed is offline Find More Posts by Drezed
Reply With Quote
Reply


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Sold Flight Stabilization System with Programing Card Woody_99 Aircraft - Electric - Helis (FS/W) 1 Mar 23, 2012 01:50 PM
Sold Flymentor Flight Stabilization with Field Programmer Woody_99 Aircraft - General - Radio Equipment (FS/W) 0 Mar 17, 2012 08:43 AM
Sold Totally Tricked out 400 size with flight stabilization installed, BNF Woody_99 Aircraft - Electric - Helis (FS/W) 2 Mar 12, 2012 07:56 AM
Wanted FY-30A Flight Stabilization System Casey_S FPV Equipment (FS/W) 0 Mar 05, 2012 03:40 PM