Calling All Custom Multi-Copter Pilots!

I plan to do what is called a "pull" to made changes to the custom code regarding custom shaped copters.  

This change in code would only impacts irregular shaped quads, hexas, and octas when the pilot specifically opts to go custom versus the default (the standard X or +).  You have a custom quad if the:

o aspect ratio <> 1 (length is different than width).

o rotors are non symmetric around the

   - forward axis (y) going through the center of gravity (CG)

   - sideways axis (x) going through the CG

   - vertical axis (z) going through the CG

o has a front that is more open for a camera

o deviates from the pictures of a a + or X for the quad, hexa, or octa

o this includes ships described as spider, V, H, U, 88--88, C, etc.

o motor spin direction(s) are different than the pictures

o your CG is pushed somewhere else besides the centroid of the motors.

The advantages of going custom is that the motor factors will be tuned to the coordinate/spin system of your copter versus the coordinate/spin system of the regular copter.  They will fly better.  Pilots will probably not notice small deviations nor would they see significantly improved flight times.  Large deviations might be noticed and provide noticeable changes in flight duration.

Please reply with the motor number (the out-pin number on the APM), coordinates of the motor, and rotation direction of each rotor.  For example,


the owner of this copter would reply (motor number, x, y, CCW/CW):

o 1 (400, 200) CCW 

o 2 (-250, -200) CCW

o 3 (-400, 200), CW

o 4 (250, -200 CW

[note:  no need to tell us your units of measure just so long as you are consistent in measuring; say mm or inches]

Please note:

o The center of gravity of any quad spider or V is not necessarily where the bars cross.  The bars typically cross behind the CG.  .

o The CG is the center of the coordinates or (0,0) where x=0 and y=0

If you decide to participate by replying, the idea is that you will be able to access your custom motor factors without having to compile firmware.  No promises at this point.  First we see what's out there.  But if you do reply, it's far more likely that your design will be implemented in the library.  

If you have any questions or difficulties in doing this, let me know so I can help.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


    • Ok!..., I think that a proper gyro ( velocity) PID can handle asymmetry better than the "final toutch" mixing couplings..., my video proofs it.
      Mechanical symmetry is number 1, PID will do the rest...
    • MR60

      PID will do the rest if your poygon can be described by one or two dimensions with the CG located at the center of the rotors.  If it takes three or more dimension to describe the polygon (e.g., front width, length, rear width) you may have to modify code, which isn't that hard.

    • Can you make a sketch/drawing of your thoughts?

    • MR60

      It doesn't really matter where the FC is as long as the frame is relatively stiff.  Rotation is rotation is rotation.

    • Rotation yes - but you'll get accelerations you wouldn't normally see on a COG placed board. Maybe you'd want some code that anticipates these with all the fancy inertial nav stuff going on in there?

      ... and then an autotune that starts doing full flips to figure them out automagically :D

    • MR60

      the APM has one IMU and the Pixhawk two with x/y/z acceleration chips (and gyros) on the mother board, which are not in the center of the board. Those IMUs are never at CG.  It really doesn't matter that much. However, there may be an argument for having the FCU further away from CG.  Unless I'm not thinking correctly, the farther the IMU is from CG, the better the signal to noise ratio because the accelerations are larger and easier to discern from noise.

    • More to the point: IF the accelerometer is far enough away from the COG that it does show accelerations on rotation above the noise, then you might want to compensate for that. 

    • Developer

      Hi taso,

      We currently only support frame geometries that put the CG on the center of lift. The controllers will deal with offset CG but you may start to get coupling between axis depending on your frame geometry.

    • Could you explain what "coupling between axis" means , a vidéo or drawing to illustrate it ...



    • MR60

      Coupling between roll and yaw is where you apply Roll and:

      - the ship rolls

      - the ship yaws a bit

      or you apply Yaw and:

      - the ship Yaws

      - the ship rolls a bit

      Yaw can also be inefficient when the only solution to eliminating coupling is to use Yaw values that are not equal to 1 or -1.

This reply was deleted.