MultiWii

Posted: **Mon Feb 21, 2011 12:11 am**

A lot of work on this dev version.
The stable mode is greatly improved

GUI and LCD: D is now positive (to avoid confusion in explanations)

GUI: 3D copter attitude visualization

ALL: RC channels AUX2, CAM1 CAM2 added. only relevant for PPM SUM stream or MEGA boards. On the 328p with a standard receiver, only the first 5 channels are recognized. CAM1 and CAM2 controls are not yet impemented.

ALL: AUX1 and AUX2 switches are fully customizable via a 3 state position. We can activate/deactivate individually level mode (ACC), baro or compass (mag). It's a generic approach which lets other possibilities to control things in the future.
With this principle, it's possible to activate permanently the options you want even if you have only 4 channels (replace the FORCE LEVEL option)

ALL: new level mode
the level mode is completely redesigned with a coherent independant trim
There a now a PI control loop for level mode based on angle estimation.
The old autolevel strength value was a sort of P only control loop.
With the new code, the I term allows to refine the remaining angular error for a better angle positioning accuracy.
with an RC rate = 1, the angle at full stick is around 45deg => a flip should never happen in this mode.

MAIN SOFT: software trim for stable mode
It is now possible to adjust the trim of the level mode to match the same TX trim used for the acro mode.
1) disarm the motors
2) full throttle (must be >1900)
3) full PITCH forward/backward and full ROLL left/right (2 axis possibilities) will trim the level mode according to the neutral angle you want to change. The status LED will blink to confirm each ticks.

MAIN SOFT: new calibration procedure
The ACC calibration differs now from the gyro calibration.
gyro calibration: it's still done at each power on. It's also possible manually as before: min throttle+full pitch backward+full yaw left.
acc calibration: motor disarmed, full throttle up, full pitch backward+full yaw left.

GUI: ACC calibration. there is now a calibrate button to calibrate the ACC directly from the GUI (it resets the soft trim)

LCD: all parameters are now customizable via the LCD thanks to the work initiated by Shirka. This first one is still P for both ROLL&PITCH as it is the most used.

ALL: MAG is still for visualization only (no code control for the moment). BARO is still not working very well with huge amplitude (note it's a code issue, not a baro component issue)

MAIN SOFT: it was in 1.6 but not mentionned. it's possible to arm/disarm motors etheir via min throttle + full yaw stick or full roll stick.

SPECIAL NOTE ABOUT THE PULL-UPS:
- they are now again enable by default
- WARNING if you use I2C devices that don't support 5V.

- If you use a WMP alone: enable it in soft
- If you use a WMP + NK : enable it in soft
- If you use a WMP + BMP020 (5V friendly thanks to its LLC): enable it in soft
- If you use a WMP + (LLC + I2C devices): enable it in soft
- If you use a WMP + direct I2C bus connection I2C devices (not 5V friendly): disable it in soft and use external pull-ups on 3.3V. note that most breakout boards are built with pullups already available.

The code is on the googlecode repository

This code is as usual compatible with everything developed before
including the very low cost setup: WMP only + promini + standard 4ch receiver

Posted: **Mon Feb 21, 2011 4:20 am**

Great big thank you alex... I'm stil on 1pre6...

Sign change on "D" should reduce rcgroups traffic 5% alone

Need to remember how to get code off google now so I can check out the new level mode.

Posted: **Mon Feb 21, 2011 4:28 am**

IN-CREDIBLE!

Alex, you sure produce great work at blinding speed! I can't wait to try this out!

spag

Posted: **Mon Feb 21, 2011 6:17 am**

hi,

just installed 1pre7, tested it holding in hand until now only - everything seems to work fine. (nano clone, wm+ clone, bma020)

but the GUI is very laggy now. looks like video at 1fps

Posted: **Mon Feb 21, 2011 7:51 am**

dodecopter wrote:hi,

just installed 1pre7, tested it holding in hand until now only - everything seems to work fine. (nano clone, wm+ clone, bma020)

but the GUI is very laggy now. looks like video at 1fps

Yeah I'm having the same problem. My computer is very fast, but it has no video card... could this be the problem? Alex, is there a way to disable the 3D aspect of the GUI? Or can you post the requirements for running it (directx, D3D version, etc)

spag

Posted: **Mon Feb 21, 2011 8:10 am**

hi,
this version it too big for a 168, i have removed bat monitoring but it is still 600b too big,
is there anything else i can remove?

yes i have commented the lcd

edit:

just made it fit, might work:)

