I need help please. I have made a couple of custom hexacopters. My favorite frame shape is the U-shaped Hexacopter. Unfortunatley I am not arduino gifted. Fortunately I do have the DJI wookong. They have a nice custom motor mixing table which makes any custom frame design easy to program, all you need to do is to write in the motor percentages.
So my question is how can I change the motor power percentages in Arduino code to do this?

Views: 3786

Reply to This

Replies to This Discussion

Look in the AP_Motors library. Should give you a starting place as you'll need to extend it for your frame type.

Thanks. I will give it a try this weekend.

did you ever figure out how to change the motor mixing for pitch, roll, and yaw?

i'm in the final setup of a custom octa-H and need to figure this out also.

Maybe this for writing code but I am a hunt and punch typest so I don;t write code. I did notice that on the Mission Planner, when I was flying a "Y" 6, there was an option to change the motor percentage for the top or bottom motor. I am going to set up a "U" 6 hexa and just match up my motor positions to the "Y" 6 and adjust the percentage of each motor according to it's function.


Good luck,


The cure for an uneven hexa that may not be perfect but works. In the new Mission planner 1.2.44 yo can set up a hexacopter then choose the "V" frame instead of "X" or "T". It is not perfect but it works. I would rather see the motor pecentages to get a more precise motor adjustment but for now my Hexa "U" flies and is stable.

Good luck

Glad that the hexa V sort of works.  If it doesn't work well enough, I can send you to the forum where a complete solution resides.

I've been trying to lobby for direct access via MP to the pitch, roll, and yaw factors table, which would allow the control we custom copter builders need.  If you get the chance please voice the need.  The more we get, the better.

A side discussion - U versus H:  Both U and H designs meet the needs of photography.  So since you like to build custom stuff, here were my thoughts after a few months of tossing design options back and forth.

The advantage of a U over H (when both have an aspect ratio of 1) are: a slightly smaller footprint (the aft end motors tuck in a little closer and thus the width & length can be a bit less)

The advantage of a H over U are:

o symmetric opposites and fore/aft so the X becomes a close proxy (tested)

o ease of vibration isolation (2 motor boom versus in the U case of 6 arms)

o four parts and one deck versus the U six arms and two decks

o cross beams carry torsional loads so electronics platform (decks) can be lighter 

o six arms in the U case versus two cross beams in the H case are continuous versus cut in the middle

o fewer parts to assemble and fewer attachments (24 for the U and 9 for the H) if made portable

o a slightly less frame and fewer bolts for less fixed load

o photo views out both ends (you can always yaw the U but yawing the gimbal may be more stable)

So if you get the creative juices and decide to build an H someday, let me know and I'll send you the excel worksheets and photos to help get you there, not that a guy like you needs any help but your input into the H design would be helpful.

While direct access via MP to the pitch, roll, and yaw factors table would be nice, it is not currently possible.  Currently, the motor mount tables are hard coded in the source code.  The motor mount tables would have to be re-written to accept either variables or read the settings from eeprom memory space.  Then, the MP can set the said variables or eeprom memory space.  So, the issue isn't an MP issue, but one of the source code not being configured for that type of access, and we now have to manually change the tables and recompile the firmware.


Wow.  That would be great if that ever happened, but until it does ... I've read that with an Octa H, I can say I have an Octa V and that redirects the code to the add_motor_raw lines of code under Octa V.  So I need to modify the parameters in those 8 lines of code.  Before I do that, however, I have some questions (mostly procedures, not math) to which I've scoured this forum and the pirate forum to no avail.  Might you be a patient person I can ask and get answers?  I'm making an excel file for forum users to simplify the correct calculations for every type of configuration diydrones supports and would like to share that, but want to add explicit instructions which I don't have. Can you help me or know someone who would that is familiar with the Octa V nuances?

I can assist with the procedures needed to manually modify the source code.  I've built a TBS Discovery type frame, and have hacked in my numbers to the AP_MotorsQuad.cpp library file.  So far, so good ...

I've seen your spreadsheet, but haven't had the time to study it.  Yes, there is a lack of concise information on how and what to do.  There is a lot of conflicting information on how to arrive at the needed numbers, and also a lot of incomplete information.

Anyway, I'll help as I can.


Super.  I'll do one question at a time spread out over time to not overload you.  I'll incorporate your answers into the Excel document to explain the process.

Question 1 concerns configuration control of the compiled code.  For a standard system, how is configuration controlled maintained for each copter.  For example, the answer might be something like the following (please edit or start from scratch).

- MP does not detect the latest version of flight software.  The user completely controls updates of flight software and should stay informed via periodic checks at xxx.  If MP informs the user of an update, it is talking about an update to MP. [Conversely this might say ... MP auto detects for the latest version of flight software.  It informs the user with a pop-up that says "An update of flight software is available."  If it says "An update is available", this is referring to MP not flight software.]

- When you want to load the latest flight software, the common method is to run MP, go to the Firmware page (do not connect to your vehicle) and click on the picture of your vehicle. Mission Planner will auto-detect what kind of board you have, download the latest compiled code from the Internet, and then load the code to your APM board.  (Note: MP also allows the compiling of previous or custom flight software).  The compiled flight software code resides on your vehicle but not on your computer.

- It is not necessary to erase the firmware from the copter first nor is it necessary to erase the copter settings first that are transmitted when you connect to your copter.

- The code uploaded does not impact any of the previous settings found in the Configuration page of MP as long as the configuration chosen is the same as the previous configuration chosen. [Or conversely, after an update of the flight software, go to xxx to see which parameters can change.]

Anyway ... something like that. This will set the stage for the differences between normal and custom configuration control. Please point to a location if this is all ready explained.

Thanks Rick.  I don't know how many custom folks there are out there, but once this is done, that percentage might increase.

I think we are getting off the topic of this thread, and your questions would be better handled offline.  Send me a PM, and I'll send you back my email address.


contact me at forrestfrantz@gmail.com for the offline discussion

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service