Multiwii and Megapirate AIO Flight Controller w/FTDI (ATmega 2560) V2.0
This board features a multiple serial interface as well as a dedicated I2C interface. You can now plug in a GPS directly, and you still have extra ports for other external devices. In addition to that, the new ATmega 2560 has more IO pins so it can both read the PWM signal from your receiver and it has enough PWM outputs to control the ESCs directly without the need to do the PWM signal in software.
This controller even has a MicroUSB port right on the board, no need to attach an extra FTDI USB interface.
The motion sensing side features a new generation MEMS Gyro, a MPU6050 by InvenSense, which has the MEMS Gyro / Accelerometer sensor on a single chip. There’s also a 3-axis magnetometer and a barometer sensor with a resolution of 0.01 millibar – approximately a 10 cm height difference.
Interested in GPS functionality? Well this is one of the most cost effective ways to get started - simply add a 10Hz GPS module (coming soon) and you’re good to go!
Features: • Supported MegaPirateNG and MultiWii firmware • Up to 8-axis motor output • 8 input channels for standard receiver • 4 serial ports for debug/Bluetooth Module/OSD/GPS/telemetry • 2 servos output for PITCH and ROLL gimbal system • 1 servo output to trigger a camera button • 6 Analog output for extend device • A I2C port for extend sensor or device • Separate 3.3V and 5V LDO voltage regulator • ATMega 2560 Microcontroller • MPU6050 6 axis gyro/accel with Motion Processing Unit • HMC5883L 3-axis digital magnetometer • MS5611-01BA01 highprecision altimeter • FT232RQ USB-UART chip and Micro USB receptacle • On board logic level converter
Flight mode for Multiwii: • One of the following basic modes – Acro – Level – Alt Hold - Heading Lock
• Optional mode – HeadFree (CareFree) – GPS Hold (Need GPS receiver) – GPS Back to home position (Need GPS receiver)
Flight mode for MegaPirate: • Acro • Alt Hold • Loiter (uses GPS) • Guided (uses GPS) • Position (uses GPS) • Circle (uses GPS) • RTL (uses GPS) • Auto(uses GPS) • Follow Me(uses GPS)
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?
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.
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.
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
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.
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
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
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
I'm setting up this board and configuring the firmware so it can run megapirateng. I have compiled and uploaded to board and it connects to mission planner and gps works. The problem is that all of my tx controls work except elevator. I have ruled out the TX and ruled out the RX this leaves only this board. I'm wondering if the board is defective or if there is a setting I missed. I did notice that depending on which tutorial you read in the files section they say to select either the Crius AIOP v1 or the FREEIMU ... not sure which it should be now. Tried both though and neither worked. Any help or suggestions would be greatly appreciated.
Thanks in advance.
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?
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.
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.
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.
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
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.
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.
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.
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.
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
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.
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.
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.
Hello, someone know if I can put this 3 componentes toguether????
Multiwii and Megapirate AIO Flight Controller w/FTDI (ATmega 2560) V2.0
Multiwii MWC FC Bluetooth Module Programmer (Android compatible)
NEO-6M GPS Module
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
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?
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.
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.
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
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.
...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.
...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.
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.
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.
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?
if i connect this to a TURNIGY Plush 25amp Speed Controller and Turnigy 2200mAh 3S 20C Lipo Pack and 8045 SF Props 2pc Standard Rotation/2 pc RH Rotation (Orange) and Turnigy D3530/14 1100KV Brushless Outrunner Motor do you think this would be a good setup, do i need anything else?
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.
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.
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???
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.
Farzin, you are NOT right
pins assignment is a few rows in def.h
#define THROTTLEPIN 3
#define ROLLPIN 6
#define PITCHPIN 2
#define YAWPIN 4
#define AUX1PIN 5
#define ROLLPIN 4
#define PITCHPIN 5
#define YAWPIN 2
#define AUX1PIN 6
So, that's relatively easy to swap Throttle with Aux
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.
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.
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
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
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 :)
help... i think i may have fried my board. i was trying to get it going, i had one motor running, but when i put all 4 at once the microchip got really hot to touch and no motor response. i can see all control inputs from tx on the multiwii screen on my computer EXCEPT for throttle... any suggestions??? will reset maybe help??
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.
I just ordered this board along with NEO-6M GPS Module and Multiwii FC I2C-GPS NAV Module. I feel I may have jumped the gun, as I don't fully understand what these things are for. In the item description, the Neo Module requires a USB to FTDI adapter board. Is this the purpose of the Multiwii FC I2C-GPS NAV Module, or do I need to order this adapter board from somewhere? Thanks for the help in advance.
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
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!
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
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!
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.
Hi every one My name is Sean, i am attempting to build my first Quadcopter. i have just bought this flight controller, it is in the post now.
I am looking for some instructions for it so i can start getting my head around the operation of it before it arrives . Also if any one has some helpful tips to get me started it would be most appreciated.
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)
Alright guys, it's my turn to ask for some help. I'm running Multiwii v2.2 and I'm experiencing jitter in the yaw servo. I had previously been using HXT-900 servos on another frame with no issues, aside from the occasional stripping of the gears. I decided to go ahead and order a metal geared TGY-9018MG servo from here. While waiting for it to arrive, I went ahead and built a new frame for it. Since the frames were similar in size, I just loaded up the same PID settings that I used before. Right off the bat, even before arming the motors, the servo would start shaking really bad, almost as it were oscillating. I dialed down the yaw PID vales from 7, 0.10, 10 to 3.5, 0.10, 0. This seemed to help as it would no longer shake uncontrollably before even arming, and I'm now left with the jitter that you see in the video. (Trying to record video and fly at the same time was quite a challenge.) I've tried powering everything with, and with out a UBEC, but it had no effect. I'm officially stuck.
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!!
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.
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)
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:
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.
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.
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).
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.
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
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!!?
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
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.
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.
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 - 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?
...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.
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
I'm having trouble with getting my computer to talk to the controller. The serial port selection is greyed out in the menu and I'm unclear as to how to get the two talking. Any tips would be greatly appreciated.
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
Hello! Setting up my first quad. I have connected everything and got no response from the motors. Then I connected the quad to the PC and MultiWii GUI. I get response from every channel except throttle. The throttle stick is working correctly with the Rx(I have checked). But the board is not getting any signals for THR. Hoping so much that some of you have the answer, I want this thing working properly :)
Specs except FC: Turnigy multistar 30A ESC, NTM motors, Turnigy SBEC, Turnigy 9X Tx and 9X8C V2 Rx.
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*)
Hello everyone, I can not load the configuration hexa tab because the Arduino software gives me this error avrdude: stk500v2_ReceiveMessage (): timeout avrdude: ... Please help me! The driver are correctly configurated and my Mac see the data from the board when launch the multiwii software but i need the hexacopter configuration.
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
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"
**** 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?
I reproduced the error when I set wrong 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
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
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
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...
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, 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.
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
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?
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
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.
hi at all.. simple question, i have change the baudrate on gps (ublox)at 115200 for fly whit this board and multiwii, now want to try the megapirates, I have to change the baud rate back to the gps? if so, what baud rate? thanks!!
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
Hi everyone, I am running this board with Megapirate and Mission Planner. I have PIDs pretty much set, but i have hardly any throttle. It starts to hover at around 45% then theres hardly anything after that. If i go full throttle it will climb, but verrrry slowly.. I played with 'Throttle Accel' in PID, but no help. What am i missing?
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.)
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.
I'm an absolute newbe in the multicopter busyness. I though this board would be a really nice starter for my first quad build. I tried out this board and like it a lot. I'm currently using it with megapirateng 2.8r3. I have bought the neo6m gps but haven't got a clue how to connect it up to the AIOP V2. Neither do I know how to configure megapirate for it. Any help would be welcome!
First you need to connect it physicaly to serial2.
S1-S3 connector RX2-GPSTX, TX2-GPSRX, GND-GND,
And take 5V from I2C connector
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
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
bought my third controller and i hope that i do not have to solder the vreg on this one a big plus for this board are the sensors they all work flawles i fly with 2 of the faulty????? boards that i have soldered the vreg and for sure i can say it is worth the money
yes its not a crius but works the same for half the money
AND PLEASE HK DO NOT I REPEAT DO NOT ERASE THE REVIEW AGAIN
because that PISSIS the buyers off
No comments. Reply..
Ahh, I can finally write a review on this product. I'm an original owner of the first version of this board, the one with a faulty GND trace. Upon receiving the board, I highly recommend you go over it with a fine comb. Aside from the known fault on the original board, I also had a lifted pin on the 2560 (A11) which resulted in intermittent yaw control. We're talking really really small pins here, unless you have expert-advanced soldering skills, and even if you do, it's probably best to just request a RMA and send it back. Now that's out of the way, on to the review. If you're new to the multirotor scene, this board is not for you. There's a lot going on with this board and to use it safely, you'll need to have a sound understanding of working/tweaking with firmware, how all the elements work and connect together, and the ability to troubleshoot/fly a buggy multirotor. If you've worked with Multiwii in the past and are looking to move on to something a little more advanced without busting your wallet, then this might be the board for you.
It's ability to handle different flavors of firmware is what drew me to this board. As per the description, it can handle Multiwii, MegaPirateNG, and although it's not mentioned, I have been running ArducopterNG on it as well. It's worth noting that the MegaPirateNG and ArducopterNG are both ports of the Arducopter2 firmware. Bec
No comments. Reply..
Opened up my FC today and wasnt really happy. I got someones returned board. HK didnt even take the time to remove all the the previous persons double sided tape from the back of the board. After reading all these reviews I am wondering if it is worth my time to figure out which version I have and dive in. Man those KK2 boards are making this thing look like a nightmare! All these features better be worth the time investment.
No comments. Reply..
Top, no problems with it. I use it with Multiwii Software. Altitude hold, Level mode, mag, bluetooth, gps hold and return to home, all works fine with high precision. Nice Board... Altitude sensor must be covered with foam... Gps is a Locosys from a Tiny OSD 2 with serial interface, 10Hz and 112500 data transfer rate... You can use one gps modul for Flightcontroller and Osd (it needs only TX from Gps Modul)