Posted: **Mon Feb 21, 2011 10:16 am**

Great Job Alex. I will try it asap in my hexa and report the sure fine work.

Posted: **Mon Feb 21, 2011 10:37 am**

my computer handles it mine, but it is a high tech gaming machine

Posted: **Mon Feb 21, 2011 1:12 pm**

Great Job Alex with this great piece of Mastery of coding. I have a question please,

In version 1.6, you had 100 as the wGyro and the invW values but in the pre 1.7, it was changed to 300. What is the basis for this change?

Thank you

1.6

Code: Select all

uint8_t wGyro = 100;         // gyro weight/smooting factor
static float invW = 1.0/(1 + 100);

Pre1.7

Code: Select all

int16_t wGyro = 300;               // gyro weight/smooting factor
  static float invW = 1.0/(1 + 300);

Posted: **Mon Feb 21, 2011 1:33 pm**

This is one of the key to obtain a better stable mode.

This weight traduces the importance of short term angle estimation computed via the Gyro only, this term is much less noisy than the angle estimation computed via the ACC.

But there is a limit: we still need the ACC angle because with a gyro only approach, it's impossible to know the horizon. 300 seems good, I didn't test bigger values.

copterrichie wrote:Great Job Alex with this great piece of Mastery of coding. I have a question please,

In version 1.6, you had 100 as the wGyro and the invW values but in the pre 1.7, it was changed to 300. What is the basis for this change?

Thank you

1.6
Code: Select all
uint8_t wGyro = 100;         // gyro weight/smooting factor
static float invW = 1.0/(1 + 100);
Pre1.7
Code: Select all
int16_t wGyro = 300;               // gyro weight/smooting factor
  static float invW = 1.0/(1 + 300);

Posted: **Mon Feb 21, 2011 1:37 pm**

My computer is 2 years old, but I have a dedicated GeForce, it might help

I didn't test the GUI on another computer.
Maybe I should add a "3D" checkbox to disable the 3D in the gui.
It's maybe possible also to tweak your java runtime, I don't know.

spagoziak wrote:
dodecopter wrote:hi,

just installed 1pre7, tested it holding in hand until now only - everything seems to work fine. (nano clone, wm+ clone, bma020)

but the GUI is very laggy now. looks like video at 1fps

Yeah I'm having the same problem. My computer is very fast, but it has no video card... could this be the problem? Alex, is there a way to disable the 3D aspect of the GUI? Or can you post the requirements for running it (directx, D3D version, etc)

spag

Posted: **Mon Feb 21, 2011 1:58 pm**

Alexinparis wrote:This is one of the key to obtain a better stable mode.

This weight traduces the importance of short term angle estimation computed via the Gyro only, this term is much less noisy than the angle estimation computed via the ACC.

But there is a limit: we still need the ACC angle because with a gyro only approach, it's impossible to know the horizon. 300 seems good, I didn't test bigger values.

Alex, I found this in my research, what is your opinion?

invw = Gyro Sensitivity

Sensitivity – is the sensitivity of your gyroscope it is expressed in mV / (deg / s) often written as mV/deg/s , it basically tells you how many mV will the gyroscope output increase , if you increase the rotation speed by one deg/s. The sensitivity of Acc_Gyro board is for example 2mV/deg/s or 0.002V/deg/s

http://www.starlino.com/imu_guide.html

For my gyro, I had to set that value to 67. This number is from the gyro datasheet.

Posted: **Mon Feb 21, 2011 2:10 pm**

invw = Gyro Sensitivity

you make a confusion between the gyro sensitivity and its weight in the mix formula.

