Offset X frame configs. Just changing angles, or manually setting roll/pitch factors? Digging through code, need help!

OK, in summary I have a TBS discovery and I want to do a better job of setting up its odd angle arms to work with the APM.  I feel like understand this would also be great for testing and adding new platforms like a spider Octa, hexa V, etc.

I've made pictures because I feel they can better convey information.  Basically, I've found the angles on my non-pure X frame (not 45* spacing) from the horizontal and vertical lines.  I tried do a simple edit of these values (see picture 3), but it didn't see very stable over the normal X with the same PID settings.

I also looked at how the Octa V is setup, and I'm thinking that is the best way to tackle this problem, but I don't quite understand how I might map these values out for this setup.  Who wrote the V code?  Could they share any insight?

Here is the normal X frame, and the rough Roll/Pitch factor that gets applied after the add_motor function by my calculations. 

I then looked at the Octa V and saw how it skipped the add motor function and just wrote raw roll/pitch factors.  I mapped them here to try to better understand how their placement would change my offset X.


So can I get away with my angle changes running add_motors, or do I need to find out what the real roll/pitch factors for this offset should be?


Edit: Updated pictures.

Views: 6274

Reply to This

Replies to This Discussion

I just did more flying on the correct angle offset config, and it does not fly well.  The pure X setup feels much better than the correct angle setup, and I believe this is because the "pure" setups are made to be symmetrical in nature.

I did some more testing yesterday;  putting the add_motor_raw function works just fine.  I started out just emulating the X quad setup to get a baseline, and this worked as well.   I will flight test the configuration in the last picture today.  It felt like it had more forward pitch correction which is what I wanted.

I still am looking for any information on how one might find these raw values so we can write code for Octa spiders, Hexa V's, or other crazy designs.  Anyone? 

How do you mean it flew badly ? Did it respond to roll/pitch correctly ?

Also, where did you get the raw values ? Here's what I'm getting for these angles (67.5 -120 -67.5 120)

#1 -0.9   0.4

#2  0.9  -0.5

#3  0.9   0.4

#4  -0.9 -0.5

rounded up at one decimal

but if you measured correctly then the correct in-code angles for 2 & 4 should be more like 127.5 , -127.5

Sorry for the lack of clarification, I didn't find the raw values for the different angle setup, and thank you for correcting the math errors there.  As for flying, it didn't feel right, everything felt off balance.   Because of this code, I still don't believe setting the proper angles for an offset frame is going to work.  See the +90 for adding the pitch factor in the add_motor function, which makes me think the code expects the next motor to be 90 degrees from the first.


//void AP_MotorsMatrix::add_motor call raw motor set-up method

cos(radians(angle_degrees + 90)), // roll factor
cos(radians(angle_degrees)), // pitch factor

The raw values of .5 /. 7  .7  / .7 are just made up values I'm currently testing.  I believe if we can understand how the values of the Octa V was done, we can find the formula for any setup.  

Also, the .5 / .7 raw just flew well.  Forward and back pitch felt good.  Left to Right Roll is coming a little too the back.  I'll keep testing.

90 is added to angle_degrees to represent roll/pitch phase difference: If a motor is at 0degs it should have zero roll factor (indeed cos (pi/2)=0) and a unity pitch factor ( cos (0)=1. Has nothing to do with incrementing next motor etc

I don't see how V raw values could be of any help. Here the add_motor function is useless since some motors have roll and pitch factor of 1 and there's no angle giving cos(x)=cos(x+90)=1 :D

I think as long as all the motors are in a circle there should be no need to use add_motors_raw.


I follow on the roll factor.   However the raw values call the add_motor_raw function.  The angle based mapping call the add_motor when then takes those angles and calls add_motor_raw.

Look at AP_motorsMatrix.cpp

Finally got some arms, here's what I'm getting for angles on the TBS discovery:

I'll be trying out 62/-133/-62/133 see how it goes, not until some more parts are in though

Hi Josh,

check this out, ardupirates motor mixing.

I wrote this when I made the V mixing for the arducopter/ardupirates, hope it helps.


Let me know how that works out.  What are you running for motors/props/cells?  Right now I've got the stock DJI motors with 10" x 5" graupner props, and it's under powered on 3 cells.  I don't have any big 4 cells, so I'll probably balance my 10" x 4.7" stock DJI's since they create more lift.


Thank you!  Just glancing at it I see there is a useful method of finding the correct values. Good stuff.

I think I better understand things now; the add_motor function is based on all motors being the same distance from the center, which is the case with the discovery.  

My current understanding of odd frames like a V/etc is that you need to find the angles and distances for each motor, then find your pitch and roll based on that, but again, not an issue for the the discovery.    I'm going to switch to your calculations and go for a flight tomorrow.

I'm going to buy some small cheap motors and play around with some odd configs and hopefully put together a calculator.

Motor mixing is just a matter of knowing how much "strength" must a motor apply on pitch and roll depending on it's position, no need to mess up with angles, only distnaces from center in percentages.... hope you get the idea.

Once you're clear with that, you can mix for any kind of shape you can think of.


Reply to Discussion


© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service