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]
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.
a lot of flyers like the H. the reason most of us like the X is for the same reasons we'd pick a triangle over a square ... it's much stronger and lighter. but there is a lot to be said about the beauty of a square or H. but a square or H have a lot of strength issues that are not apparent to even engineers--axial twist.
the X has the same benefits of the com at prop level. it's just about design and placement of the electronics platform.
on the other hand, my brother will choose sex appeal over weight efficiency every time. so go with your personal preference. it has to be fun.
the spider or slanted X has the same benefits of the X's strength with only a small weight penalty for opening up the front for a center gimbal mounted camera. in fact, the camera Field of View (FOV) of an X will be greater than that of a H because of the structure required to spread the H gets in the way of the FOV.
for some, the H is cool and simple to build. and for others, like QAV owners, they are somewhat forced into it.
yes and no.
H, I and square are typically the same. All suffer from issues with torsional twist (sort of the difference between a triangle and square).
Are they the same as the X if shear structures are added to the H, I, and square so they solve the axial twist issue? Yes in regard to turning sharp corners and not having the camera view wobble as the frame tries to twist and flex. But no in regard to the ship weighing about 40 grams more and not flying as long (between a few seconds of less flight time on typical quads to about 4 minutes on well engineered long-duration copters).
So if you are only trying to stay in the air for 15 minutes, an H, I or square is fine.
Forrest, I have little time for the moment,so it can take some time before i have the V octo up and fly...
Do you have the compiling manual ready? It could be nice too see how to do it :).
But I do not want it being trouble for you, if it is a lot of work to complete the manual...
It's done and turned into 3DR.
This has been on our list of things to do for a long time now. It is just a matter of getting it to the top of the list. Unfortunately there is only so much time in the day.
Reading through the post and thereafter the comments, I see that there might be something that's missed and is related to the CG of the frame.
For example I have a 500 spider quad which is loaded and unloaded with stuff frequently, i.e. gimbal for scenic stuff, no gimbal for fpv... With this in mind and that my FC positioning is probably much irregular, how would the FC handle the irregularity of the frame and a tail heavy frame with a CG that is not center in relation to the FC (tailheavy and FC almost at front)?
I understand that this is still a call for sources sought maybe, but still the question pops if we provide motor positioning for library or such purposes :) Shouldn't the motor positioning be relative to the FC for example and not CG and allow in the code for such integration?
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.
Hi, late reply...
I am still surprised on how difficult it is in APM to tune the Rate-PID's. I am used to do it with KK, Mwii, CleanFlight, and my own gyro-only KK-based PID code.
I am missing the HeadinHold feature (ie the I accumulator) Any suggestions on how to achieve this in APM? I am talking Acro mode, not Stabilize.
This is an old, old, video of a gyro only quad with a "simple" PID loop. So, having a not so square H quad, will not be a problem if PID's are rock solid and at least get the HeadingHold ...
And again, i am amazed how the other flight boards / firmwares does define custom frames / motor mixes so easily ...
you can count your lucky stars with the APM/Pixhawk
I looked at the link you provided for MultiWee. the factors for the V and U in the link are not explained correct for yaw and thus the math is not correct.
- there will be coupling between yaw and roll if the values described are used.
- the yaw values are not optimal (yaw force does not change with distance)
In addition, the motor mixes are done the same way in the Pixhawk or APM (with the exception that the math is correct). So maybe i'm not understanding the question or issue.
I know, APM does wonderful things, all i want to say that "simple" is not a word for APM/Pixhawk ?...,
Basic gyro-only-error-PID loop, and a big error accumulator will do wonders.
If someone can tell me how to get "heading-hold" done in APM?
like this other example:
Sorry for my confusing questions.
First the basics then the details.
PS:are you sure "yaw force does not change with distance" !? Physics are not always intuitive...
Hi Forrest. Great idea. Sorry this is a bit late...!
Here are my offsets for a 550 nominal asymmetric frame:
1 (248, 165) CCW
2 (-198,-165) CCW
3 (-248, 165) CW
4 (198,-165) CW
Thanks for the effort.