Originally Posted by Lapino

Thank you shufflz
I've a separate switching BEC from hk. This should solve the heat issue but i hope it doesn't introduce much interference with the rc tx and video tx. My flyduino mega or at least one component near the cam servo supply is getting really hot after just a few seconds, even when powered from 5v (or 3.3v?) via USB...is that normal?

Thanks in advance

Switching BEC's supposedly cause some magnetic interference because of switching voltage on/off (simplified). Linear BEC/voltage regulator 'burns' extra voltage to heat, so no/less interference.

I've had just the same happening to me the other day! Major heat build up.
Seems to me GND from switching BEC isn't 'reachable' for GND from servo ports. Or maybe BEC blocks additional voltage running back on its GND, causing FC to cope with this? @Paul; can you please confirm??!!

Never had problems powering FC and servo's from BEC, but the other night I powered cam servo's via ESC and board via BEC. Now my board seems fried...

BTW: When I used 'simple' BEC from Flyduino I never had this issue. Only just mounted 'big' switching BEC.
My entire MEGA gets so hot I can easily burn myself. Even when just powered via FTDI!

My mega got hot right when i got it. I connected a esc to 5v in and it got hot...same for ftdi only. Now that i have a switching bec i can only connect bec OR ftdi either way it gets very hot. As i use 4s lipo i have no real option as working with switching bec. I'll see how much interference it brings and try to move it far far away from rx and video tx.

I've never before had a Mega getting hot, I'm running one on X8 and one on quad.
Carbonquad is flying Pro Mini, on that one the regulators on the MWC board get very hot when powered by anything else than BEC.

I'm flying 3S and 4S depending on situation (which ever are charged) .

Do you have a buzzer? You need to move that the furthest away
MAG prefers to have a 3 to 5 cm clearing around it too, supposedly. But that's never going to work on IMU's :P

Yeah my buzzer is really far away from anything else (~10cm). So i guess my mega was a bad one right from the start.

I just ordered a naze32 so hopefully this unit is alright ;-)

Originally Posted by Lapino

Yeah my buzzer is really far away from anything else (~10cm). So i guess my mega was a bad one right from the start.

I just ordered a naze32 so hopefully this unit is alright ;-)

You should ask Paul for a replacement.
When it got hot from the start then it looks like some defective part on th FC.
Paul is well known for his "no questions asked" policy.

Will try to contact Paul, his service is very good indeed!
But I've also ordered something new to try

Had the strangest thing happening yesterday. I installed the FFIMUv.0.4.1 on my quad (which was running v0.3.5) saturday as I had that sensor available now from the other Flyduino MEGA unit. Was in a hurry so upped the P's with 1 for most settings, without testing.

Next day, start flying (bit windy) and quad was jittering/vibrating under too high P, but quite flyable. Ran through 2 LiPo's (3S and 4S 3000mAh) all fine. Day was coming to an end, decide to fly 4S 4000 on wide-open field. Fooling around with auto-level recovery from sharp turns/banks. Altitude was bit higher than normal to have room for recovery.

Suddenly, with only minor stick input, it shoots to the skies! Throttle changes didn't do anything, except 0 (no disarm) got it to descend. Close to ground I gave a little bit of throttle and BAM, shoots up again. Without any control over other axis. Switched on autolevel so it would land flat when killing throttle. Didn't come down at all, even at 0 throttle. Turn off autolevel and one side drops like a brick. Another recovery on throttle caused it to full throttle up again, eventually I managed to get a somewhat controlled crashlanding.

Walked out to the unit, armed it to see if all was spinning and it rockets upwards again (nice and flat though)! Spun around frame-axis couple of time when killing throttle (I didn't feel anything like Warthox :P). Burying itself into the mud with one arm/motor eventually.

What could have caused this?
Prop failure wouldn't let it rise 'stable'?
Motor failure wouldn't let it shoot up straight?
ESC failure would have cause dropping like a brick instead of shooting up?
Sensor-overload seems unlikely as it flew much more challenging stuff earlier?
RX failure seems unlikely, because it did respond to switch and throttle inputs.
TX failure/interference? Last one seems unlikely as there wasn't anything on 2.4Ghz for at least 500m all around.
FC/software failure not to sure about?

Sadly the onboard video from that flight got corrupted as SD card came loose in crash.
Would like to hear your thoughts!

Originally Posted by kinderkram

You should ask Paul for a replacement.
When it got hot from the start then it looks like some defective part on th FC.
Paul is well known for his "no questions asked" policy.

I contacted Paul one day after I read your answer and he sent me a new one ;-) Paul has a first class service as he answered my mail very quick and got the new unit within a few days :-) I would recommend his shop at any time. Thx Paul! Hope to get the new one ready at the weekend ;-)

Hi,
I have a DroFly MPU6050 + MS5611 + HMC5883 + Atmega32U4 from www.drotek.fr.
I try to setup an OCTOFLATX configuration (multiwii v2.1). No luck up to now, some motor outputs are dead or behaves strange. In the GUI everything looks all right!
Could you share your config.h file and other adaptations you made to make it work? Also the esc connections!
Thanks,
manu

Originally Posted by marc von DEE

hi guys,

