Hi All,

 

Im having a bit of brain fade. Having just upgraded to 2.9.1 from 2.7.3 its been a while since Ive had to do much setup. Ive also added a frsky d4r-II rx in ppm mode to the mix. Ive already thrown the 27ms software upgrade onto the rx, which seemed to go ok. Ive put 2.9.1 on my apm2 all ok, Ive come to setup the radio and i seem to have my roll and pitch swapped over (when moving the roll stick on the tx, it makes the pitch bar move on mission planner and visa versa). Tried a google search to no avail. Ive also had to change from mode 1 on my jr pcm9x tx to mode 2 to get the throttle correct on mission planner.

 

If anyone can shed some light on my issue it would be much appreciated.

 

Alex

Tags: Frsky, apm2, cppm, problem

Views: 2013

Reply to This

Replies to This Discussion

Randy,

First, thank you so much for taking the time to look into this.

However, on JR transmitters throttle is channel one, aileron is channel 2, and elevator is channel 3, therefore we actually need to change the order of the first 3 channels.  Will having the throttle on channel 1 create a problem with the throttle failsafe feature? 

It would be nice to see a setting in the Mission Planner to adjust this easily.  Maybe in the near future we can have that feature...hint, hint...LOL!

 

Thanks for the info.

 

Beau

Beau,

      Ok, so it's just reordering this three lines then.  The number on the left (i.e. g.rc_1) is the internal name for the channel and that shouldn't be changed.  The number on the right (i.e. CH_1) is the actual channel number on the incoming ppm stream.  So just need to move the CH_1, CH2 and CH_3 around to look like below:

static void read_radio()
{
    if (APM_RC.GetState() == 1) {
        ap_system.new_radio_frame = true;
        g.rc_1.set_pwm(APM_RC.InputCh(CH_2));                // rc_1 is roll or aileron
        g.rc_2.set_pwm(APM_RC.InputCh(CH_3));                // rc_2 is pitch or elevator

        set_throttle_and_failsafe(APM_RC.InputCh(CH_1));   // rc_3 is throttle


-Randy

Randy, 

I figured that is what was needed, but I was afraid it might not play well with the failsafe function of the throttle.  I guess as long as the radio.pde knows which one is the throttle channel and passes the correct information to the APM, it really doesn't matter which channel of the transmitter is the throttle.  I still have not had a chance to try this, but I hope to this weekend.  I will let you know what I find out.

Thanks again for your help on this.

Best regards,

Beau

Beau,

    No troubles.  From the APM point of view even with the above changes the failsafe features should work correctly.  You can see above that the "set_throttle_and_failsafe" function is being passed the channel 1 input to it's checks so I think it'll do the right thing.  Here's the issue ticket for the longer term fix.

Isn't the issue that when the PWM signal is lost on channel 3 it sends it as a fixed PWM on CH3 to the APM, the PPM encoder is doing this because it is throttle not the reassigned CH3 which is elevator. You can recompile this behaviour in PPM encoder FW to the new CH1 which is throttle now.

Bill,

    Ah right!  of course, sorry, you're right.  I was only thinking about parts #1 and #3 but forgot about #2.  Ah, that is a little tougher...it'll require a special ppm encoder for the fr receivers.  In which case we should just push all of the problem down to the ppm encoder perhaps..make it do the channel swapping for us.  that would save me some work!  :-)

Oh. And to add further to the questions i had a realization that isn't PPM Encoder in "pass through" mode. So maybe it does work?

Oh again, but what does it do
On flat line PPM in?

Bill,

    So there are two ways to hitch up the ppm stream.  If you attach to channel 5 of the APM it'll go straight through to the APM bypassing the ppm encoder completely.  This is an undocumented feature 'cuz I think we think it's not the right thing to do.

     if the ppm encoder (or the receiver which has bypassed the ppm encoder via the ch5 thigng) sends a flat line, as of 2.9.1 it will see this and after 2 seconds a failsafe will be triggered.

     So a possible solution is to use the ch5 thing + the code fix I pasted above and it all might work.  I guess it brings us to the question, if we're using a ppm stream is the ppm encoder providing any value?

I did some reading, and it looks like when the PPM Encoder is in pass thru mode  it does not do anything with the signal at all. It's just like you connected to CH5 with the solderpad on the board you mentioned.

The Encoder goes into this mode when it first detects pins 2-3 are connected on boot. so even if the PPM signal flatlines due to RX failure for example, the encoder will not substitute a value for any channel.

This means the changes should work as Randy explained. Set throttle failsafe on your Tx as normal and all should be good

Hi Bill

Have you had chance to implement any of the alterations to the code that Randy mentioned?

I've started a discussion to try and get extra help with code altering and stuff as I am starting from scratch. Its here if you're interested.

Alex 

Thanks to everyone who helped with this issue. I managed to sort it with Randy's short term method of altering the code. 

As there was an air of uncertainty with regards to changing channel 3 (throttle references to different flight modes) I decided to just set my tx to mode 2 and just change channels 1 and 2. I did this by modifying the radio.pde's read_radio() function in the arduino program downloaded from the downloads area. Randy has mentioned that a more permanent fix will be available in a later release, if not the next one the one after that.

I also would like to thank everyone that helped with this.

Alex,

I am glad to hear that works.  I haven't had a chance to try it yet, but hope to in the near future.

Best regards,

Beau

RSS

© 2014   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service