copterrichie wrote:
Alexinparis wrote:This is one of the key to obtain a better stable mode.

This weight traduces the importance of short term angle estimation computed via the Gyro only, this term is much less noisy than the angle estimation computed via the ACC.

But there is a limit: we still need the ACC angle because with a gyro only approach, it's impossible to know the horizon. 300 seems good, I didn't test bigger values.

Alex, I found this in my research, what is your opinion?

invw = Gyro Sensitivity

Sensitivity – is the sensitivity of your gyroscope it is expressed in mV / (deg / s) often written as mV/deg/s , it basically tells you how many mV will the gyroscope output increase , if you increase the rotation speed by one deg/s. The sensitivity of Acc_Gyro board is for example 2mV/deg/s or 0.002V/deg/s
http://www.starlino.com/imu_guide.html

For my gyro, I had to set that value to 67. This number is from the gyro datasheet.

Posted: **Mon Feb 21, 2011 2:52 pm**

Alexinparis wrote:
invw = Gyro Sensitivity

you make a confusion between the gyro sensitivity and its weight in the mix formula.

But is this the line of code that set the Sensitivity?

Code: Select all

gyroFactor = deltaTime/300e5; //empirical, depends on WMP on IDG datasheet, tied of deg/ms sensibility

the 300e5 is the Maximum Angular Velocity (deg./sec) for my gyro and 200e6 is for the WMP.

Posted: **Mon Feb 21, 2011 5:06 pm**

Alexinparis wrote:My computer is 2 years old, but I have a dedicated GeForce, it might help
I didn't test the GUI on another computer.
Maybe I should add a "3D" checkbox to disable the 3D in the gui.

[/quote]

that would be nice.

a older notebook is easily to take with, and its cheap. but often has weak graphiks/onboard without 3D...

my thinkpad x60 (dual core ) has no dedicated graphics too, that might be the problem.

Posted: **Tue Feb 22, 2011 6:04 pm**

Alexinparis wrote:
invw = Gyro Sensitivity

you make a confusion between the gyro sensitivity and its weight in the mix formula.

I believe you are correct. I changed the value for invW to 300 but I have only tested it with Gyro, but Much Improved.

Thanks.

Posted: **Thu Feb 24, 2011 2:12 pm**

GUI: 3D copter attitude visualization

my netbook plaing 3D very very slowly

(

Posted: **Thu Feb 24, 2011 4:55 pm**

Yeah the GUI has a known bug in it that causes a memory leak on some computers. I'm certain Alex will have it nailed down when he finalizes 1.7. And 1.7 is already amazing....what more could be done?!

Posted: **Thu Feb 24, 2011 11:35 pm**

There was a memory leak problem on the 1.pre7 GUI.
I've just uploaded a patch for the GUI.
Without the memory leak problem, it's now smooth, even on my mini pc (small atom n450)
http://code.google.com/p/multiwii/so...se/#svn%2Ftags

Posted: **Fri Feb 25, 2011 10:13 am**

Thanks for fixing that Alex

Posted: **Sat Feb 26, 2011 12:44 pm**

I have one problem uploading to arduino.

I have arduino mega and I defined that. But got this error.
What can I do?

Posted: **Sat Feb 26, 2011 1:02 pm**

what is your arduino version ?

Posted: **Sat Feb 26, 2011 1:10 pm**

I have program: ARDUINO 0022 - 2010.12.24

and board: Duemilanove ATtmega328

Posted: **Sun Feb 27, 2011 12:24 pm**

quadslo wrote:I have program: ARDUINO 0022 - 2010.12.24

and board: Duemilanove ATtmega328

The Duemilanove is not an Arduino Mega board (despite the fact that the chip has the "mega" in its name)

Posted: **Mon Feb 28, 2011 10:48 am**

Tnx for info! It should work now.

Posted: **Mon Feb 28, 2011 3:37 pm**

I just got chance to fly my Flyduino XQuad with FF IMU and pre1.7. Disabled baro and Magneto in code.

Flew just fine with default PID settings. And could be flown with the warped MK 1045 props vibrating like hell.

Stable mode, is as you said - greatly improved. With stock settings and a little bit of stable mode trimming it snapped back to level each time.

Thanks Alex, I really think you outdid yourself this time. I like the way you have also kept the simplicity of the GUI. Thanks for keeping it simple while managing to improve performance each time! Video to come!

Jussi

Posted: **Mon Feb 28, 2011 7:30 pm**

Nice,
So, we are waiting for your video.
I think the next step is the compass implementation as it can be tested inside.
The most complicated part is probably the implementation of baro+Z ACC compensation.

Posted: **Mon Feb 28, 2011 9:20 pm**

Here is that video...just some autolevel and ground effect hover testing.

http://www.youtube.com/watch?v=TR3NYhg-62k

Pilot error cut my testing short :roll:

. This was still with stock PID´s so I think I can improve performance with a little bit of tuning! Looks like we will get some calm days later in the week, so I will go and make a better vid then!

Great work. Looking forward to the compass - but I think you can start to study the datasheet for ]for HMC5883L since that will be the one on the 1.22L FF IMU. And take your time on the Baro/Z-accel. I know that stuff is tricky to code, and you are doing great already! I cant believe how far this has come already!

