Multiwii and Megapirate AIO Flight Controller w/FTDI (ATmega 2560) V2.0

 XRAYAIR 218 points

Yes, it comes with the same USB connection as an Android Phone. Micro USB.

 alex.khoroshko 366 points

Yes. I've just received the board and this problem is fixed. That's why there's the "v2.0" in the product name. It is the same now, as CRIUS v 1.1. Works flawlessly for me.

 jrt-RC 33 points

thanks for the info Alex!

 ebourlet 22 points

Alex, you say that it is the same and everything works. Do you have you gimbal working? So far I have not been able to get the roll gimbal to work on this board.I have not been able to find anyone that has the roll gimbal working on megapirate with this board but have with the one that JT mentions. If you have can you share your setup?

 alex.khoroshko 366 points

Nope, I just said "works good FOR ME", which means, that all the functions I use are fine (most of the modes I use, GPS). I can test out for you, is the camera gimbal pin physically connected to the MCU you to be able to know, whether it's the board failure, or the software one.

 Farzin 222 points

Try #define MultiWiiMega instead of CRIUS_AIO_PRO_V1.

 alex.khoroshko 366 points

The most ultimate way - read the whole chip using USB ASP programmer, save hex - there you go. Anyway, I don't see any reasons to do so - compilation of both multiwii and megapirates is easy and you'll have the newer version in comparison to what was shipped with the board.

 edwiiiz 3 points

thank you Alex it's just because my sketch is not original I connected GPS and everything works fine, but I'm having problems with my PID settings I played all week but it oscillates no matter what I do. SO I thought I will update with new sketch and start all over again. Thank you

 alex.khoroshko 366 points

Hmm, that's strange. The way to start with the PIDs - set the I and D (if present - I work with megapirateng, not multiwii) to zero. Reduce the P significantly (by 2-4 times). At the beginning - the multirotor would not oscillate, but would be very hard to control. If still oscillates - reduce more. Then, you can increase the P until you get little oscillations, reduce it a bit - it'll fly fine. Then increase I and then the same way - D. Hope this helps - I don't think, that the sketch itself can be the reason. Also, sometimes, the weak booms can be the reason.

 edwiiiz 3 points

Thank you very much it is helpful because I had no Idea what I was doing. My motors are turnigy SK3-3530-1150KV and ESC's are turnigy plush 30A. Maybe you have any suggestions with what PID I should start. I use Mission planer. Should I change PID's in Arducopter Pids or in arducopter config ? at the moment my PID's are: Stabilize roll-P 2.1,I 0.65,IMAX 8.0. Stabilize pitch-P 2.1, I 0.65, IMAX 8.0 Stabilize Yaw-P 7.0, I 0.01, IMAX 8.0 Once again thank you for your support Alex. I know this information what I give doesn't mean a lot but maybe you can see something really wrong :D

 edwiiiz 3 points

www.link here is a good guide, but again He is talking about RATE PID's so do I need to do all of them separately (roll,pitch,jaw)? what about STABILAZE (roll,pitch,yaw) ? And he is saying tuning in acro mode. Just a little bit confusing for dummy like me :D it looks like it's simple but I want to know what I am doing. Actually now it's more complicated than before :D

 edwiiiz 3 points

