Problem with reverse pitch for an Arducopter/Pixhawk2.1Cube

Hey everyone. I am having a hell of a time trying to get my reverse pitch that Arducopter/Pixhawk2.1Cube requires. It seems that no combination of joystick/radio calibration on the HereLink, and/or RC2 normal/reverse, gives me the reverse output that Arducopte requires. No matter what I try, I get pitch stick forward- increased pwm. Pitch stick backward- decreased pwm.

Please help!

You posted this in multiple places.

How are you trying to do this?

What firmware are you running?

I am using 3.6.10 for Arducopter. I don’t know how to find the HereLink firmware.

I did the joystick setup in QGC. Then I did the radio calibration in QGC. I connected my pixhawk Cube to mission planner and did a radio calibration for Arducopter. I have tried changing the RC2 reverse and normal. I have tried calibrating the HereLink sticks and radio by holding the pitch stick opposite to the normal. I have tried every combination I can think of and no matter what I do I get pitch stick forward-increased pwm. Pitch stick back- decreased pwm.

Which mode are you in?


Set RC2_REVERSE to 1 in Config/Tuning - Full Parameter List in Mission Planner, or to Reverse in Vehicle Setup - Parameters in QGroundControl.

And reboot your FC afterwards.


Reverse it on the radio instead. I was not able to reverse my throttle. Maybe there is a bug in the reverse function today.

As Hampus said, reverse elevator in the radio transmitter.

FWIW, after arming the motors for the maiden flight, testing aileron and elevator direction is the very first thing I do. If I discover that either of those controls is backwards it is easier and to go into the radio and reverse the appropriate control than it is to connect to Mission Planner/qGC and go parameter hunting…

Looks like herelink does not have channel reverse function.

In addition, arducopter’s RCn_REVERSED function not working…

To this day, I have a pitch reverse problem between the arducopter firmware and herelink.

in QGC on the stick configuration, there is the ability to do this, and the Ardupilot revers feature most definitely works.

what version of ardupilot are you running?

definetly, arduplane have channel reverse functions.
but this functions not working in copter firmware.
it was installed 3.6.11 and 4.0.0 rc2

where is ‘stick configuration’? it it "joystick’?
I cant found it…

I’d dump it and go back to a Taranis.

Making a "high end"radio that does not allow the end user to “customize” its behavior to suit his particular application is bad engineering and very bad business.

Have you posted this on Ardu forum ? I do not see this being faulty on two different firmware.

I can’t check it my self right now but that does not really make sense. You also could reverse the servo output of not the RC. This is all there in Ardu

Herelink has all the functionally anyone would ever need with in Ardu, it’s not perfect and yes is lacks switches and I’d prefer a better gimbal wheel but every product has limitations. Overall it’s got massive amount of options in Ardu and the unit it’s self.

You can reverse the controls in here link very easily. During calibration of sticks if pitch is asking you to hold it at top position hold it at bottom position instead and when it asks for bottom position put it at top position. You have just reversed the switch

Edit make sure you are connected to air unit when calibrating. It seems to recall the calibration from air unit

1 Like

Feel free to go back to the 1980’s… maybe you may want to grab some 27MHz crystals to go with your trip back in time!

The HereLink is designed for connection to a cube, running Ardupilot. A correct setup of a transmitter for ardupilot requires that you leave the transmitter in a completely predictable state, and set up ardupilot correctly. This means that the default setup on a HereLink will work with a correctly set up vehicle.

Designing for simplicity is the goal, and it’s what helps to remove human error from aircraft setups.

But what would I know, can you send me a link to the solution that you brought to market?

1 Like

I really don’t want to get into a flame war over this but facts are facts.

First off, several other manufactures have “dumbed down” there equipment and it has done nothing but create a gaggle of empty headed thrill seekers who get their jollies from buzzing airports and wild fires.

Second, from a business perspective and excluding toys, designing something that anyone with a pulse can fly is just plain stupid.

Third, commercial aircraft are complex machines and the learning curve to get one airborne is steep for a reason.

Fourth, designers and engineers never listen to end users until the support calls and item recalls begin to happen.

From what I have gathered from this particular thread, there is a flaw in the design of your radio transmitter in that stick movement vs control signal direction cannot be changed by the end user. This design flaw has a direct and possibly catastrophic impact on aircraft and pilot safety. This flaw also has an impact on the safety of public property, private property, as well as the safety of the general population at large. The fact that you are unwilling or maybe even unable to correct this obvious flaw is telling indeed.

As for a providing a link to a solution that I have brought to market, I don’t need to provide one because there are literally millions of RC transmitters on the planet that do not suffer from this same design flaw that was the result of real world disconnect and short sightedness that you have eloquently displayed today.

There fore my initial recommendation still stands. Using a Taranis or any other RC transmitter that is on the market today will allow the original poster to resolve this control issue.

Sorry but this is a load of nonsense.

The stick can be revered by calibrating backwards or changing the affect/output in Ardu and PX4.

This is simply a non issue as it’s capability is there to program in software what ever you want.

Having this option in the RC or the Flight Stack makes zero real world difference and actually keeping RC programming options at a minimum and having all main config in the flight stack makes far more sense from production industrial use point of view.

1 Like

I’ve reversed pitch in AC 3.6.7, 8, 9, 10 and 11, and all the 3.7-dev and 4.0-masters I’ve tried in the last 8 or so months, and it worked everytime. I’ve never calibrated the TX backwards.

The only thing that baffles me is why a product built for AC/AP doesn’t have the reversed pitch as a default, leaving people that use it for other projects to struggle with the issue… :smiley:

Ok, so let me get this straight… The radio doesn’t have the ability to reverse any channel outputs to keep things simple and reduce the probability of a human making an error, but on the other hand if there is an issue with control direction you advise that same error prone human to go into the flight stack and reverse channel behavior.

Talk about a load of nonsense…