Hello, I've got a problem with APM and Raptor 50 heli

I trying to set up APM on Raptor 50 with Glow engine. I connect my JR RC control to APM next variant:

 RC                             APM

 rx                           in      out 

1 trotle(pitch) ---->     3        3      

2  ailer          ---->     1        1

3 elevator      ---->     2        2

4 rudder        ---->     4        4

my transmitter sets up in "airoplane mode"

 The essence of the problem: I don't understand how set up the swash plate. On helicopter installed 90 degrees swash plate  I tried different variants of degrees setup. For example:

servo1  90      (aileron??)

servo2  0       (elevator??)

servo3  180    (pitch??) 

ailerons works normal, but elevator and pitch mix some strange.  

 please help me....

p.s. Sorry for bad English

Views: 3921

Reply to This

Replies to This Discussion

Yeah, I've been looking at the code for a while and have a general understanding of it.

I'd be prepared to put out an attempt at a fix today, but I have to answer that question about scaling.  I know how the numbers come into the function.  Pitch_out and Roll-out are -4500 to 4500.  Coll_out is 0-1000.  Coll_out_scaled is say, 200-800, depending on where you set your limits of swash travel.  But I just need to be sure what the numbers have to look like before they go out to the servos.  Is it 0-1000, -4500 to 4500, or 1000-2000?

Much of this is done in RC_Channel library, but that file is really hard to understand and not commented well so it's difficult to figure out.

I would imagine that scaling needs to be done to line those values up with the min-max ranges for the servos. Heli.pde has got to be doing that already. We just have to figure out where.

Also, where are the pitch and roll angles for the blades set for maneuvering? If theyre set on the radio like a traditional RC, there should be no issue, but if Ardupilot keeps those values, we'll have to make sure we're incorporating those.

Im not the best at coding from scratch, but I do pretty well with analyzing code, especially alongside someone like yourself who has some basic understanding. I'll go through based on our chat and see if I can't find out where everything's hiding. I have Visual Studio with the Arduino plugin now, so maybe I'll have an easy enough time figuring it out with all of VS's sexy tools.

Thanks for your answers, i'm very busy in university but i  1 or 2 weeks and i will solve the problem in heli.pde   

I will give it a go today, Robert has a good plan, I was waiting for 2.4 release before starting, it has the best chance of working well.  

Sweet! I look forward to seeing the results.

Here's what Randy said about the issue in another thread.


"It's not terribly difficult to get a non-mixed input working but it's lower down on the to-do list so it won't be done for a while.

In case someone else wants to have a try at it - there are separate routines in the Heli.pde for both turning the ccpm inputs from the RX into separate roll, pitch, yaw and collective commands and the opposite of turning these commands back into ccpm outputs to the servos.  The catch is that then we would need to have a new set-up routine to capture min + max servo values, servo direction, etc.  At the moment, the set-up only works for CCPM."


Sounds like the routines for setting up the servos is designed around CCPM. The unmixed swashplate setup will apparently need entirely new setup routines.


This is getting a little over my head. I don't have ArduPilot hardware yet myself. I just recently ordered my first setup, and I'll be waiting for it for a while because it's a new APM 2.0 preorder (should ship this next week I think, judging by the order numbers they're posting on their status updates). I've just been doing all my flying in HiL mode to get a feel for how the software is supposed to work, using a barebones Arduino Mega 2560 as the platform until I get the real hardware.


Once I get my own hardware and get to play with the real thing, I'll have more insight into how the software's put together, and hopefully I'll be more help.

@Chris, All,

     That comment was from the old ccpm set-up which was much more complicated and actually required you to send in mixed signals from the TX.  I.e. the TX had to be set-up in helicopter mode.  That's been changed now so the TX sends regular unmixed signals just like it does for the quad.  So the solution is easier now.

What you want to send out depends upon the range set-up for the individual servo.  Check out the init_rc_in in radio.pde.  So for the roll and pitch servos you'll want to send out values between -4500 ~ 4500.  For channel 3 (collective pitch) you'll want to send out values between 0~1000 i think.  As you've said, you need to remove all the mixing on it's way out to the servos.


Yes, the RC_Channel library is pretty hard to understand.  I think I spent a day looking at it the first time and writing down what it did to try and figure out what it was doing.  I'd like to rewrite that thing some day.

Alrighty that's good news. Any insights on the scaling factors and how they're applied to the outputs, and on how to incorporate the setup for setting pitch angles and all that good stuff? It seems like we should be able to decouple the outputs easily enough, but scaling them properly is much less clear up front.

Might be a strange question, but I wonder if anyone has an actual flow chart drawn up for the code flow. This isn't a super hard problem mathematically, but without knowing exactly what path has been taken to solve it, and with the actual code being so spread out across so many libraries, modding it is going to take a bunch of reverse engineering

"Yes, the RC_Channel library is pretty hard to understand" ... agree

Day 2 on it for me, was thinking of cleaning it up myself :)


      This is open source so if you do clean it up that would be greatly appreciated.

     I believe the libraries purpose in life is to transform between various possible ways to specify a servo position (i.e. pwm which is 0~1000, an RC style number which is 1000~2000 or a user defined range like -45deg ~ +45deg).  what i found confusing is that at least in the arducopter code, sometimes we put a number into "control_in" (which seems logical) but more often we put a number into servo_out which seems strange to me.  It seems like any "out" should be an output of the conversion function.

     Although it's slightly laborious normally we ask people to put dev changes into a clone and then someone on the dev team (like me or tridge) can more easily look at the change/patch and merge it into trunk.

     We have some notes on how to contribute on this wiki page although it's a bit out of date as it talks about subversion but we moved to GIT months ago.

     Anyway, no pressure, it's open source so you can do what  you like!

Actually, without fully rewriting it, just having it commented properly would be a huge help.  Explaining what each function does.

PWM = 0-1000

RC = 1000-2000

Angle = -4500 - +4500

I wasn't sure about the PWM one, so that's a big help.

Control_in and Servo_out, would love to know exactly how those work.

Reply to Discussion


© 2018   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service