a couple of month ago, i wrote a little bit about an octo with FCP centerplates.
after having many issues trying to flash my esc, i ordered a set of 25A at Paul' s shop.
Those are allready flashed with the simonK firmware, and are compatible with the MT 3506

configuration:
OctoflatX, FCP centerplate, 16x1 alumium booms, MT3506-25 650 kV,12x4,5 props, SimonK 25A esc, 2x 3s 2100mAh flyduino, Divide E Impera V2, BMA020, ITG3200 MultiWii_dev_20120622 .
2950g with gimbal still empty... that's an octofat...http://www.youtube.com/watch?v=WLAvwiMmLNE&sns=em

the first part of the job is done now, maiden flight was this evening
fly' s with basic setup, only P on 7, I on 0.040, and rc rate on 2.
have to tune this a bit more, but that' s ok so far.



CU, marc

Hi,

I did some further measurements to try to understand why the Drofly, which is also based on the ATmega32u4 and "thus" similar to the "MicroWii.. ATmega32u4 Based 10DOF MultiWii FC"

4+2 Rx channel inputs,
I set only these from a original multiwii version 2.1 config :
#define OCTOFLATP
#define DROTEK_10DOF_MPU//
#define MINCOMMAND 1000
#define A32U4ALLPINS

Compile, check in the GUI=> ok octocopter
Mesure with a oscilloscope and i expect to have 1000µSec on the pins 11,10,13, 5, A2, 6, A3, 9
I mesure 1000 µSec on the pins : 9,6,5,10,A2,A3; 1043µSec on the pin 13 ; nothing sur 12,11,A1,A2,A5

//#define HEX6X
GUI=> ok hexacopterX
expect 1000µSec on the pins 6,10,11, 9, 5, 13
I mesure 1000 µSec on the pins : 9,6,5,10,A2; 1043µSec on the pin 13 ; nothing on 12,11,A1,A2,A3,A5

//#define QUADX
GUI=> ok quadricopterX
expect 1000µSec sur les pins 6,10, 9, 5
I mesure 1000 µSec on the pins : 9,6,5,10; ok but still 1043µSec on the pin 13 ; nothing on 12,11,A1,A2,A3,A5


#define OCTOFLATP
#define DROTEK_10DOF_MPU//
#define MINCOMMAND 1000
//#define A32U4ALLPINS
expect 1000µSec sur les pins 11,10,13, 5, A2, 6, A3, 9
I mesure 1000 µSec sur les pins : 9,6,5,10,A1,A2,A3; 1043µSec on the pin 13 ; nothing on 12,11,A3,A5

I don't get it! And always 1043 on the pin 13?

Thanks for help,
manu

Hi Manu,

I think you'll be more successfull getting the answers posting your questions in the correct thread
Not to push you away or anything, and I'd be happy to help, if i could...

Probably not too many people with Flyduino boards have experience with those (farely new) DroFly boards, please see the MultiWiiCopter thread.

I'm not sure if a ATmega32u4 is capable of running an octo, as only 6 hardware PWM outputs are available?
Or at least that is what is stated with the Flyduino MicroWii...
Have you tested the #define HWPWM6?

Hope this points you in the right direction and good luck mate!

#define OCTOFLATP #define DROTEK_10DOF_MPU// #define MINCOMMAND 1000 #define A32U4ALLPINS #define HWPWM6

Solved!
Thanks

Originally Posted by shufflez

Hi Manu,

I think you'll be more successfull getting the answers posting your questions in the correct thread
Not to push you away or anything, and I'd be happy to help, if i could...

Probably not too many people with Flyduino boards have experience with those (farely new) DroFly boards, please see the MultiWiiCopter thread.

I'm not sure if a ATmega32u4 is capable of running an octo, as only 6 hardware PWM outputs are available?
Or at least that is what is stated with the Flyduino MicroWii...
Have you tested the #define HWPWM6?

Hope this points you in the right direction and good luck mate!

Welcome

Hiya,

Been a while since i posted here, but glad to see everything is going well here.

Anyway i have been flying my flydumini on multiwii v1.7(i know its old but it worked LOL) anyway thought it was about time to try the latest stuff, see if things have settled.
So loaded dev 1240 and my pitch and roll have been reversed, checked with v1.9 and its OK, it seems things have altered on v2.0 and up. My sensor is a Drotek V2 i think(ITG3200 and BMA180) can anyone shine a light on whats going on and how to fix it.

I looked at the Flydumini thread first and there doesnt seem like much activity there so i apologise if im posting in the wrong thread.

Ray

Hi Ray,

From the top of my head there is an option in the code now to rotate sensor direction. Are you sure that it's actually reversed, or just 45%? Not at home ATM, but I recall that option being available in latest dev release I've tested.

Otherwise, you can always change + and - directions in sensors.pde

Hi shufflez,

Yep everthing is shifted 90 degrees anti clockwise(i think?) but i cant find any option to move it back. Im useless with changing the orientation code, i just cant visualise what im changing. I will have to unsolder the sensor and realign it i suppose(sigh) the trouble with that is i am then forced to remain with v2.0 and up from now on, which also means i have to sort out the I2C errors as well. Mm i'll probably just put it back to v1.7, it actually flies very nicely on that and its only a little indoor job anyway(200mm motor to motor) and you know what they say "if it aint broke dont fix it" and i do have others to play about with.
Anyway Thanks just the same