# Inverting Axis

Hello, I am trying to find a way for when our driver starts reversing with our mecanum drive robot, the rotation axis gets inverted.

Show us what you have first so we can suggest different approaches on how you can accomplish it.

I’d suggest multiplying the axis you want to invert by -1. Example code:

``````
if (reversing) { //Put whatever code you use to detect if you're reversing here
myMotor.set(joystick.getYAxis() * -1); //Set a motor to the inverse of the Y axis.
}
``````

You can also just place a - in front of it.

``````
if (reversing) { //Put whatever code you use to detect if you're reversing here
myMotor.set(-joystick.getYAxis()); //Set a motor to the inverse of the Y axis.
}
``````

Is this just a matter of aesthetics, or does it actually generate more efficient code?

I’m not sure about Java, but I do know that with traditional compilers, it is more efficient - changing the sign on a number is a much simpler operation, usually done in a single clock cycle. Unless the compiler is doing serious optimization, multiplying by -1 is a full floating-point multiply.

Why would you consider that to be a serious – rather than a simple and obvious – optimization?

That is a question I do not know the answer to. I’m assuming that it is just aesthetic. You are technically using the unary minus operator in both situations because the - in front of the 1 is technically inverting the value of 1.

It is however better practice to place the - in front of the variable instead of multiplying by -1.

I share your opinion on this matter1, but to move out of the realm of individual opinion: Is there a widely accepted code formatting standard that states this explicitly?

1for aesthetic reasons and to discourage the compiler from generating a floating-point multiply
*
*

It is known.

I do not know of any source that explicitly states it, and I haven’t found one in a quick Google search. It’s just the way I learned and it is the way I do it at work.

It’s simple and obvious to a human, of course. If things were obvious to computers, programming them would be much easier.

OBTW, you pass the Turing test.

You are claiming that particular optimization isn’t obvious to a compiler. In fact, you implied it would be difficult (serious optimization). Please explain your reasoning for that.

I did a bit of Googling, and it does seem that several optimizers will generate the same code for both cases. Optimizers appear to have come a ways since I last paid close attention.

It still makes sense to me to ask for -x (or 0-x) rather than -1 * x. Provided that the code is equally (or arguably better) readable by people, why not give the computer the simplest directions?

Nobody is arguing otherwise.

…why not give the computer the simplest directions?

Because “simple” is subjective and a matter of personal preference.

That’s why I asked if this (very reasonable, in my opinion) use of the unary operator in this case might be part of a widely-accepted Java coding standard that could be referenced in support of the recommendation.

For an example where the simpler code is not easier to read:

Logically, you want to do a conditional:

if (c is between a and b, and you don’t know whether a is larger or smaller than b) then…

Human simpler (use this!):

if ((a<b) && (b<c) || (a>b) && (b>c)) then…

Probably machine quicker, but don’t use:

if ((a-b)*(b-c) > 0) then…

I guess neither is simpler.

I swapped b and c between the two. Let’s correct the prose. I meant to say that b was between a and c, and you didn’t know whether a or c were larger.

`````` double strafe = mainStick.getRawAxis(3);
double forward = mainStick.getRawAxis(1);
double rotation = mainStick.getRawAxis(2);

//mecanum algotrithms
double mFL = strafe + forward + rotation;
double mFR = strafe + forward - rotation;
double mRL = strafe - forward + rotation;
double mRR = strafe - forward - rotation;

FL.set(mFL);
FR.set(mFR);
RL.set(mRL);
RR.set(mRR);

``````

This is my code for regular driving for mecanum but I feel that if I inverted the motot not everything else would be the same.

The correct inverse kinematics for mecanum is:

``````*

*double mFL = forward - strafeRight  - rotateClockwise;
double mFR = forward + strafeRight  + rotateClockwise;
double mRL = forward - strafeRight  + rotateClockwise;
double mRR = forward + strafeRight  - rotateClockwise;
``````

If the above doesn’t work, it’s better to do the necessary motor inverting/swapping to make it work, rather than changing the signs of the kinematics.