MultiWii v1.pre7 released

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

MultiWii v1.pre7 released

Post by Alexinparis »

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
Attachments
1_pre7.JPG

Centurian
Posts: 44
Joined: Sat Jan 22, 2011 10:55 am

Re: MultiWii v1.pre7 released

Post by Centurian »

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.

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii v1.pre7 released

Post by spagoziak »

IN-CREDIBLE!

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

spag

dodecopter
Posts: 35
Joined: Fri Jan 21, 2011 7:37 am

Re: MultiWii v1.pre7 released

Post by dodecopter »

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

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii v1.pre7 released

Post by spagoziak »

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

bradleyk
Posts: 48
Joined: Wed Jan 19, 2011 10:58 pm

Re: MultiWii v1.pre7 released

Post by bradleyk »

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:)

Nosepo
Posts: 24
Joined: Thu Jan 20, 2011 11:13 am

Re: MultiWii v1.pre7 released

Post by Nosepo »

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

bradleyk
Posts: 48
Joined: Wed Jan 19, 2011 10:58 pm

Re: MultiWii v1.pre7 released

Post by bradleyk »

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

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii v1.pre7 released

Post by copterrichie »

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);

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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);

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii v1.pre7 released

Post by copterrichie »

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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii v1.pre7 released

Post by copterrichie »

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.

dodecopter
Posts: 35
Joined: Fri Jan 21, 2011 7:37 am

Re: MultiWii v1.pre7 released

Post by dodecopter »

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.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii v1.pre7 released

Post by copterrichie »

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.

Covax
Posts: 2
Joined: Fri Jan 21, 2011 7:42 am

Re: MultiWii v1.pre7 released

Post by Covax »

GUI: 3D copter attitude visualization

my netbook plaing 3D very very slowly :((

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii v1.pre7 released

Post by spagoziak »

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?!

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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

spagoziak
Posts: 171
Joined: Thu Jan 20, 2011 1:18 am

Re: MultiWii v1.pre7 released

Post by spagoziak »

Thanks for fixing that Alex :)

quadslo
Posts: 16
Joined: Sat Feb 26, 2011 12:39 pm

Re: MultiWii v1.pre7 released

Post by quadslo »

I have one problem uploading to arduino.

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

Image

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

what is your arduino version ?

quadslo
Posts: 16
Joined: Sat Feb 26, 2011 12:39 pm

Re: MultiWii v1.pre7 released

Post by quadslo »

I have program: ARDUINO 0022 - 2010.12.24

and board: Duemilanove ATtmega328

OpticalFlow
Posts: 5
Joined: Sun Feb 27, 2011 12:22 pm

Re: MultiWii v1.pre7 released

Post by OpticalFlow »

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)

quadslo
Posts: 16
Joined: Sat Feb 26, 2011 12:39 pm

Re: MultiWii v1.pre7 released

Post by quadslo »

Tnx for info! It should work now.

JussiH
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Thanks

Post by JussiH »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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.

JussiH
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Re: MultiWii v1.pre7 released

Post by JussiH »

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

javitech
Posts: 8
Joined: Mon Feb 28, 2011 10:19 pm

Re: MultiWii v1.pre7 released

Post by javitech »

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...

vfbl
Posts: 5
Joined: Fri Feb 18, 2011 10:10 pm

Re: MultiWii v1.pre7 released

Post by vfbl »

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.

JussiH
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Re: MultiWii v1.pre7 released

Post by JussiH »

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!

User avatar
Hamburger
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

1.pre7patched GUI on MacosX does not run properly

Post by Hamburger »

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!

vfbl
Posts: 5
Joined: Fri Feb 18, 2011 10:10 pm

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

Post by vfbl »

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.

dynai
Posts: 32
Joined: Tue Mar 01, 2011 10:01 pm

Re: MultiWii v1.pre7 released

Post by dynai »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

@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.

dynai
Posts: 32
Joined: Tue Mar 01, 2011 10:01 pm

Re: MultiWii v1.pre7 released

Post by dynai »

thanks :)

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

Christoph

dynai
Posts: 32
Joined: Tue Mar 01, 2011 10:01 pm

Re: MultiWii v1.pre7 released

Post by dynai »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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]));

mskroese
Posts: 13
Joined: Thu Mar 03, 2011 4:54 pm

Re: MultiWii v1.pre7 released

Post by mskroese »

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

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

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

mskroese
Posts: 13
Joined: Thu Mar 03, 2011 4:54 pm

Re: MultiWii v1.pre7 released

Post by mskroese »

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

JussiH
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Re: MultiWii v1.pre7 released

Post by JussiH »

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?

User avatar
Hamburger
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: MultiWii v1.pre7 released

Post by Hamburger »

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

noobee
Posts: 66
Joined: Fri Feb 25, 2011 2:57 pm

Re: MultiWii v1.pre7 released

Post by noobee »

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?

dynai
Posts: 32
Joined: Tue Mar 01, 2011 10:01 pm

Re: MultiWii v1.pre7 released

Post by dynai »

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

Black Thunder
Posts: 2
Joined: Sat Mar 05, 2011 11:25 pm

Re: MultiWii v1.pre7 released

Post by Black Thunder »

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 ;)

User avatar
speto_sk
Posts: 29
Joined: Sat Mar 05, 2011 7:32 am
Location: Slovak republic, Kosice

Re: MultiWii v1.pre7 released

Post by speto_sk »

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.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii v1.pre7 released

Post by Alexinparis »

@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).

User avatar
speto_sk
Posts: 29
Joined: Sat Mar 05, 2011 7:32 am
Location: Slovak republic, Kosice

Re: MultiWii v1.pre7 released

Post by speto_sk »

THNX Alexinparis, now I know.

Black Thunder
Posts: 2
Joined: Sat Mar 05, 2011 11:25 pm

Re: MultiWii v1.pre7 released

Post by Black Thunder »

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?

Post Reply