MultiWii v1.pre7 released
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
MultiWii v1.pre7 released
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
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
Re: MultiWii v1.pre7 released
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.
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.
Re: MultiWii v1.pre7 released
IN-CREDIBLE!
Alex, you sure produce great work at blinding speed! I can't wait to try this out!
spag
Alex, you sure produce great work at blinding speed! I can't wait to try this out!
spag
-
- Posts: 35
- Joined: Fri Jan 21, 2011 7:37 am
Re: MultiWii v1.pre7 released
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
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
Re: MultiWii v1.pre7 released
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
Re: MultiWii v1.pre7 released
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:)
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:)
Re: MultiWii v1.pre7 released
Great Job Alex. I will try it asap in my hexa and report the sure fine work. 

Re: MultiWii v1.pre7 released
my computer handles it mine, but it is a high tech gaming machine
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii v1.pre7 released
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
Pre1.7
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);
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
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.
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.6Code: Select all
uint8_t wGyro = 100; // gyro weight/smooting factor
static float invW = 1.0/(1 + 100);
Pre1.7Code: Select all
int16_t wGyro = 300; // gyro weight/smooting factor
static float invW = 1.0/(1 + 300);
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
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.

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
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii v1.pre7 released
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
http://www.starlino.com/imu_guide.htmlSensitivity – 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
For my gyro, I had to set that value to 67. This number is from the gyro datasheet.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
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 Sensitivityhttp://www.starlino.com/imu_guide.htmlSensitivity – 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
For my gyro, I had to set that value to 67. This number is from the gyro datasheet.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii v1.pre7 released
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.
-
- Posts: 35
- Joined: Fri Jan 21, 2011 7:37 am
Re: MultiWii v1.pre7 released
[/quote]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.
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.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii v1.pre7 released
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.
Re: MultiWii v1.pre7 released
GUI: 3D copter attitude visualization
my netbook plaing 3D very very slowly

Re: MultiWii v1.pre7 released
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?!
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
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
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
Re: MultiWii v1.pre7 released
Thanks for fixing that Alex 

Re: MultiWii v1.pre7 released
I have one problem uploading to arduino.
I have arduino mega and I defined that. But got this error.
What can I do?

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

-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
what is your arduino version ?
Re: MultiWii v1.pre7 released
I have program: ARDUINO 0022 - 2010.12.24
and board: Duemilanove ATtmega328
and board: Duemilanove ATtmega328
-
- Posts: 5
- Joined: Sun Feb 27, 2011 12:22 pm
Re: MultiWii v1.pre7 released
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)
Re: MultiWii v1.pre7 released
Tnx for info! It should work now.
Thanks
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
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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
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.
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.
Re: MultiWii v1.pre7 released
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
. 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
http://www.youtube.com/watch?v=TR3NYhg-62k
Pilot error cut my testing short

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
Re: MultiWii v1.pre7 released
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...
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...
Re: MultiWii v1.pre7 released
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.
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.
Re: MultiWii v1.pre7 released
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!
1.pre7patched GUI on MacosX does not run properly
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
or when starting application I get additional info:
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!
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!
Re: MultiWii v1.pre7 GUI patch looping but not redrawing.
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.
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.
Re: MultiWii v1.pre7 released
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
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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
@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
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.
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

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.
Re: MultiWii v1.pre7 released
thanks 
ill check this as soon as possible.. right now i'm a bit short on time. Ill report back.
kind regards
Christoph

ill check this as soon as possible.. right now i'm a bit short on time. Ill report back.
kind regards
Christoph
Re: MultiWii v1.pre7 released
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?
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?
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
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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
Hi,
I think the problem comes from the first 4 lines:
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
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]));
Re: MultiWii v1.pre7 released
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
Any advice?

Thanks!
Maurits
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
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's new with 1.pre7
Re: MultiWii v1.pre7 released
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
Re: MultiWii v1.pre7 released
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?
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?
Re: MultiWii v1.pre7 released
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
Re: MultiWii v1.pre7 released
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?
Re: MultiWii v1.pre7 released
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)
Kind regards
Christoph
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
-
- Posts: 2
- Joined: Sat Mar 05, 2011 11:25 pm
Re: MultiWii v1.pre7 released
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
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

Re: MultiWii v1.pre7 released
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.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii v1.pre7 released
@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).
@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).
Re: MultiWii v1.pre7 released
THNX Alexinparis, now I know.
-
- Posts: 2
- Joined: Sat Mar 05, 2011 11:25 pm
Re: MultiWii v1.pre7 released
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?