Edits in MultirotorMixer.cpp not reflecting in drone behaviour

1

I’m using quad x.
I have been trying to edit the lines:
outputs[i] = roll * _rotors[i].roll_scale +
pitch * _rotors[i].pitch_scale +
thrust * _rotors[i].thrust_scale;

File : MultirotorMixer.cpp
Function : MultirotorMixer::mix_airmode_disabled(float roll, float pitch, float yaw, float thrust, float *outputs)

But there seems to be no effect on the drone behaviour even after a successful compilation(make px4_fmu-v3_default) and upload(make px4_fmu-v3_default upload) thru the console.bat. The same commands show proper effect when used to edit quad_x.main.mix

2

Hi Shady welcome to the community! Glad you are here!
Just wondering what effect where you expecting?

3

I want to remove the responsibility of roll completely from front motors(1 and 3) to ONLY to the rear motors(2 and 4). I don’t want to make a new custom airframe.
If im just able to see the code changes reflect in the behaviour of the quad, that’s enough for me to carry on.
I’m aware that this change will destablize the quad, but i will mount the motors physically different, not as represented by the geometry.
All I need is the code changes in MultirotorMixer.cpp to reflect in the behaviour.

4

& thanks in advance for responding

5

Just to prove that any edits are not working I did a small experiment:
Even though i comment out the code for Airmode=Disabled(default). The Quad still seems to respond as before:
case Airmode::disabled:
default: // just in case: default to disabled
//mix_airmode_disabled(roll, pitch, yaw, thrust, outputs);
break;

It still responds to the rc inputs. According to me it should not respond to any yaw or roll desired on the radio sticks.
Is it because this code is running on PX4IO controller and the command (make px4_fmu-v3_default upload) only burns the code on FMU ?

6

I see so basically your looking to crash your drone :-).
I think you should put a write to the log in your code to make sure is there and running.

7

What flight mode are you using to test? It could be that a higher-level control loop is compensating for your changes. Does acro mode produce the expected behavior?

You could also take a look at

or maybe better edit


without using the 4x formula.
8

Will try putting the logs. But just to understand, wanted to know for sure where the mixer code runs? And if it’s the io processor then is the Mixer code getting burnt there everytime i make change in mixer equation.

9

I have tried it in manual and pos control mode. Not yet with acro.
I had already tried modifying .toml as follows:

Generic Quadcopter in X configuration

[info]
key = “4x”
description = “Generic Quadcopter in X configuration”

[rotor_default]
direction = “CW”
axis = [0.0, 0.0, -1.0]
Ct = 1.0
Cm = 0.05

[[rotors]]
name = “front_right”
position = [0.707107, 0, 0.0]
direction = “CCW”

[[rotors]]
name = “rear_left”
position = [-0.707107, -0.707107, 0.0]
direction = “CCW”
Cm = 0.0

[[rotors]]
name = “front_left”
position = [0.707107, 0, 0.0]

[[rotors]]
name = “rear_right”
position = [-0.707107, 0.707107, 0.0]
Cm = 0.0

10

I had experimented with quad_x.main.mix as well
But i guess i can only do 2 things there

  1. Change rpy Scaling values and
  2. Tinker with aux input( not useful in my case)

My lookout is that i should separate the yaw and roll logic
Front two motors are only responsible for yaw
And
Rear two motors are only responsible for roll

And dont worry, the quad wont topple, it will be resting on a frictionless surface

11

Tried it in acro mode. Produces the same result.
Does that mean it’s not a loop compensation problem?
Does it mean that any edits are simply not reflecting in behaviour?
If yes, what will be the solution?