:( I can't put link here sorry. it's arducopter tuning guide posted by Dave C. in DIY DRONES.

 alex.khoroshko 366 points

Find me on facebook - user a.u.khoroshko. I'll help you out with PIDs :)

 Farzin 222 points

You can use avrdude command line tool with options to read from atmega MCUs memory area the binary/uploaded sketch and save it in a bin/hex file, for late use or transfer to another MCU. Look up the commands and options in: http : // www . nongnu . www.link

 Farzin 222 points

link is the following but you must remove all spaces: http : // www . nongnu . org / avrdude / user-manual / avrdude_4.html # Option-Descriptions

 Jason 41 points

Ok... I connected another of these boards and still have the same problem so either I've ruled out the board or both boards have the same problem. However I believe it's not the board either because if I connect aile to the elev pin on the board it does respond. it seems whatever the signal that is being output on the elev channel on all the rx's i've tried (including 2 different brands, with two different TX's) isn't being understood by either the board or by Mission Planner. Still confused on this one. Has anyone else had a similar problem?

 Farzin 222 points

Reverse your Elevator channel on your Tx. Most probably your Throttle channel also needs to be reversed.

 Jason 41 points

Farzin ... I tried both and every combination of each ... no luck :( ... any other suggestions?

 alex.khoroshko 366 points

Do you mean there's no changes in mission planner - transmitter calibration tab? Anyway, it looks like you just tuned your TX in the wrong way so that there's no elevator sygnal on the receiver at all. Or your receiver is defective. It's obviously not the board, because, as you say, elevator channel works from another channel of your receiver.

 Jason 41 points

I believe I may have mispoke, the ELEV channel on the receiver does not show any movement in mission planner regardless of the pin I connect it to. I have also tried 2 identical receivers, then a completely different receiver and tx and still the same result.

 Farzin 222 points

I assume you connect your Rx channels to the Single Row header pins and not to Camera Gimbal port marked Roll,Pitch. The other thing is that you may not have a fully working sketch. Double check to see if you have configured correctly for your frame configuration (#define PIRATES_SENSOR_BOARD PIRATES_CRIUS_AIO_PRO_V1, FRAME_CONFIG ?, FRAME_ORIENTATION ?). Recompile and upload. It's worth checking your Aux channels and see if they affect the Mission Planners Pitch/Elev. It could be your Tx config.

 Jason 41 points

Farzin: I really appreciate the help, I thought I may have a bad sketch, I've now also tried this with a fresh copy of MPNG 2.7r4, 2.8r3 and 2.9 ... all have the same problem. I'm still working at it though lol

 Farzin 222 points

Do yourself a favour and load MultiiWii for Quad-X, just to see what your FC does. It's less painful compare to MPNG. Then at least you know if you have working/faulty FCs. Start with minimal attachments i.e do not configure GPS or BlueTooth etc.

 alex.khoroshko 366 points

How you guys don't understand, that when the other channel of receiver is connected to elevator and it works - then the reason is in the recevier or the radio itself. There's just no chance there's something wrong with the sketch, board. To check that out, you can try to connect any servo to elevator channel of your receiver. I bet it won't move.

 Farzin 222 points

My understanding was/is that Jason has tried other Tx/Rx combinations. Does he have two lots of faulty Tx/Rx? Or is he connecting every thing up in the correct/wrong way??? The only constant here is his sketch.

 v_max 454 points

And wires.... sometimes it can be also a reason...

 Jason 41 points

Ok ... I have solved this issue ... and since I had two boards with the same problem I tried the same solution on both and it worked. First I loaded multiwii (thanks to Farzin for the suggestion) and tested the radio calibration. This showed all channels working. I then loaded MPNG 2.8r3 once again and they issue went away. So solution is to load multiwii and if all channels are present reload mpng.

 alex.khoroshko 366 points

Hello! Download APM mission planner, connect it to the board, calibrate accelerometer. the standard button in planner didn't work out for me, so I opened the terminal in planner and wrote - 'setup', then 'level'. Connect the motors to the board and you can go tuning your PIDs

 v_max 454 points

Better to add bluetooth and connect to android multiwii gui application. (with multiwii firmware) Much more functionality to tune your board. And much cheaper solution, when you have already android phoner tablet.

 Noobie 69 points

I already had to do the BT as the usb on this board doesn't work, which is what I wanted to use. I only have the computer access to it, no android phone though. I did find that you can hack one to it, but it's not perfect either and I'm not sure how well it works either. Well, I was just curious. Thanks.

 v_max 454 points

I beleive LCD board is ****. Mount it forever isn't a good choice because of weight and power consumption, mount it removable is a headache.. And it do not give as much ease of use and capabilities as blutooth connection to phone, tablet or notebook.... Sure you CAN connect it if you use MWI firmware, but for my opinion this is not best solution.

 IBeHoey 393 points

Hey Eduardo, you sure can. Bluetooth is such a nice feature to have with this board, it makes tuning in the field a breeze with an Android phone. As for hookups, the GPS will plug into the S1~S3 port, and the Bluetooth will plug in to the FTDI port. Just remember to unplug the Bluetooth before you do any flashing. :D

 Eduardo 2 points

Tnks ibhoey...but i have another question, can i with this 3 features mount a programmable plc with c or c ? I do know a little bit of control in matlab that i can aply in this case...i will do an autopilot to follow a previos route or just keep altitude...using neural networking maybe...do you know someone who did that?

 v_max 454 points

You can just program anything you want, Multiwii and Megapirate are open source projects, so if fact you need to rewrite source code only and reflash the board. You are limited only with hardware capabilities of Atmega2560 (memory, CPU speed) and of course with your own fantasy and skills. P/S/ BOTH MP and MWI has the return to launch mode with GPS (not by route but just to point) So you are probably reinventing the wheel.

 Farzin 222 points

Eduardo, one step at a time. The next release of MultiWii will be supporting Way Points - if this is what you are trying to achieve. MegapirateNG does that out of the box. Have a look at the source code, if you are familiar with programming in C.

 v_max 454 points

If you power FC from ESC, you can plug it on any free motor port on FC board.

 Mogabure 1 points

I power my FC with an UBEC on extend power. So that's why this way is impossible for me. Maybe from the RX. But I would prefer from the board ... Any idea ?

 IBeHoey 393 points

Hey Mogadore, I've powered many LED setups through a spare channel on the RX without any issues. If that's simply not an option for you, you could use some of the spare molex cables, that comes with the board, and just tap into the I2C port. :D

 Farzin 222 points

Easiest way is to use the header pins along the row of pins that your Rx cables are connected to (clearly marked GND,plus5V). On the back of FC also marked GND, plus5V, closest to the throttle. No plus 5V is available on the motor ports, since you must remove the bridging jumper when Extend Power In, is utilised.

 Farzin 222 points

...Be careful not to overload the onboard 5V regulator. If you are using a UBEC, you must have the option of setting 5-6V output (supply 6V to Extend Power In header). Make a Y cable and pinch the power from the UBEC. Your 3-LED strip is hardly any load. But, if in the future you decide to add other things, bear that in mind.

 Farzin 222 points

...One other thing, you cannot directly plug that 3pin connector to FC, as its polarity does not match the FC header pins. Either swap the little connectors, or simply cut the unused part so, it can plug in without fouling the throttle header pin.

 v_max 454 points

Farzin, all motor ports power pins connected in parrallel, so if you have ESC with ubec plugged in one port then it will power all other motor port pins.(That's why you need to disconnect all 5v pins on all ESC connectors except one) The power mode jumper connects 5 ESC ports power line with internal board power. Thus you CAN power leds from free motor port when you have at least one ESC with UBEC plugged in. Doesn't matter how you power FC board, with esc or with ext port.

 Farzin 222 points

v_max, thanks for your initial solution (spot on and functional) and comprehensive explanation given above which holds true, until the last sentence/statement. If the board is powered via Extend Power In, the bridge jumper must be removed (Mogabure's case - no 5V will be available on motor headers). Please clearly explain, the purpose of having another set of 5V on the motor pinouts, where in fact you would only need to connect ESCs' signal wires (outputs from FC to drive ESCs). Thanks for your enthusiastic participation, we are all here to share knowledge and learn from each other.

 v_max 454 points

If the board powered via extended port AND jumper removed, then motors ports power pins line is disconnected from FC power. That's right. But if this ESC have UBEC then why not to use ESC UBEC for powering leds? You do not need even soldering and connecting. Just plug ESC to motor port and plug leds to another free port. This is just simpliest way for my opinion... isn't it?

 v_max 454 points

From the point of view of flight controller this doesn't matter. FC is one of the best on the market for today. BUT....do not think your setup is good. D3530/14 1100KV is overkill with 8045 *3S battery. This motor designed to operate with more load (larger props or with higher voltage) Even smaller and lighter 2830-11 is optimal for 1045 or 1145 props at 3S. This motors will drain out 2200mAh in a few minutes in this setup. And it wouldn't give much trust with so small propellers. Google for "xcopterCalc - Multicopter Calculator" go to first result and calculate your setup. Doubt you will get more then 7-8 minutes of hover time.

 v_max 454 points

Yes, you can do whatever you want. This is Arduino compatible board. Anly limitations are available memory, CPU speed and your programming skils.

 Farzin 222 points

Strictly speaking No, this is not possible on the FC board. All FC pin-outs are designated to do a particular operation on initialisation and later via the control loop i.e input/output/PWM etc. and that you cannnot mock with. Unless you know how to reconfigure/rewrite the whole MultiWii software code. If your FC boots/initialises, my guess is that you do not arm the FC, so there is no response from the throttle. You may have to reverse your throttle channel/throttle range set first on the Tx and try to arm the FC. Hope this helps.

 timothy 4 points

yea thats what i was afraid of. i can see all tx inputs on the gui, thrott used to work before i made some mistakes- now i dont even see the throt on the gui anymore,but other controls ARE responding. looks like i need a new board. maybe i should downgrade to a simpler fc, like a kk board? till i get a better feel for the tech???

 Farzin 222 points

Sorry, to hear that, but do not despair. Connect one of your motor's ESC to Rx throttle channel (bypass the FC and have nothing else on the RX) and see if the motor responds (no props on or be careful). If successful your Rx is ok. Then connect up as before with all motors etc. and try to arm the FC. Arming the board lights up a green and orange LED on this board. If that does not happen, try to adjust the Tx throw range on your Yaw and Throttle channels. One other thing, you may have to decrease the MINCOMMAND in the config.h #define MINCOMMAND 950 and reflash the FC. That would bring you to a stable starting point.....or you have blown your FC.

 timothy 4 points

wow! believe it or not i understand everything you said! alot to learn and i'm a newbie. 8 wks ago i didnt know what arduino was... looks like its the board :(

 timothy 4 points

what does one yellow flashing mean? is there a flash code chart somewhere?

 timothy 4 points

found it...

 v_max 454 points

Farzin, you are NOT right pins assignment is a few rows in def.h //Standart RX #define THROTTLEPIN 3 #if defined(A32U4ALLPINS) #define ROLLPIN 6 #define PITCHPIN 2 #define YAWPIN 4 #define AUX1PIN 5 #else #define ROLLPIN 4 #define PITCHPIN 5 #define YAWPIN 2 #define AUX1PIN 6 #endif So, that's relatively easy to swap Throttle with Aux

 timothy 4 points

so i could make it THROTTLEPIN 6... and AUX1PIN 3???

 Farzin 222 points

v_max - My statement was qualified by saying "Strictly speaking". Of course, you can rewrite the whole thing to your liking because it's open source. But def.h is not the domain of average users, it's were all configurations are finalised based on config.h values. And where you are directing/pointing is actually for atmega32u4 (Promicro). Who is wrong???. What about Atmega2560 which is this particular Arduino based FC, with its own specific ports and hardware PWM pin-outs etc. Do not raise false hopes here. If you are a programmer, have a read of #if defined(MEGA). The forum is not for scoring points, its there to brain storm and share experiences.

 v_max 454 points

1. You do not need to rewrite WHOLE code. Changes is localized in 2 lines. 2. Unfortunatly form do not allow formatted text. There is simple #if ... #else ... you just not noticed because of formatting. So #if is for atmega32u4 #else is for all other CPUs icluding Atmega2560. I checked the code specially for this case. 3. Have no doubts this is possible, you do not need to be programmer to swap numbers in 2 lines. So this is not false hopes. 4. You already got your points for this question, so you may see that it isn't my goal. I just want to help in nonstandard situation and point to solution.

 v_max 454 points

Thimoty, YES! you need to open in arduino file named def.h and find line "//Standart RX" Change next line "#define THROTTLEPIN 3" to "#define THROTTLEPIN 6" then in #else block (few lines down) change "#define AUX1PIN 6" to "#define AUX1PIN 3" Recompile and reflash the board. Then you can use AUX1 input for throttle

 v_max 454 points

OHHHH... yes, Farzin, right....I'm looking in wrong place... For atmega changes need to be done in other place,

 v_max 454 points

For this FC, in def.h find line /************************** all the Mega types ***********************************/ and below this line change #define THROTTLEPIN 4 and #define AUX1PIN 0 Sorry, for mistake. FARZIN, you are right! I looked in wrong place

 timothy 4 points

You guys are a trip! Thx for all your help :)

 timothy 4 points

hey guys, for what its worth- it worked! i now have throttle INPUT showing up!!! but i'm afraid the board is dead anyway... it no longer has any gyro,acc,mag, at all. and this was before flashing new program. i already have a new one coming... what the heck-its only money :)

 timothy 4 points

TO OUR READERS- these problems i've been having are entirely my fault. hk sell fine products *)

 timothy 4 points

OMG EVERYBODY!!!! I GOT IT WORKING!!!!!!!

 v_max 454 points

Congratulations *) and happy flying!

 XRAYAIR 218 points

Try a reset, then remove the center wire from all of the other 3 ESC's so they won't keep trying to power the board.

 v_max 454 points

When connect ESC, only one ESC ubec must power the board, you need to remove 5v pin from all ESC connectors exept one esc. The next, may be one of you ESC UBEC is faulty and give full power woltage to the board. Check the ESCs 5v outputs first vith voltmeter. Next, if you see resp in GUI after that's mean that board may be alive.... I think reflash might help. At least reflash wouldn't make things worth. Well, you need to find where fault is if your board do not show throttle responce in GUI. You can plug other RX channel (rudder for example) in throttle input on bord to check is board input pin ok or not. If throttle will respond on rudder stick with this connection then probably problem is in RX output. (I guess you may powered RX with overvoltage) and this might cause RX fault, not board. In any case I can guess thet probably one of ESC was faulty. Either it has shortened UBEC to full power, either shortened signal pin to power or to 5v.

 timothy 4 points

oohhhh! ok!!! i didnt know about the "one" esc pwr source! thank you guys so much! and thx for the diagnostic tips on whether its the board or rx, now i can move fwd! this forum is great!!!

 timothy 4 points

now that i think about it, i did connect one esc direct to the rx and it worked, i will check them out w my volt meter... thx again!

 IBeHoey 393 points

Hey Jake, to start off, the I2C-GPS NAV Module you bought is used to convert the serial data, from the GPS, to the I2C protocol. It'll basically allow you to connect a GPS module to the I2C bus, which is found on all flight control boards. Unfortunately, you're not going to need it with the (Crius All-In-One-Pro) board you ordered. The reason for this is because, the ATmega2560 processor, that's used on this board, has a total of 4 serial ports that can be used, which the NEO-6M GPS module will plug into. If you were using another Multiwii board based off of a Atmega328 processor, which only has 1 serial port (reserved for flashing and the GUI interface) you would then need the I2C-GPS NAV module to connect the (serial) GPS module. As for the USB/FTDI adapter, mentioned in the NEO-6M description, it'll be used to reconfigure the settings of the GPS module (Baud rate, protocol). They can also be bought from here for around $6 (ID#009000003). Whether you need one or not, is debatable. If you plan to only run the Multiwii firmware with this board, the NEO-6M GPS Module will work right out of the box, no reconfiguring required. Later down the road, should you decide to try the megapirate firmware, or wish to just simply change the settings of the GPS, then you'll need to have one. The USB/FTDI can be used for other things as well, so it's a handy little tool to have around. For instance, should you ever accidentally break off the USB plug on this control board, you could then use the USB/FTDI adapter in it's place to reflash the board. :D

 Jake 1 points

Thanks so much for the response* been trying to figure this out myself with no luck. Wouldn't have ever gotten into stuff this complicated but I lost a tricopter carrying a GoPro and I need RTH...Oh ****...this is the correct gear for RTH, correct? Again, thanks for the help mate!

 IBeHoey 393 points

Hey Jake, glad I could help and thanks for the credit. :D Sorry to hear about your tri, were you ever able to find it? Yep, with the gear you've chosen, and with the Multiwii firmware, you'll have both RTH and POS hold features. In the near future, Multiwii will also support GPS waypoint programming as well. I have to tell you though, don't expect the RTH and POS hold to work right out of the box. I'm not sure what control board you were previously using with your first tricopter, but with Multiwii (and megapirate for that matter) you're gonna have to do some tinkering and tweaking of the PID values to get everything dialed in. It can be a bit overwhelming at first, but once you have a solid understanding of what the values are, and what they do, tuning a new board will come 2nd nature. On the plus side, the Multiwii platform is very popular, so there are tons of guides and tutorials out there that can help you along the way, or you can just simply ask in here. Depending on your application, and how involved, or complicated, you want to take things, you might want to check out the megapirate firmware as well. I wouldn't recommend trying it until after you've figured out Multiwii though, as there's literally twice as many values and settings to tweak, but in terms of GPS features, it's the cat's pajamas, so to speak. It'll turn your tricopter in to a bonafide autonomous drone. :D

 Jake 1 points

Nope, never found it. Looked the last couple days, but the area I last saw it was pretty large. I was flying out over a valley in Idaho when I lost it. Hiked down and looked everywhere (surrounded by cows) I thought it could have crashed, but no luck. Spent all yesterday reading about this board and it definitely looks complicated. The tri I lost was using a KK2, which was great for what it was, and simple, but the GPS thing is mandatory after this experience. I'll be happy with the MultiWii firmware for quite awhile. I understand the concept of the values after using the KK2, but it seems people had trouble even connecting the board to their computer, and the micro USB port breaking off very easily. Another question: why is it suggested to have an external BEC for the gps? I've never messed with one, but in the manual it is advised. I don't want to overly complicate it, though. Sorry to inundate you with questions, but can you possibly post some helpful links? I'm trying to educate myself as much as possible before I get the board. Very anxious to get flying again. Thanks for all the help Hoey, very kind of you!

 IBeHoey 393 points

That stinks, hopefully it'll turn up. If there's any upside to a bad crash, it's that you usually learn something from it. I nearly lost my first quad when I took it to the park for the first time. Had it up way too high, lost orientation, and I slowly watched it disappear over the tree line. I'll never forget that walk of shame lol. Spent a good 8 hrs hiking through the woods looking for it. Had it not been for a $2 low voltage LiPo alarm (ID# DL-Volt-Alarm, HIGHLY recommend picking one up if you don't have one), there's no way I would have found it, shredded to pieces, 20ft up in a tree. Luckily, my search drew the interest of a good samaritan who happily climbed the tree for me. If not for him, there was no way I was getting it down. The frame was wrecked but the electronics turned out ok, still use them to this day. The problem people have connecting the board to their computer, more times than not, is just a driver issue. If you've never connected a FTDI device to your computer before, you'll need to install the driver which can be found in the Arduino IDE folder. If you don't already have the Arduino IDE installed, you should go ahead and do that and familiarize yourself with it (I'm pretty sure it's covered in the manual). The weak USB port is an issue but so long as you're careful with it, it's not going to fall off. It is recommended that you should put a small glob of epoxy over it to help protect it. If you do use epoxy, just make sure you don't get any inside the port. Also, if the port should break off, you can also use a FTDI/USB adapter in it's place. As for the external BEC, when you have the GPS plugged in to the S1~S3 port, and you're powering the board via the ESC's BEC, the GPS is not going to get any power. The only way to power the GPS from the S1~S3 port, is by using the extended power port on the board. That being said, you don't need to power the GPS through the S1~S3 port, all you have to do is just draw power from somewhere else on the board. In other words, an external BEC is not required when using GPS. One thing nice about this board is that it comes with a lot of molex connectors/cables. Using a xacto knife, or a small pin, you can easily pull the wires from the molex plug, and swap them out. What I did was just take the power wires from the GPS, plugged them into a 4pin molex connector, and used the I2C port to power my GPS. (See attached picture) target=_blank> I've been running it this way, as well as others, for awhile now with out any problems. The BEC on my ESC is rated for 2amp, even with the servo, I'm well below that. It's totally up to you whether you want to use one or not, I'd say, if you can afford the added weight, and/or cost, you simply can't go wrong with using one. I'd like to post some helpful links but it's not allowed here in the discussion thread. One thing you should know when reading up, and trying to find info on this board, is that it's actually a clone of the "Crius All In One Pro v1." If you do a google search for "mealie, CRIUS ALL IN ONE PRO v1.0 Multi Rotor Flight Controller" you'll come across a RCGroups thread that has a TON of good info in it regarding the board. For info on Multiwii, google "MultiWiiCopter (previously TriWiiCopter)" and you'll come across another RCGroups thread. One last tidbit of advice that I can give you is to just take it one step at a time, and to go slow. There's a lot to absorb here and it's very easy to over look something. Also, when you go to hook everything up, double/triple check your connections, then check them again before adding power. A small mishap here and you can easily turn something in to a fancy paper weight.

 Jake 1 points

Gotcha, thanks for all the help mate!

 v_max 454 points

Check the "files" tab. You will find several manuals and instructions. Not bad to start with.... I'd recommend to start with MultiWii 2.2 firmware, it's siplier then Megapirate.

 sean 5 points

Thanks v_max for your speedy reply and info

 v_max 454 points

The next point is "MultiWii is a software to control a RC multi copter". HK do not allow to post links, just google for it and go to the first result. And one more usefull resource is "MultiWii FAQ" (google for it, first result)

 Robert 5 points

Go to RCGroups and look at RCJOSE's blog. He has a bunch of videos that explain every aspect of the AIO pro.

 sean 5 points

Thanks Robert very useful vids on RCJOSE's Blog. Cheers.

 Nigel 3 points

Arduino 1.04 but I have thw windows c aswell if that helps

 Farzin 222 points

Hi IBeHoey - Have a look at the following video. Your PID settings should not have any effect on the servo while at rest. The PIDs come into effect when there is a detected change in the IMU (Inertial Measurement Unit) sensors, hence compensating/correcting. I will be interested in solving this too. My guess is electrical noise, as per the video. The FC driver circuit cannot drive the servo cleanly!!

 Farzin 222 points

...has the routing of your cables been changed in the new frame? Look for silly things like that, if you are sure that the servo itself is sound.

 Farzin 222 points

...if you are running an extension lead with your servo, wrap it around a ferrite core or keep its length to minimum.

 alex.khoroshko 366 points

I was fighting this problem a lot with my kk2 board and digital servo. I did plenty of research and here's my conclusion. Most of tail mechanisms are done wrong - all the mass of the motor is placed on one side of rotational axis. So, when the tail motor turns, the center of mass instantly moves to another point, so the tricopter turns even though the motor's thrust didn't take any effect yet, or even when the motor is off. Try to connect the servo to servo tester or receiver and move it rapidly - you'll see that the tricopter yaw is changing even though there's no thrust at all. Here's my idea - I've placed the axis of yaw mechanism somewhere close to the motor's center of mass (actually, it's too low on the photo, but it worked!). It helped A LOT, I didn't beleive, how much better the yaw started to function and feel in flight. Also, when you do so, the servo would have less torque to cope with, so it's life span would increase. The digital servos tend to oscillate this way more, because they move the motor instantly, unlike the analog ones, which need the great error to reach the full torque. target=_blank>

 alex.khoroshko 366 points

Also, I've come to a conclusion, that the mini servo, everybody use, are way too small for my 2836 motor. I replaced it with the Corona DS329MG servo, and that's when the fun began! I know, it's heavy, but my motors are heavy as well, and the reliability pays off completely - I crashed it from 10 meters, the tail mechanism was bent, but the servo is still like new! So I suggest going for bigger servo, 3kg at least for your config (it would last forever)

 Farzin 222 points

Excelent explanation and solution as far as the mechanical setup is concerned. But the problem is present when the tri is at rest. I tend to think electro-magnetic interference from some device. I have my own version of tail mechanism, designed exactly with those thoughts. See photos:

 alex.khoroshko 366 points

No, your tail is just like the others - when your mechanism changes the angle of the motor, the whole motor moves sideways, as it is placed above the rotational joint. Let's make the mental experiment. Imagine, the tri is in front of you, tail in. Your motor moves counterclockwise around its yaw joint, so the center of mass moves left (the whole motor moves left!) This would cause the boom to move right, to compensate the inertia. The flight controller senses the change and tries to compensate - by moving the motor further to the left! So, we get the self-amplifying process. Do your oscillation happen always, or only when armed? If when armed only, then I consider, that my version is correct - this mass-shifting issue would work even when the motor itself is completely shut down and the tri is on the ground. Try to hold the rear boom near the yaw mechanism with your hand as hard, as you can. If the oscillations would decrease or disappear, that would proof the mechanical reason of oscillations.

 Farzin 222 points

Are you talking about the gyroscopic effect caused by changes in the rotational axis of the motor? I am aware of that, and cannot easily be rectified with our simplistic designs. We can only hope to reduce its effect by proportioning the booms correctly, and introducing a dampening effect.

 alex.khoroshko 366 points

No, not gyroscopic. Take something heavy (10kg is fine), hold it above your head on the straight arms, and then try to move it to the front of you as fast, as you can. Your whole body would unavoidable move backwards (the law of conservation of momentum that is). That's exactly what happens to the boom, when the tail mechanism moves the motor sideways. But if the center of mass would stay in the same position (it should lay on the axis of rotation for that), then this effect wouldn't be present. Google for "Mass properties factors in achieving stable imagery from a gimbal mounted camera". There's a very good illustrated explanation to what I'm trying to say (English is not my native language, may be that's why it's not really understandable from my words).

 Farzin 222 points

I get what you are suggesting, and this is evident from your photo. But you are using a direct drive method, which is very onerous. Unless you have a reasonable mass relative to the whole assembly at an offset, this effect would be negligible and will be resisted by servo/drive stiffness and further dampened by friction alone. A good bearing design would overcome/resist the induced imbalance/offset mass. I tried to keep my motor assembly/mass as low as possible to its axis of rotation, but not perfectly. Regardless, this is a good discussion and I will research it further. Thanks.

 alex.khoroshko 366 points

Not sure, was I able to reach you in my posts, but anyways... Also, my tail design is bearing-supported (I use the 4x8x4 bearing press-fitted into the aluminum strip, holding the motor).

 Farzin 222 points

IBeHoey - one more thought, have you tried to plug the servo lead into a spare Rx channel, instead of the FC. Just to see if there is some noise on the rails.

 IBeHoey 393 points

Oh, wow, thanks guys. Had no idea I'd get this kind of response. :D Alright, where to start? As per suggested, I tried recompiling the sketch in Arduino 1.0.4 but saw no improvement. Farzin, as for interference, I'm using the same wiring harness from the old frame and the wires are all routed very similar (across the bottom of the frame with zip ties). I rerouted the servo lead, out from the frame, and even tried wrapping a ferrite coil with no luck, it still has that small twitch in flight. Okay, as for the shaking I was experiencing when the tri was grounded and un-armed, I resolved this and found it to be caused by poor frame design. The 11x11mm wood booms I was using were not stiff enough, which would cause the tail boom to shake when the servo moved, resulting in oscillation, even when un-armed. To remedy this, I ended up running a, roughly 4mm plywood blank across the whole bottom to stiffen it up. So no more tail wag. :D With this frame and setup, my goal was to keep things as light as possible. I'm using 24gram Hextronik 1300kv motors with 12A Turnigy plush ESCs flashed w/ BLHeli FW. The motor spacing is roughly 400mm. AUW without battery is 380grams. I posted some pictures of my yaw mechanism (notice the mismatched linkage stoppers :D, it's all that I had on hand.) I'm always open for suggestions and/or improvements. The yaw mechanism itself is very smooth, there's no slop, and hardly any resistance. I was skeptical about using zip ties to secure the motors and servo, but after doing so, I'm now a believer. Not to mention how many grams were saved by not using screws. The mass-shifting theory is something that I have never thought of, and it looks like I'll be doing some reading of my own. I don't believe the servo is under powered in my application, but I could be wrong. I had a lot of success with the 9gram servo on my last frame, aside from stripping gears on "rough" landings of course. The TGY-9018MG I'm using now, listed, has twice the torque, which is why I chose it. To throw another curve ball in to this equation, last night I decided to swap out FC boards and hooked up my old HK multirotor 2.1 board. After a few pot adjustments, it flew on rails. No servo twitch, or anything, it flew really well, and oooh the power. 13min flight on a 1600mAh 3s. Is it safe to assume that the twitch issue I'm experiencing lies somewhere between the AIOP board and firmware? What about the servo refresh rate? Could it be something with that? At any rate, I look forward to further discussion regarding my issue. I'm sure between the 3 of us, we'll figure it out. :D target=_blank> target=_blank> target=_blank>

 Farzin 222 points

Default servo refresh rate is 50Hz. But you can try #define SERVO_RFR_300HZ for digital servos. The booms/arms proportions (over all stiffness of frame) are very important when in-flight, and you have resolved that - Great. But the jitter mystery remains when static!!?

 IBeHoey 393 points

Heh yeah, getting closer. The static jitter is gone, I'm just still getting that small jitter while in the air. I just got done running a few battery packs through it, did some more tweaking with the PID settings. Sigh, the small twitch is still there but man, aside from that, she's rock solid. I don't really notice the twitch much in forward flight, not saying it's not there, but it doesn't seem to effect it much. On the last two packs, I was pulling some pretty hard stall turns and it remained locked in the whole time. Ahh, but that little twitch it does when hovering around is going to drive me up a wall. If it weren't for a storm rolling in, I'd try to get some more video of it twitching in the air. It's a lot more stable now than the last time I tried to record. Guess I'll just have to wait until tomorrow. If I find the time later on tonight, I thought about loading up the megapirate firmware and giving it a go. Just to see if it twitches or not. Then again, it could be that I'm just expecting too much from a $5 servo lol. I'll give the refresh rate a try, I know it's currently set to 50, are there any set increments that I should take when increasing this value? :D

 Farzin 222 points

No, there is only this option for digital servos. Jitter may result if there is both an overshoot and undershoot. The servo tries to reach where it's suppose to be incrementaly and the slew rate is not optimal.

 Farzin 222 points

...incrementally, I do not know how to spell :D

 jerryatrik 16 points

servos can jitter because of simple dynamic resonance at certain flying conditions. mostly just annoying and unavoidable. a small change in CG can fix it or something to change the natural frequency of the system. for instance i put a piece of foam in the back of the fiberglass tri to keep the jitters out of the hover range.

 IBeHoey 393 points

Alright guys, once again thanks for all of the help. The small twitch is still there but it's hardly noticeable and doesn't appear to effect the performance, so I can live with that. This tri is only going to see light aerobatics and night flying anyways, so a little twitch isn't going to hurt. :D I posted a video below of the yaw servo in action, just ignore that ugly mug on the sticks.

 IBeHoey 393 points

Arg... Let's try this again.

 IBeHoey 393 points

3rd time the charm?

 Farzin 222 points

IBeHoey - nice one. Is your prop tracking properly? Some of these SF props flex too much, and they may suffer from Retreating Blade Stall, in translational flight, leading to slight loss of lift and IMUs demand for more rotation and more torque to overcome etc - hence a twitch that quickly gets dampened. But in your video it's not clear if you are translating back and forth too aggressively. Tell us, the static twitch has disappeard altogether, Has it?

 Farzin 222 points

...Viewed from rear, I fly my Tris with Front LH motor and rear motor rotating CCW (Normal Pitch props), and Front RH motor rotating CW (Right Pitch prop). This seems to help the in-flight twitching. The frame may have less counter torque to deal with. Give it a go if you have a RH prop.

 IBeHoey 393 points

****

 IBeHoey 393 points

Really?!? I spent a good hour writing my last response and it gets deleted? Only possible reason I can see is because maybe I mentioned another retailer? Or maybe it's because I said the SF gemfan props sold here are not nearly as stiff as the SF gemfan props sold elsewhere? Anyways, Farzin, not sure if you got a chance to read my reply before it was censored but the static twitch (un-armed and on the ground) is gone. The twitch I'm still trying to resolve can be seen in the video from 0:33-0:39 (during this time period I let it hover without giving it any rudder input.) I'd also like to add that I did some experimenting with prop direction. In the video, I had it set up as so: FL-CW FR-CW R-CCW. Switching to FL-CCW FR-CW R-CCW seemed to help with the overall stability of the Tri, but the small twitch is still present. In fear of being censored again, if there a way I could contact you off of this discussion thread? For instance, do you have a RCGroups account? If so, my name on there is the same on here IBeHoey. If you wouldn't mind, I'd love to get your input on a new Tri build I'm about to put together. Once again, thanks for all of your help. :D

 IBeHoey 393 points

Hey Nigel, what firmware/GUI software are you trying to use?

 alex.khoroshko 366 points

Looks like physical connection failure. Make sure that you use the functional cable, that the board is powered on and that the USB port you're using is not dead.

 Farzin 222 points

You are missing the USB driver - install it from the arduino/driver folder i.e Arduino MEGA 2560 REV3.inf, if you are using a PC and not a mac.

 Nigel 3 points

Thanks man that sounds like the ticket

 IBeHoey 393 points

It sure dos Mateusv, I use the very same one. If you plan to use the Megapirates firmware, you'll have to reconfigure the GPS (setting baud rate and protocol)via U-center first using a FTDI/USB dongle. With Multiwii, no reconfigure is required other than uncommenting the "#define UBLOX" protocol within the Arduino IDE. :D

 jerryatrik 16 points

no need to reconfigure the gps for megapirates. i used mine right out of the bag...

 v_max 454 points

If you see that throttle channel bar in GUI responds then you simply must arm the motors. Thrortle to minimum and yaw to right. After this motors dhould start at minimum idle speed. If this not happens you need to check first that Throttle minimum value in GUI is below 1100 and yaw maximum value is above 1900 (this is arming thresholds). If you do not have enough range on all sticks from 1000 to 2000 in GUI then you need to calibrate transmitter and adjust endpoints for channels. And last thing before you start your motors, you need to calibrate escapes. I can't post link here, just google for "multiwii wiki esc calibration" and go to first result. Good manual.. And do not forget to remove propellers before calibration*)

 XRAYAIR 218 points

Sometimes we have noticed with the 9X receivers, that we need to power them separately, and not from the flight controller. Might help with channel failures...

 Mathias 2 points

That's the problem the throttle bar in GUI do not respond. Thanks a lot for the tips. I shall try them all.

 slyhq 120 points

Try going to Tools/Boards and select the correct model, ie. ATMega 2560. Else run the EEPROM->eeprom_clear before trying to load your config.

 v_max 454 points

Go to Tools->Programmer and select Arduino as ISP

 Alessandro 1 points

I have tried all the solutions that you have given me, the board is correctly connected the drivers are ok, if I open the program MultiWii read and communicate with the card, even if I select Arduino is an ISP can not do anything and the error is always the same avrdude: stk500v2_ReceiveMessage(): timeout avrdude: stk500v2_ReceiveMessage(): timeout avrdude: stk500v2_ReceiveMessage(): timeout avrdude: stk500v2_ReceiveMessage(): timeout avrdude: stk500v2_ReceiveMessage(): timeout avrdude: stk500v2_ReceiveMessage(): timeout avrdude: stk500v2_getsync(): timeout communicating with programmer

 XRAYAIR 218 points

Try installing the newest J * A * V * A * S * D * K...

 v_max 454 points

MultiWii GUI is running? Disconnect GUI. Or you do not selected correct serial port Go to Tools->Serial port and select correct port. When port is not correct you will get exactly this message "avrdude: stk500v2_ReceiveMessage(): timeout"

 v_max 454 points

Oh yeah, port will appear in choice list only when usb is connected to board

 Alessandro 1 points

**** software is ok, I've tried uninstalling everything and recharge MultiWii software is turned off when I use the Arduino software The serial port to use with the Arduino software is the same that I use when I open MultiWii I use a Mac computer, thinking that the problem was the mac I tried with windows xp, but the error is the same I use a usb cable to 30 cm. I have to connect the esc to the board? I have to use external power to power the card?

 v_max 454 points

I reproduced the error when I set wrong port. Tools->Serial port This might mean that either port selected wrong in arduino or port is already opened by GUI and thus busy, either USB device is not connected (bad cable, usb connector contact fault), either USB do not power the board (normally USB power it OK, and you do not need to connect lipos, but may be you connected some power consuming periferials and usb is over current limit). either you have some periferials connected to serial0/ftdi connector. Bluetooth may be? "I have to connect the esc to the board? " Normally no need. "I have to use external power to power the card?" Normally no need. USB power must be enough. I'd recommend to disconnect all from board. Leaving only USB connected

 Alessandro 1 points

thanks for the help the board is disconnected from any device, only the USB cable is connected to the card. ftdi driver allows me to read the data on the card when I use the software MultiWii and allows me to have the serial ports to be selected when using the Arduino software, in fact if I leave open the Arduino, MultiWii software tells me that the port is full. I start to think that my card has problems

 IBeHoey 393 points

I'm not a mac person so I can only advise regarding XP. When you plug in the controller, have you tried opening up the Device Manager to verify that the driver is properly installed, and to also check to see what COM port is being assigned to it (port settings/advanced)? You might want to also try changing the port # as well. Just a thought. :D

 Farzin 222 points

My 2 cents worth - grab the latest Arduino SDK and re-install it on your mac. Your comm ports and other stuff are all OK, as you have explained. If you still cannot load, try to press the reset button on the FC after the Binary Sketch Size message appears, when you click upload. You may have to try this several times before you succeed. As there is a 3 second delay before the bootloader kicks in. I have also managed to program these FCs by selecting AVRISPmkII from Tools/Programmer menu. Have a go...

 v_max 454 points

Alessandro, this probably mean Arduino installation problems, do you install drivers as part of arduino installation? Farzin, right. I'd try to reinstall arduino first. The second thingie, probably you have bootloader corrupted on card. You can try to connect USBASP proframmer to ISP port and reflush curd with it (including bootloader)

 Rodrigo 1 points

I'm having the same problem here(missing bootloader i supose). I Bought a USBasp and didn't work too (old firmware - serial clock problem)my next try will be to buy an AVRisp programmer.

 Helio 1 points

Rodrigo, same problem with me, same error. Im trying use the serial1 port using ftdi usb converter but the problem persists. If you read this discussion list you will see another people with the same problem. Perhaps hobbyking has a lot of defective boards. Lets keep in touch to see how to solve this problem, I dont wanna wait 1 month again to take my board.

 Alessandro 1 points

I think the only explanation is that the card is broken. There is no other explanation, I am sure you have put everything in the right way, drivers, cables, speed doors

 Farzin 222 points

One other thing, in your config.h, what FC board type are you selecting? Make sure you only have #define MultiWiiMega uncommented.

 IBeHoey 393 points

Hey Ntc, I'd be glad to help but I'm going to need a little more information first. Are you having issues powering the GPS, or is it a setup issue you're having?

 IBeHoey 393 points

Alright, starting from the beginning, the GPS is going to plug in to the port labeled S1~S3 on the AIOP board as so: GPS-TX = RX2, GPS-RX = TX2. If you plan on powering the AIOP board using an external source (BEC) via the extended power port (don't forget to remove the yellow jumper), then the GPS's can be powered through the Vcc and GND pins on the S1~S3 port. If you're not powering the board through the extended port, then you'll need to draw power for the GPS elsewhere on the board. Personally, I use the VCC and GND pins on the I2c port. Now that power is taken care of, the last thing you need to do is open up the Arduino IDE and make a few changes to the Multiwii Sketch. Under the config.h tab, scroll down until you find GPS. Under the GPS protocol, make sure you have uncommented, removing the two "//" in front of the "#define UBLOX" statement. After that, reflash the board with your changes and you should be good to go. :D

 Ntc_heli 85 points

hi iBeHoey, that is really helpful, I am powering the board via the extended power port, so will connect all wires to the S1~S3 port. so just to confirm there is no need to fiddle around BAUD rates for the GPS??, as I have don't what you said in the code and will try out today. Als odo you know how to wire the Bluetooth module to the AIO board? ie what wires go where? is it simply RX to TX, TX to RX, GND to GND, but where does the VCC on the Bluetooth go, there is no VCC on the FTDI port on the board?

 Farzin 222 points

Ntc-heli - S0/FTDI port pinout: (gnd, gnd, 5v, rx0, tx0, dtr)

 IBeHoey 393 points

Yep, with MultiWii there's no need to reconfigure, or change the baud rate of the GPS. If you were to go the megapirate route, then you would need to reconfigure the GPS using the u - center software. As for hooking up blue tooth, just hookup as per Farzin's directions. :D

 v_max 454 points

Use GPS-TX = RX2, GPS-RX = TX2. on s1-s3 port and power (VCC) from i2c port. Serial2 is default port for GPS in MultiWii. The only change you need in conf in this case is #define UBLOX. Then it do autoconfiguration and work like a charm (provide clear sky above, may not get sat signal indoor) Attempts to connect to Serial0 (FTDI) port will fail. Because multiwii use this port for GUI and flashing. So you need to modify code to disable GUI connection on serial0 . Thus you wouldn't be able to tune quad PIDS, and wouldn't be able to reflush it while GPS connected. Not a best solution.

 v_max 454 points

With s2 port and #define UBLOX. NEO6M magically works withiout any reconfiguration via u-Center (autoconfig UBLOX feature added since Multiwii 2.2)

 IBeHoey 393 points

v_max, any reason why you just repeated what has already been said?

 v_max 454 points

just wanna to explain the common mistake - attempt to use s0/ftdi port for GPS

 IBeHoey 393 points

Yes you can, the Megapirates and Multiwii firmware both support it. :D

 jerryatrik 16 points

i am running mine at 115200. Works fine, locks nicely.

 stefano 25 points

115200 in megapirates?

 jerryatrik 16 points

yes, ver 2.8 r3, serial 2 is set at 115200, type is UBLOX

 IBeHoey 393 points

Hello Tommm, the IMAX settings ties in with the "I" settings and dictates the max value that "I" can build up to. lol if that makes any sense. For instance, the value for STABILIZE_IMAX will set the maximum amount the copter can compensate for imbalanced forces. If you're still looking for some more info about this, just google "AC2_Tweaks". The first page you come to will go in to detail about all of the PID settings in Mission Planner. :D

 tommcgarry 12 points

Thank you sir! U got credit for that one

 jerryatrik 16 points

did you calibrate your radio throws in the mission planning software?

 tommcgarry 12 points

Hi jerryatrik, yes i did. There must be a setting or PID that im missing.. It seems like a throttle curve problem, but I havnt even touched the curve..

 IBeHoey 393 points

Another thing to check would be to ensure you have properly calibrated your ESCs. If so, then how well balanced is your frame? If the motors are having to over compensate for a heavy axis, it could hurt overall performance. What kind of setup are you running? (Motors, props, frame, ect.)

 tommcgarry 12 points

I am running a DJI F450 ARF with the OPTO ESCs and 2212 DJI motors. Before this board i had the same setup with the KK2, there were no balance/calibration issues with that setup..

 jerryatrik 16 points

have you solved this one? there is a "throttle rate" setting that defaulted very low. that made my throttle not act right.

 v_max 454 points

Yes, It's really cool. I think this is controller has best price/functinality value on the FC market

 jerryatrik 16 points

that usually happens when the board and the software arent speaking correctly. under tools make sure you have the proper board, port and programmer.

 Crono1124 122 points

with multiwii 2.2 you do not have to cal the acc at every power on. (or any other version that i know of). but i'm not sure what exactly your asking.

 v_max 454 points

Claus, if you use MWI then you power board leave it for a few seconds in calm horizontal state. It do autocalibration on startup. So if you shake you board just after startup you need to recalibrate it later.

 v_max 454 points

First you need to connect it physicaly to serial2. S1-S3 connector RX2-GPSTX, TX2-GPSRX, GND-GND, And take 5V from I2C connector VCC-GPSVCC This is because VCC port on S1-S3 powered only when you power board through external 5V port. Next, you need to connect you UBLOX with FTDI adapter to U-Center (ublox config utility) and upload CN-06v2.0_(NEO-6M_u-blox_6)_APM MPNG_config.txt to change GPS settings... (Just google for this filename) Last... you need to define in APM_Config.h #define GPS_PROTOCOL_UBLOX That's all... if I do not forget something.... Megapirate is a bit wired thingie to newbee... With Multiwii everything is much simpler. You do not need to configure GPS, Megapirate do it automatically on startup (since Multiwii 2.2). So you only need to wire it and set UBLOX protocol in config