HMC5883L datasheet:
http://media.digikey.com/PDF/Data%20She ... C5883L.pdf

HMC5883L Errata sheet:
http://media.digikey.com/PDF/Data%20She ... ata%20.pdf

Posted: **Mon Feb 28, 2011 10:22 pm**

Hi 420rcpilot:

I really want to know, how much value you have por autolevel and I values...

also i want to know your PID settings...

thats is very responsitive... very fast...

what is your config please?

THX in advance...

hope your quad is fixed easy...

Posted: **Tue Mar 01, 2011 4:21 am**

The patch is still not working for me.

Putting MultiWiiConf1_pre7_GUI_patch under eclipse, I could only tell it was looping through draw() and processSerialData(), but the conf window was updated only once after the pressing the start button and would not refresh any more. The animation thread was active but I don't have the source to check what it was doing.

The process was showing on top as the top process:

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19754 root 20 0 1473m 122m 23m S 102 3.1 0:37.49 java

It used one core of my dual core CPU and 1.5G virtual memory. I have 4G RAM.

The original 1_pre7 conf used 1.9G RAM. It is still not working, probably due to the new 3D stuff.

I am running 64bit linux with a GeForce 7500LG. Since only 32bit share libraries were included with the zip's, I have to point them to my local 64bit libraries.

Woud there be an option to turn off the 3D stuff without patching the source on my own when 1.7 is released?

Thanks.

Posted: **Tue Mar 01, 2011 11:59 am**

javitech wrote:Hi 420rcpilot:

I really want to know, how much value you have por autolevel and I values...

also i want to know your PID settings...

thats is very responsitive... very fast...

what is your config please?

THX in advance...

hope your quad is fixed easy...

The setup is as follows:

KDA20-22L (980 Kv)
EPP 1045 props
18A plush esc
Flyduino
FreeFlight IMU 1.1 (Only using ITG3200 and BMA180) Looptime was circa 2500 uS
2200 3S 35C lipo

The frame is my own folding design! And there was only prop damage. (Epp dont like cold weather)

All PID settings in the video is stock settings.

I only had to trim the autolevel mode a bit to get it to fly level each time!

Posted: **Tue Mar 01, 2011 2:20 pm**

Hi,

sorry for the crosspost, I also posted on RCG at http://www.rcgroups.com/forums/showpost.php?p=17551337 (did not find any rules?

I cannot run the 1.pre7-patched GUI on MacosX 10.5.8 with latest java installed.
Starting from shell I see

Code: Select all

<some path>/JavaApplicationStub
Invalid memory access of location 0x8 eip=0x37ef77d
Bus error

or when starting application I get additional info:

Code: Select all

