MultiWii 2.0 bug report
Re: MultiWii 2.0 bug report
Ok once more about tbe:
in the German FPV-Forum there is a 7-page thread about this issue:
http://fpv-community.de/showthread.php? ... table-Mode
Maybe google can help you with translation.
The last report is as follows:
User rc-action_de has three copter, all more or less unflyable in acc mode with 2.0:
"TBE is the same with me at 3 Coptern.
Crius the Quadro board
Paris 4.0 with 6 DOF IMU Robo Bee in the Quadro
Mega Flyduino with Sirius in the Navigator Hexacopter
All boards previously had the 1.9 software and were flashed on the 2.0.
All copter fly (without ACC) are extremely stable, but with almost unflyable ACC.
The hexa example flew with the 1.9 and very high P-values are very stable...."
How can we help to identify the problem ? It takes me wonder that nobody else reports this problem as up to now quite a
few people are reporting tbe in the fpv-forum....
regards
Joachim
in the German FPV-Forum there is a 7-page thread about this issue:
http://fpv-community.de/showthread.php? ... table-Mode
Maybe google can help you with translation.
The last report is as follows:
User rc-action_de has three copter, all more or less unflyable in acc mode with 2.0:
"TBE is the same with me at 3 Coptern.
Crius the Quadro board
Paris 4.0 with 6 DOF IMU Robo Bee in the Quadro
Mega Flyduino with Sirius in the Navigator Hexacopter
All boards previously had the 1.9 software and were flashed on the 2.0.
All copter fly (without ACC) are extremely stable, but with almost unflyable ACC.
The hexa example flew with the 1.9 and very high P-values are very stable...."
How can we help to identify the problem ? It takes me wonder that nobody else reports this problem as up to now quite a
few people are reporting tbe in the fpv-forum....
regards
Joachim
Re: MultiWii 2.0 bug report
Yesterday i tried the stable mode fly with MONGOSE board. A very bad experience. The copter do not want to stay level no mater of the acc trim, pid level adjusts.Sometimes it goes to the left with accumulative drift or sometimes go to front, than right than left than .... I am more and more disappointed by the multiwii way of doing things.
I think is time to try something else ... maybe fuzzy logic ? Maybe it will be easier to understand and adjust the parameters than PID's.
My opinion is that we are interpreting in a wrong way the acc sensor data.
I think is time to try something else ... maybe fuzzy logic ? Maybe it will be easier to understand and adjust the parameters than PID's.
My opinion is that we are interpreting in a wrong way the acc sensor data.
Re: MultiWii 2.0 bug report
To contribute with Joachim Stable mode (Acc) problems.
I'm using MultiWii v2 on two boards.
First on my Vtail small quad (700g) Paris v4, Sirius
Second on my Vtail medium quad (1050g), Paris V4, FreeIMU 4.3
Here is a video of the small one in Stable (Acc) flight with Z hold/Heading hold.
There are no glitches with my setup and PID settings.
Marc
http://vimeo.com/40504035
I'm using MultiWii v2 on two boards.
First on my Vtail small quad (700g) Paris v4, Sirius
Second on my Vtail medium quad (1050g), Paris V4, FreeIMU 4.3
Here is a video of the small one in Stable (Acc) flight with Z hold/Heading hold.
There are no glitches with my setup and PID settings.
Marc
http://vimeo.com/40504035
Re: MultiWii 2.0 bug report
Marc,
i cant see how your video contributes to my problem. It shows a Multiwiicopter which is flying wihout
any glitches in stable mode... I think most of the users have have this sort of behaviour...
In the meantime I know several people with the toilet bowl effect problem and as our copter does not
fly stable we cannot shot a video without risking a crash..
i cant see how your video contributes to my problem. It shows a Multiwiicopter which is flying wihout
any glitches in stable mode... I think most of the users have have this sort of behaviour...
In the meantime I know several people with the toilet bowl effect problem and as our copter does not
fly stable we cannot shot a video without risking a crash..
Re: MultiWii 2.0 bug report
Hallo Joachim,
My video is to show it can work.
Default pid settings are for a light quad. With heavier configuration I have around 50% more P (Acro and Level). I also have lower I for Level (0.010). It helped a lot with 1.9 version and I stick to it (no bad drift).
Toilet bowl tell me "increase P".
I experienced diagonal oscillation: it was due to slipping shaft. I also had some free magnets after a crash. Not good for a nice flight.
Enjoy your quad,
Marc
My video is to show it can work.
Default pid settings are for a light quad. With heavier configuration I have around 50% more P (Acro and Level). I also have lower I for Level (0.010). It helped a lot with 1.9 version and I stick to it (no bad drift).
Toilet bowl tell me "increase P".
I experienced diagonal oscillation: it was due to slipping shaft. I also had some free magnets after a crash. Not good for a nice flight.
Enjoy your quad,
Marc
Re: MultiWii 2.0 bug report
jevermeister wrote:Okay, I don't know if it is a bug with 2.0 because I flew some lipos without this problem:
My copter stutters and drops a few centimeters and banks to left to right and front and back randomly and this lead to a crash two times.
I was lucky that I was fas flying low at the first crash in FVP.
Here is a video ( do not laugh because of the missing front legs, they got killed in the first crash :-/)
All these small glitches are not me...
http://youtu.be/6nFd-ZBJeNE
Is this a Software problem or do I have some loose wires? I swapped the batteries of my TX but this did not help, even a new LIPO does not help...
Nils
ps.: I will post this into RCgroups too, so please do not object.
the up and down looks like the behavior when baro is activated.
which imu/sensors do u use?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii 2.0 bug report
warthox wrote:jevermeister wrote:Okay, I don't know if it is a bug with 2.0 because I flew some lipos without this problem:
My copter stutters and drops a few centimeters and banks to left to right and front and back randomly and this lead to a crash two times.
I was lucky that I was fas flying low at the first crash in FVP.
Here is a video ( do not laugh because of the missing front legs, they got killed in the first crash :-/)
All these small glitches are not me...
http://youtu.be/6nFd-ZBJeNE
Is this a Software problem or do I have some loose wires? I swapped the batteries of my TX but this did not help, even a new LIPO does not help...
Nils
ps.: I will post this into RCgroups too, so please do not object.
the up and down looks like the behavior when baro is activated.
which imu/sensors do u use?
Hi Warthox,
Baro is deactivated here, bigger problem is the sudden tilt forwad
I just flew a lipo a few moments ago but have no problems. Very strange, I think I have some loose parts here.
I have no IMU I fly single Bobs: WMP, BMA020, BMP085, HMC5883L.
Never had this behavior before :-/
Thank you for looking into my issue
Nils
Re: MultiWii 2.0 bug report
i think i found another bug.
i built 3 quads. all with promini and mpu6050 from flyduino.
all with totally different setup.
flydumini + tiger 10A + tiger 1306 // dji clone frame + suppo30A + mt2212 980kv // grasshopper frame + hobbywing 10A + mt2208 1100kv
all have the same behavior. they dont take throttle directly, very laggy, dont fly smooth.
its like with a copter with an itg3200 with no lpf and much vibrations.
i also swapped the board to another frame which i fly a long time without problem. same behavior here.
so i tried the mpu6050 lpf down to 20hz but no difference.
i also tried different fw versions from 2.0 pre over 2.0 and latest the 2.0 dev.
the dji clone quad flies smooth with a mwc board with itg3200 gyro and the grasshopper quad also flies good with an ff board with ported mwc fw.
it seems that the lpf for the mpu6050 has not a bit of effect.
i built 3 quads. all with promini and mpu6050 from flyduino.
all with totally different setup.
flydumini + tiger 10A + tiger 1306 // dji clone frame + suppo30A + mt2212 980kv // grasshopper frame + hobbywing 10A + mt2208 1100kv
all have the same behavior. they dont take throttle directly, very laggy, dont fly smooth.
its like with a copter with an itg3200 with no lpf and much vibrations.
i also swapped the board to another frame which i fly a long time without problem. same behavior here.
so i tried the mpu6050 lpf down to 20hz but no difference.
i also tried different fw versions from 2.0 pre over 2.0 and latest the 2.0 dev.
the dji clone quad flies smooth with a mwc board with itg3200 gyro and the grasshopper quad also flies good with an ff board with ported mwc fw.
it seems that the lpf for the mpu6050 has not a bit of effect.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii 2.0 bug report
Joachim08 wrote:Ok once more about tbe:
in the German FPV-Forum there is a 7-page thread about this issue:
http://fpv-community.de/showthread.php? ... table-Mode
Maybe google can help you with translation.
The last report is as follows:
User rc-action_de has three copter, all more or less unflyable in acc mode with 2.0:
"TBE is the same with me at 3 Coptern.
Crius the Quadro board
Paris 4.0 with 6 DOF IMU Robo Bee in the Quadro
Mega Flyduino with Sirius in the Navigator Hexacopter
All boards previously had the 1.9 software and were flashed on the 2.0.
All copter fly (without ACC) are extremely stable, but with almost unflyable ACC.
The hexa example flew with the 1.9 and very high P-values are very stable...."
How can we help to identify the problem ? It takes me wonder that nobody else reports this problem as up to now quite a
few people are reporting tbe in the fpv-forum....
regards
Joachim
Hi,
can you try to remove this line in multiwii.ino (from 2.0):
Code: Select all
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
With this, you should have exactly the same behavior of 1.9 stable mode.
can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii 2.0 bug report
warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.
Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.
Re: MultiWii 2.0 bug report
for OCTOFLATP I did receive the following bug report via email from Michael Geuer:
which imho boils down to:
for OCTOFLATP, the GUI displays OctoX instead and roll and pitch are wrong (switched?)
Hope it makes sense to someone - I have nothing bigger than TRIs.
#define OCTOFLATP ausgewählt. Aber im Config ist Roll und Pitch falsch und es steht auch noch OctoX im Tool
which imho boils down to:
for OCTOFLATP, the GUI displays OctoX instead and roll and pitch are wrong (switched?)
Hope it makes sense to someone - I have nothing bigger than TRIs.
Re: MultiWii 2.0 bug report
hi,
he wrote me this email too .. and i looked at the mix tables.. it seems that there is everything right. i told him that it may be because of an incorrect sensor orientation.. or a not corrrected one.
regards
felix
he wrote me this email too .. and i looked at the mix tables.. it seems that there is everything right. i told him that it may be because of an incorrect sensor orientation.. or a not corrrected one.
regards
felix
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii 2.0 bug report
ronco wrote:hi,
he wrote me this email too .. and i looked at the mix tables.. it seems that there is everything right. i told him that it may be because of an incorrect sensor orientation.. or a not corrrected one.
regards
felix
same here
Re: MultiWii 2.0 bug report
Alexinparis wrote:warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.
Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.
thanks alex
Re: MultiWii 2.0 bug report
Alexinparis wrote:
Hi,
can you try to remove this line in multiwii.ino (from 2.0):Code: Select all
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
With this, you should have exactly the same behavior of 1.9 stable mode.
can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?
Alex,
regarding the tbe i have just downloaded 2.0dev of 14. April. It looks like you have changed the line in multiwii.ino already.
The Z ACC is around 512 when it is flat on the ground and - (minus) 524 when it is reverted.
Is that ok so far ?
When i start the copter in my hands it looks much better now, but i cannot fly because of windy weather outside, maybe
i can give it a try later this evening.
Is there any reason why you have not included the code for the new Drotek IMU 10DOF with MP6050 in the sketch ?
Re: MultiWii 2.0 bug report
when compiling latest code r700 out of MultiWii_shared, I get the following warnings:
Code in question is
Could not this be rewritten in a compiler-clean way?
Serial.pde: In function 'uint32_t read32()':
Serial.pde:47: warning: left shift count >= width of type
Serial.pde:48: warning: left shift count >= width of type
Code in question is
Code: Select all
static uint8_t checksum,stateMSP,indRX,inBuf[64];
uint32_t read32() {
uint32_t t = inBuf[indRX++];
t+= inBuf[indRX++]<<8;
t+= inBuf[indRX++]<<16;
t+= inBuf[indRX++]<<24;
return t;
}
Could not this be rewritten in a compiler-clean way?
Re: MultiWii 2.0 bug report
Hamburger wrote:when compiling latest code r700 out of MultiWii_shared, I get the following warnings:Code: Select all
..
t+= inBuf[indRX++]<<8;
Could not this be rewritten in a compiler-clean way?
Should be like this (sry, not tested...):
t+= ((uint16_t)inBuf[indRX++])<<8;
t+= ((uint32_t)inBuf[indRX++])<<16;
t+= ((uint32_t)inBuf[indRX++])<<24;
...
Re: MultiWii 2.0 bug report
yes, thanks. It eliminates the warnings.
Re: MultiWii 2.0 bug report
cannot calb ACC with latest r700 MWii_shared.
What I did:
zeroed out eeprom,
then uploaded freshly compiled MWii to crius lite board.
Then run freshly compiled GUI. Sensor graphs are all over the window - because acc values go crazy.
Pressing the 'Calib ACC' does nothing to this.
Loading older r660 with corresponding GUI allows to calib Acc. If I now again load r700, then the graphs look good but
pressing 'calib ACC' does not give the typical notch in the acc graph. So I presume that with r700 the GUI never makes the board enter the Acc calib.
What I did:
zeroed out eeprom,
then uploaded freshly compiled MWii to crius lite board.
Then run freshly compiled GUI. Sensor graphs are all over the window - because acc values go crazy.
Pressing the 'Calib ACC' does nothing to this.
Loading older r660 with corresponding GUI allows to calib Acc. If I now again load r700, then the graphs look good but
pressing 'calib ACC' does not give the typical notch in the acc graph. So I presume that with r700 the GUI never makes the board enter the Acc calib.
Re: MultiWii 2.0 bug report
also, the GUI Reset Button does nothing for me.
Re: MultiWii 2.0 bug report
Alexinparis wrote:warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.
Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.
hi
is there any solution for this problem?
my quad with flydiuno MPU6050 has the same problem as wartho described before.
would be great if anyone could solve the problem.
br michael
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii 2.0 bug report
Hamburger wrote:for OCTOFLATP I did receive the following bug report via email from Michael Geuer:#define OCTOFLATP ausgewählt. Aber im Config ist Roll und Pitch falsch und es steht auch noch OctoX im Tool
which imho boils down to:
for OCTOFLATP, the GUI displays OctoX instead and roll and pitch are wrong (switched?)
Hope it makes sense to someone - I have nothing bigger than TRIs.
It's just the GUI which is generic for all octo configs and display OCTOCOPTER X8 for all configs.
I will switch it to the generic term "OCTOCOPTER"
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii 2.0 bug report
Joachim08 wrote:Alexinparis wrote:
Hi,
can you try to remove this line in multiwii.ino (from 2.0):Code: Select all
PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
With this, you should have exactly the same behavior of 1.9 stable mode.
can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?
Alex,
regarding the tbe i have just downloaded 2.0dev of 14. April. It looks like you have changed the line in multiwii.ino already.
The Z ACC is around 512 when it is flat on the ground and - (minus) 524 when it is reverted.
Is that ok so far ?
When i start the copter in my hands it looks much better now, but i cannot fly because of windy weather outside, maybe
i can give it a try later this evening.
Is there any reason why you have not included the code for the new Drotek IMU 10DOF with MP6050 in the sketch ?
Your ACC value seems to be correct.
Please look better. The line I suggested to remove is still present in the current dev version... and nothing changed regarding the ACC stability.
Re: MultiWii 2.0 bug report
mbrak wrote:is there any solution for this problem?
my quad with flydiuno MPU6050 has the same problem as wartho described before.
would be great if anyone could solve the problem.
br michael
Same problem here, tried a friend's quad with atmega-328 and mpu-6050 after a good 20minutes bench tuning. It was barely flyable with very low P and high D, and only in hovering/slow manouvers.
Gyro were too sensible and seem to resonate at some frequency, making it impossible to sustain heigh and very hard to tune.
LPF filter has no effect.
Please check the full-range scale too. We really don't need the 2000 °/sec, 1000 or 500°/s should be better. (I think that is the "problem" with itg32XX too, it's just too sensitive, while old good wmp's idg600 gives a better feeling in slow flying and for AP purposes)
Re: MultiWii 2.0 bug report
jhoexp wrote:Please check the full-range scale too. We really don't need the 2000 °/sec, 1000 or 500°/s should be better. (I think that is the "problem" with itg32XX too, it's just too sensitive, while old good wmp's idg600 gives a better feeling in slow flying and for AP purposes)
are u sure that we dont need the full scale?
maybe u dont need it but some others need it.
so the best solution would be a define for it to select the scale depending on your flying style.
@ alex - did u already had the time to take a look onto the mpu lpf?
Re: MultiWii 2.0 bug report
warthox wrote:are u sure that we dont need the full scale?
Of course you can set it to what you want, but you don't need 2000°/s, expecially for AP purposes.
Anyway, setting the full range scale to 500°/sec doesn't prevent you to flip it even much faster, prroves is that you can do that with wmp's idg500 and they are just 500°/s.
Re: MultiWii 2.0 bug report
hi
about the problem with the mpu6050 (not very stable, laggy,etc.).....
try out with p=9.0/I=0.04/D=23
just came in from testflight with these settings. very very stable. just wobbling just a tiny bit.
wow. and this with the promini without 11bit pwm.... i am impressed!
the values are from rosewhite. 10 minutes bevore i couldnt believe that they are real... now i know that they are!
about the problem with the mpu6050 (not very stable, laggy,etc.).....
try out with p=9.0/I=0.04/D=23
just came in from testflight with these settings. very very stable. just wobbling just a tiny bit.
wow. and this with the promini without 11bit pwm.... i am impressed!
the values are from rosewhite. 10 minutes bevore i couldnt believe that they are real... now i know that they are!
Re: MultiWii 2.0 bug report
Hi,
Auf welchen Achsen ? Allen drei ?
Gruß Kayle
try out with p=9.0/I=0.04/D=23
Auf welchen Achsen ? Allen drei ?
Gruß Kayle
Re: MultiWii 2.0 bug report
jhoexp wrote:LPF filter has no effect.
While troubleshooting the same quad jhoexp is referring above (we are common friends) we discovered that with current code, it seems that DLPF settings are not stored in the sensor memory thus never actually used by the sensor and completely useless. More details, including working code, at viewtopic.php?f=8&t=1591
Fabio Varesano
Re: MultiWii 2.0 bug report
Hi all,
I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:
#define QUADP
#define BMA180
#define MOTOR_STOP
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
You can see the behavior in this video:
http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded
It's seems like a bug, because with 1.9 firm, everything works fine.
What can I do?
thx
Bye!
I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:
#define QUADP
#define BMA180
#define MOTOR_STOP
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
You can see the behavior in this video:
http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded
It's seems like a bug, because with 1.9 firm, everything works fine.
What can I do?
thx
Bye!
- fr3d
- Posts: 97
- Joined: Sun Feb 06, 2011 11:21 am
- Location: Cappelle la grande near the ch'ti village
- Contact:
Re: MultiWii 2.0 bug report
bitman wrote:Hi all,
I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:
#define QUADP
#define BMA180
#define MOTOR_STOP
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
You can see the behavior in this video:
http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded
It's seems like a bug, because with 1.9 firm, everything works fine.
What can I do?
thx
Bye!
try to disable bma180
Code: Select all
//#define BMA180
or add
Code: Select all
#define BMA180_ADDRESS 0x82
Re: MultiWii 2.0 bug report
I tried to disable BMA180 but It got worst,
But I,ll add this code...let me try...
thx
Bye!
But I,ll add this code...let me try...
thx
Bye!
Re: MultiWii 2.0 bug report
Ok, I,ve tested this:
add BMA180_ADDRESS 0x82 => The same.
add BMA180_ADDRESS 0x82 and #define BMA180 => The same.
And also changued this:
#if !defined(BMA180_ADDRESS)
//#define BMA180_ADDRESS 0x80
#define BMA180_ADDRESS 0x82
#endif
But nothing ocurs. Sometimes ACC doesn't works, others works too bad.
Thx!
Bye
add BMA180_ADDRESS 0x82 => The same.
add BMA180_ADDRESS 0x82 and #define BMA180 => The same.
And also changued this:
#if !defined(BMA180_ADDRESS)
//#define BMA180_ADDRESS 0x80
#define BMA180_ADDRESS 0x82
#endif
But nothing ocurs. Sometimes ACC doesn't works, others works too bad.
Thx!
Bye
Re: MultiWii 2.0 bug report
My tri tail servo is mechanically not completely correct.
When flying straight, It needs approx 1560 us on the tail servo as shown in the GUI to keep the heading.
So I tried to trim it by adjusting TRI_YAW_MIDDLE to 1560, but it doesn't seem to do anything
Even tried 1800 (just to see if it would move at all), but no luck. It stays in the same centre position....
I'm using dev20120414, this is with a promini 328
On earlier versions (then with Flyduino mega), it seemed to worked ok.
if I change (in output):
servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR
to
servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR
it works ok.....
Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where
When flying straight, It needs approx 1560 us on the tail servo as shown in the GUI to keep the heading.
So I tried to trim it by adjusting TRI_YAW_MIDDLE to 1560, but it doesn't seem to do anything
Even tried 1800 (just to see if it would move at all), but no luck. It stays in the same centre position....
I'm using dev20120414, this is with a promini 328
On earlier versions (then with Flyduino mega), it seemed to worked ok.
if I change (in output):
servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR
to
servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR
it works ok.....
Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where
Re: MultiWii 2.0 bug report
It is stored in eeprom and can be changed via lcd or via terminal of arduino ide.
Else you can clear eeprom and upload mwii again.
Else you can clear eeprom and upload mwii again.
Re: MultiWii 2.0 bug report
Hamburger wrote:It is stored in eeprom and can be changed via lcd or via terminal of arduino ide.
Else you can clear eeprom and upload mwii again.
Aha !
now I understand......
Thanks Hamburger....
I don't have an LCD, so I never thought about this posibility to use the arduino terminal (serial monitor)....
Took me a while to figure it out, but now I got it working through the serial monitor of arduino
Some steps for so others may also used this.... I fly multiwii for almost one year and did not know, and I think there might be more people like that around....
- First ensure #define LCD_CONF is active (not commented)
- select #define LCD_VT100
- upload your program so settings take effect
- open serial monitor in arduino (right top corner)
- select baudrate 115200
- Put pitch stick forward FIRST, and only after that put throttle / yaw stick to bottom right (assuming mode 2).
Please be aware, if you first put the throttle / yaw to bottom right, it will start the motors
On the serial monitor, now the settings should appear
- with pitch up / down, you can scroll through the parameters.
- with roll left / right, you can change parameters.
here I could change the tri_yaw_middle to the required position...
when finished, throttle to left bottom, and pitch forward to save and exit.
See also http://multiwii.googlecode.com/svn/bran ... -57721.pdf for all commands
Wilco.
Re: MultiWii 2.0 bug report
I have a multiwii crius SE and I do not work in version 2.0 headfree why? What should I do?
Re: MultiWii 2.0 bug report
I have the crius multiwii se and have tried the headfree mode. It works but my aileron is reversed on it, the aileron is fine in stable and acro mode but headfree it is reversed. Is there a setting to reverse it?
Re: MultiWii 2.0 bug report
I have just noticed that on my tx the rudder and aileron are reversed which makes it correct in the GUI but I guess I could put them to normal then reverse them in the code?
Re: MultiWii 2.0 bug report
Other than that for a super cheap first build quad using the wrong esc's and having lots of vibrations it is still flying very stable and alt works great. It flies on it's own hands off sticks for at least 30secs before it starts to drift away.
I am now in the process of building a much nicer unit with a naze32 and proper Simon esc's. Also might be tempted to put some quality motors on it.
I am now in the process of building a much nicer unit with a naze32 and proper Simon esc's. Also might be tempted to put some quality motors on it.
Re: MultiWii 2.0 bug report
I am using Multiwii 2.0 (NOT DEV)
I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).
In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.
I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.
Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}
I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).
In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.
I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.
Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}
Re: MultiWii 2.0 bug report
wilco1967 wrote:if I change (in output):
servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR
to
servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR
it works ok.....
Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where
the same bug, i changed tri_yaw_middle variable to TRI_YAW_MIDDLE (define in config.h)
Re: MultiWii 2.0 bug report
SovGVD wrote:the same bug, i changed tri_yaw_middle variable to TRI_YAW_MIDDLE (define in config.h)
or you could read the two posts following the one you quoted for explanation and usage guide.
Re: MultiWii 2.0 bug report
Ausi1972 wrote:I am using Multiwii 2.0 (NOT DEV)
I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).
In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.
I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.
Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}
Forget all of that. I have just built up again, same motors but with HK F-20A ESC's flashed with Simon code, the Crius MWC SE in a DJI F450 V2 frame.
Been out in the garden with restricted space and found it flies super stable and everything is working perfect now.
Headfree mode is amazing. it makes flying a total breeze, very strange to get used to. No more trying to keep it tail in etc. Just go fly!!!!
Altitude hold is also working great.
Looking forward to a great weekend of flying my new toy!
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: MultiWii 2.0 bug report
BTW:
I have NO NUNCHUK in flight bug with MultiWii_dev_20120504. My tri ran on 1.9 before and i skipped the official 2.0, so i can not say, if it was affected with FW 2.0.
viewtopic.php?f=8&t=1455&p=13973#p13973
I have NO NUNCHUK in flight bug with MultiWii_dev_20120504. My tri ran on 1.9 before and i skipped the official 2.0, so i can not say, if it was affected with FW 2.0.
viewtopic.php?f=8&t=1455&p=13973#p13973
Re: MultiWii 2.0 bug report
Seems to find some bugs in 20120504.
I install v2.0 and it works perfect, but 20120504, I can't start CALIB_ACC and CALIB_MAG from MultiWiiConf. Try eeprom_clear but nothing change.
Also from RC stick, I can start MAG calibration, but can't start ACC calibration.
With v2.0, both CALIB_ACC and CALIB_MAG and RC stick ACC caribration and RC stick MAG caribration works well.
Is this something setting error?
My Hexa Flyduino Mega with FreeIMU v0.3.5_MS.
I install v2.0 and it works perfect, but 20120504, I can't start CALIB_ACC and CALIB_MAG from MultiWiiConf. Try eeprom_clear but nothing change.
Also from RC stick, I can start MAG calibration, but can't start ACC calibration.
With v2.0, both CALIB_ACC and CALIB_MAG and RC stick ACC caribration and RC stick MAG caribration works well.
Is this something setting error?
My Hexa Flyduino Mega with FreeIMU v0.3.5_MS.
Re: MultiWii 2.0 bug report
Hey, I just put the latest 2.0 DEV build on, and noticed I can't trim with the remote anymore!
When I move the sticks I get no response on the LEDs like I did before and it doesn't seem to change anything.
When I move the sticks I get no response on the LEDs like I did before and it doesn't seem to change anything.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Baro Bug / Solution
Hi !
In the current code there are some problems with the locking in of a new hight for the Baro/PID controller:
Original:
Problem1:
At the moment the throttlestick is altered a new hight is locked for the PID controller long before the copter could have possibly reached a new hight or has altered his position. This can also lead to a feedbackproblem.
Problem2:
With this code the throttlechannel is rasterized in 21 steps, that gives a sluggish throttleresponse and an unnatural feeling for the pilot.
Possible Solution:
Give the pilot full control over the throttlechannel.
Lock in a new hight for the Baro PID controller only under the following circumstances:
The copter has done a substantial hight (in my code 60cm) change and the pilot wanted it by stickinput (change "20").
I changed the code and tested it for 2 days - and the baro behaviour improved. Perhaps i have to raise the value of "60" for my BMP085 to e.g. "100".
I posted my findings in my german forum (http://fpv-community.de/showthread.php? ... post146766) and another user reports (http://fpv-community.de/showthread.php? ... post146996) that his copter behaves significantly better than with the original DEV 20120504.
My findings should also apply for the new DEV, but is untested.
Please look into this. I think my new code is far from perfect, but it flies better.
I am new to C and arduino programming.
Cheers
Crashpilot1000
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
EDIT 26.05.2012: I did a new Version: http://fpv-community.de/showthread.php? ... post148827
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
New Code:
In the current code there are some problems with the locking in of a new hight for the Baro/PID controller:
Original:
Code: Select all
#if BARO
if (baroMode) {
if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
baroMode = 0; // so that a new althold reference is defined
}
rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
}
#endif
Problem1:
At the moment the throttlestick is altered a new hight is locked for the PID controller long before the copter could have possibly reached a new hight or has altered his position. This can also lead to a feedbackproblem.
Problem2:
With this code the throttlechannel is rasterized in 21 steps, that gives a sluggish throttleresponse and an unnatural feeling for the pilot.
Possible Solution:
Give the pilot full control over the throttlechannel.
Lock in a new hight for the Baro PID controller only under the following circumstances:
The copter has done a substantial hight (in my code 60cm) change and the pilot wanted it by stickinput (change "20").
I changed the code and tested it for 2 days - and the baro behaviour improved. Perhaps i have to raise the value of "60" for my BMP085 to e.g. "100".
I posted my findings in my german forum (http://fpv-community.de/showthread.php? ... post146766) and another user reports (http://fpv-community.de/showthread.php? ... post146996) that his copter behaves significantly better than with the original DEV 20120504.
My findings should also apply for the new DEV, but is untested.
Please look into this. I think my new code is far from perfect, but it flies better.
I am new to C and arduino programming.
Cheers
Crashpilot1000
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
EDIT 26.05.2012: I did a new Version: http://fpv-community.de/showthread.php? ... post148827
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
New Code:
Code: Select all
static uint8_t baroloopcounter=0;
static int32_t thrsticksum=0;
static int16_t thrstickmw=0;
static int32_t estaltsum=0;
static int32_t estaltmw=0;
Code: Select all
#if BARO
if (baroMode)
{
if (baroloopcounter <64)
{
estaltsum=estaltsum+EstAlt;
thrsticksum=thrsticksum+rcCommand[THROTTLE];
thrstickmw=0;
estaltmw=0;
baroloopcounter=baroloopcounter+1;
}
else
{
baroloopcounter=0;
estaltmw=estaltsum>>6;
thrstickmw=thrsticksum>>6;
estaltsum=0;
thrsticksum=0;
// debug3=thrstickmw - initialThrottleHold;
// debug4=estaltmw - AltHold;
if (abs(estaltmw - AltHold)>60 && abs(thrstickmw - initialThrottleHold)>20) //Did the hight significant change over time on purpose?
{
baroMode = 0; // so that a new althold reference is defined
}
}
rcCommand[THROTTLE] = rcCommand[THROTTLE] + BaroPID;
}
#endif
Last edited by Crashpilot1000 on Sat May 26, 2012 5:50 pm, edited 1 time in total.
- AlouetteIII
- Posts: 27
- Joined: Tue Jan 25, 2011 2:34 pm
- Location: AU Australia
- Contact:
Re: MultiWii 2.0 bug report
@CrashPilot1000 - cool - what BARO PIDs did you have for the best result and have you tried it in combination with Acc Z variations.
which sections to replace the code you show? which tabs? And did you see if this still applies to 2.0.522 version ? thanks
which sections to replace the code you show? which tabs? And did you see if this still applies to 2.0.522 version ? thanks
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: MultiWii 2.0 bug report
Hi !
I just tried the new MultiWii_dev_20120522 with my code in the backyard and it works very well though its windy here in NW Germany.
The changes are done in the main tab of the code. Just place the new "statics" in front of the others and replace the original code (i quoted under "Original") with the new one. BTW i did my last flight (BMP085 Baro) with ..."abs(estaltmw - AltHold)>100 ..." and "...thrstickmw - initialThrottleHold)>40...". Just play with the values. Uncomment Debug 3 and 4 and watch the values in the GUI. Debug 3 tells you the change of the throttlestick and debug 4 tells you the change of the Altitude in cm of the sensor. You can test it while disarmed. If you see Debug 3=0 the code has locked in a new hight. At the moment i use the stock PID for alt/baro. I looked at the ACCZ values as well, and its beyond my capabilities to make real use of them. At the moment i can figure out with a good probability if the copter was rising or falling while locking a new altitude. This could be used e.g for a small throttleburst to support the Baro.
I just tried the new MultiWii_dev_20120522 with my code in the backyard and it works very well though its windy here in NW Germany.
The changes are done in the main tab of the code. Just place the new "statics" in front of the others and replace the original code (i quoted under "Original") with the new one. BTW i did my last flight (BMP085 Baro) with ..."abs(estaltmw - AltHold)>100 ..." and "...thrstickmw - initialThrottleHold)>40...". Just play with the values. Uncomment Debug 3 and 4 and watch the values in the GUI. Debug 3 tells you the change of the throttlestick and debug 4 tells you the change of the Altitude in cm of the sensor. You can test it while disarmed. If you see Debug 3=0 the code has locked in a new hight. At the moment i use the stock PID for alt/baro. I looked at the ACCZ values as well, and its beyond my capabilities to make real use of them. At the moment i can figure out with a good probability if the copter was rising or falling while locking a new altitude. This could be used e.g for a small throttleburst to support the Baro.