Thread 0:
0   dyld                             0x8fe0f630 ImageLoader::hasHiddenExports() const + 0
1   dyld                             0x8fe063a8 __ZN4dyldL18findExportedSymbolEPKcbPPKN11ImageLoader6SymbolEPPKS2_ + 312
2   dyld                             0x8fe0695c dyld::findCoalescedExportedSymbol(char const*, ImageLoader::Symbol const**, ImageLoader const**) + 28
3   dyld                             0x8fe14a9b ImageLoaderMachO::resolveUndefined(ImageLoader::LinkContext const&, macho_nlist const*, bool, ImageLoader const**) + 283
4   dyld                             0x8fe19828 ImageLoaderMachO::doBindIndirectSymbolPointers(ImageLoader::LinkContext const&, bool, bool, bool) + 472
5   dyld                             0x8fe19b23 ImageLoaderMachO::doBind(ImageLoader::LinkContext const&, bool) + 243
6   dyld                             0x8fe103b0 ImageLoader::recursiveBind(ImageLoader::LinkContext const&, bool) + 112
7   dyld                             0x8fe12af7 ImageLoader::link(ImageLoader::LinkContext const&, bool, bool, ImageLoader::RPathChain const&) + 295
8   dyld                             0x8fe05bbf dyld::link(ImageLoader*, bool, ImageLoader::RPathChain const&) + 207
9   dyld                             0x8fe0d9c0 dlopen + 1008

So I setup Processing 1.2.1 and installed ControlP5.
There I can RUN the code ok (can see the GUI window and click - not tested further) via the RUN button,
BUT if I export application, that gives same error as above!

Any hints, please?
Hamburger

One Followup on my own post: I just found if I export application and check the fullscreen option then the application works!

Posted: **Tue Mar 01, 2011 8:42 pm**

While trying to dig up the source of the included jar's, I came across this:

http://forum.jogamp.org/Where-to-downlo ... 09620.html

No problems in finding the jogl though.

I am using 64 bit Nvidia driver version 260.19.36 which provides opengl support. I wonder if that could be not backward compatible.

Posted: **Tue Mar 01, 2011 10:17 pm**

Hi everybody,

i have a small problem that occurred to me first with version 1.6 and continues on into 1.7

when applying full throttle my quad-X starts to rotate (yaw) this happens on FULLTHROTTLE and only on it. 3/4 throttle no problem.
i had no such problems on v 1.4 and 1.5
others in the forum i picked up on the multiwii experienced similar problems.

i tried to lower MAXTHROTTLE and increase the I-value for yaw without any significant improvement.

are there others here that have experienced similar problems?

is it possible that this i due to the implementation of the antigyro glitch?

greets christoph

Posted: **Tue Mar 01, 2011 10:35 pm**

@dynai
It may be explained by the anti yaw jump implementation
(you can try to comment or remove the part of the code between #if MOTOR_NUMBER >3 ... #endif)

@vfbl and Hamburger
I don't know all the compatibility issues about processing running an openGL code. I'm not a java fan :mrgreen:

but processing coding is so convenient
Apparently, issues are present and I'm not sure it's related to a GUI bug.
It's quite easy to remove opengl references (but with no more 3D visualization), I will build an export just for test.

Posted: **Tue Mar 01, 2011 11:19 pm**

thanks

ill check this as soon as possible.. right now i'm a bit short on time. Ill report back.
kind regards

Christoph

Posted: **Tue Mar 01, 2011 11:59 pm**

Hi,

i just gave it a minute and commented that part out and checked it on the gui.
with the anti yaw jump compensation acitve the esc-monitor reacts much less sensitive.
is it possible to encreas the range of the the jump compensation to allow for bigger range?

Code: Select all

#if NUMBER_MOTOR > 3
    //prevent "yaw jump" during yaw correction: the yaw correction should allow the same ammount of motor speed variation in both ways
    if      (rcCommand[THROTTLE]-axisPID[YAW] < MINTHROTTLE) axisPID[YAW] = rcCommand[THROTTLE]-MINTHROTTLE;
    else if (rcCommand[THROTTLE]+axisPID[YAW] < MINTHROTTLE) axisPID[YAW] = -rcCommand[THROTTLE]+MINTHROTTLE;
    else if (rcCommand[THROTTLE]+axisPID[YAW] > MAXTHROTTLE) axisPID[YAW] = MAXTHROTTLE-rcCommand[THROTTLE];
    else if (rcCommand[THROTTLE]-axisPID[YAW] > MAXTHROTTLE) axisPID[YAW] = -MAXTHROTTLE+rcCommand[THROTTLE];
    axisPID[YAW] = constrain(axisPID[YAW],-100-abs(rcCommand[YAW]),+100+abs(rcCommand[YAW]));
  #endif

do i get this right? would increasing the 100 value solve it or will i run into some over/underflow? and what limits would i have to respect?

Code: Select all

axisPID[YAW] = constrain(axisPID[YAW],-400-abs(rcCommand[YAW]),+400+abs(rcCommand[YAW]));

i just tried this at my desk so i have no clue how this will act in real life conditions, but from what i can see on the monitor it look more responsive.

greets Christoph

Posted: **Wed Mar 02, 2011 8:25 am**

Hi,

I think the problem comes from the first 4 lines:

Code: Select all

   if      (rcCommand[THROTTLE]-axisPID[YAW] < MINTHROTTLE) axisPID[YAW] = rcCommand[THROTTLE]-MINTHROTTLE;
    else if (rcCommand[THROTTLE]+axisPID[YAW] < MINTHROTTLE) axisPID[YAW] = -rcCommand[THROTTLE]+MINTHROTTLE;
    else if (rcCommand[THROTTLE]+axisPID[YAW] > MAXTHROTTLE) axisPID[YAW] = MAXTHROTTLE-rcCommand[THROTTLE];
    else if (rcCommand[THROTTLE]-axisPID[YAW] > MAXTHROTTLE) axisPID[YAW] = -MAXTHROTTLE+rcCommand[THROTTLE];

After thinking about it, something is not efficient here and I would make a first test with the suppression of those lines.

I think the last line is ok

Code: Select all

axisPID[YAW] = constrain(axisPID[YAW],-100-abs(rcCommand[YAW]),+100+abs(rcCommand[YAW]));

Posted: **Thu Mar 03, 2011 5:04 pm**

Ok 1.7 seems to work OK accept for the fact that I can't get the engines to arm. The arduino is blinking after booting, what does that indicate? I haven't seen this before, coming from version 1.5...

Any advice?

Thanks!

Maurits

Posted: **Thu Mar 03, 2011 7:50 pm**

The arduino will blink forever (and will prevent arming motors) until you calibrate properly the ACC, or if your multi is not horizontal.
It's new with 1.pre7

Posted: **Thu Mar 03, 2011 8:18 pm**

Alexinparis wrote:The arduino will blink forever (and will prevent arming motors) until you calibrate properly the ACC, or if your multi is not horizontal.
It's new with 1.pre7

It works! Great, thanks!

M

Posted: **Fri Mar 04, 2011 7:57 pm**

I have a serial LCD question

I got the 20*4 sparkfun display...Datasheet is identical to the 16*2:

http://www.sparkfun.com/datasheets/LCD/SerLCD_V2_5.PDF

I cant get it to work with any MultiWii version....But I really need it for field config.

Which serial connection is used for Display on mega version?

What baud rate should I run the display at?

Do I need to change something in code to fit the 20 character lines?

Posted: **Fri Mar 04, 2011 10:44 pm**

420RcPilot wrote:I have a serial LCD question

I got the 20*4 sparkfun display...[...]

What baud rate should I run the display at?

Do I need to change something in code to fit the 20 character lines?

default in the original MultiWii code is set to 9600 baud.
The code inverts the use of RX,TX pin funktionality (was meant to facilitate using a servo cable, iirc).
So maybe try swapping rx,tx connection at display connector.

No need to change the code, from delving in the code lately I am quite sure it does not rely on the display dimensions. It should just work but not use the additional display real estate. If it is the same type apart form dimensions then it should understand the same command sequences and fit.
Hamburger

Posted: **Sat Mar 05, 2011 2:00 am**

420RcPilot wrote:I have a serial LCD question

I got the 20*4 sparkfun display...Datasheet is identical to the 16*2:

http://www.sparkfun.com/datasheets/LCD/SerLCD_V2_5.PDF

I cant get it to work with any MultiWii version....But I really need it for field config.

Which serial connection is used for Display on mega version?

What baud rate should I run the display at?

Do I need to change something in code to fit the 20 character lines?

it should just work.

check your pinout again, i think you need to swap the order of the pins in the servo connector to properly line up the signals (if you are following the ftdi serial module pinout).

did the lcd power up and display the sparkfun banner?

Posted: **Sat Mar 05, 2011 5:35 pm**

Hi just report back from the flight field, I did testflights with the original 1.7pre and the part below in comments.
As soon as the first 4 lines are commented the drift during maxthrottle-climbs is gone so i think your suggestion to completely remove them is save.
(tested flips, speedpass stationary and autolevel)

Code: Select all

#if NUMBER_MOTOR > 3
 /*   //prevent "yaw jump" during yaw correction: the yaw correction should allow the same ammount of motor speed variation in both ways
    if      (rcCommand[THROTTLE]-axisPID[YAW] < MINTHROTTLE) axisPID[YAW] = rcCommand[THROTTLE]-MINTHROTTLE;
    else if (rcCommand[THROTTLE]+axisPID[YAW] < MINTHROTTLE) axisPID[YAW] = -rcCommand[THROTTLE]+MINTHROTTLE;
    else if (rcCommand[THROTTLE]+axisPID[YAW] > MAXTHROTTLE) axisPID[YAW] = MAXTHROTTLE-rcCommand[THROTTLE];
    else if (rcCommand[THROTTLE]-axisPID[YAW] > MAXTHROTTLE) axisPID[YAW] = -MAXTHROTTLE+rcCommand[THROTTLE]; */
    axisPID[YAW] = constrain(axisPID[YAW],-100-abs(rcCommand[YAW]),+100+abs(rcCommand[YAW]));
  #endif

Code: Select all

axisPID[YAW] = constrain(axisPID[YAW],-100-abs(rcCommand[YAW]),+100+abs(rcCommand[YAW]));

Kind regards

Christoph

Posted: **Sat Mar 05, 2011 11:45 pm**

Hi guys,

I have a strange problem with stable mode. When flying in normal mode my quad is really stable. But after I switch on stable mode, front left motor immediately spins at full speed, when throttle is applied. The other 3 motors are spinning as they are expected to. ACC is already calibrated and shows correct values. Any ideas how to solve the problem?

Thanks in advance

Posted: **Sun Mar 06, 2011 10:16 pm**

I'm beginner in Wii copter. Before I had KKboard. I have one question, can I change pid and other parameters via GUI or only via LCD. When I can change, how via GUI ? Thnx.

Posted: **Sun Mar 06, 2011 10:29 pm**

@dynai: ok good to know, I will suppress those line in the next revision

@speto_sk: To change a value in the gui, you must first read the current ones (button READ, activated after button START). and then click on it and slide the mouse. Then write (button WRITE).

Posted: **Sun Mar 06, 2011 10:41 pm**

THNX Alexinparis, now I know.

Posted: **Thu Mar 10, 2011 9:42 pm**

Black Thunder wrote:Hi guys,

I have a strange problem with stable mode. When flying in normal mode my quad is really stable. But after I switch on stable mode, front left motor immediately spins at full speed, when throttle is applied. The other 3 motors are spinning as they are expected to. ACC is already calibrated and shows correct values. Any ideas how to solve the problem?

Thanks in advance

Problem still exists, but I've tried v1.6 and there stable mode works normally. So maybe there is a bug in v1.7pre?

MultiWii

MultiWii v1.pre7 released

MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Thanks

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

1.pre7patched GUI on MacosX does not run properly

Re: MultiWii v1.pre7 GUI patch looping but not redrawing.

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released

Re: MultiWii v1.pre7 released