Pix Racer/Mission Planner Doesn't control the servos in response to changes in orientation

Hello,

I’m using a PixRacer V1.0 with an Align Trex450 and have struggled with a number of problems but have now arrived at the situation where everything is calibrated, the radio moves the servos, as expected, and the system arms ok. The artificial horizon moves as I change the orientation of the helicopter so all seems well…except that when armed and ready to go, I would expect the servos to respond to correct changes in orientation of the airframe…and they don’t. Surely this is incorrect? Obviously I don’t want to launch skywards without knowing the system will auto stabilise (I’m in Stabilise mode) when I get up there!

Can anyone give me some advice please?

Many thanks in advance.

Hi Damien,
as you have a traditional Heli TRex 450 it would be good if you ask your questions in the traditional Heli sub forum. @bnsgeyer is th expert and very friendly and helpful.
How you are tested this behaviour. I don’t think that you are armed and spooled the rotor up and than moved the airframe by hand?

Hi Juergen, my problem has nothing to do with the airframe…the problem is with my PixRacer/Arducopter. My guess therefore is that by posting in the T450 forum would just limit the number of amswers I get…and possibly to zero, if no-one has set this up on a T450!

Yes, the system is armed and the rotors are turning. Incidentally, I can spool the motor up with the PixRacer disarmed…ie I could launch into flight with no stabilisation with could have scary consequences!

As mentioned, the artificial horizon moves as expected, but the servos do not :scream:

Apologies…‘Mission Planner’ not Arducopter as such!

Please post a log demonstrating this behavior on the bench. At a minimum post your parameters.

This is a helicopter set up problem. Meaning you have set it up incorrectly. Have you followed the wiki instructions?

Please post your parameters so that I can have a look to see what the issue is.

This has nothing to do with Mission Planner. Moved to TradHeli. Glad Bill is here to assist.

1 Like

Hi Yuri, thanks for your thoughts, but why do you say it is nothing to do with mission planner please…it has nothing to do with the airframe. My T450 has already flown very well for many years.

Hi Bill, apologies, being somewhat new to mission planner and this forum, can you advise how I post a log demonstrating the behaviour please? I also don’t know how to post my parameters but I assume there’s a file I can copy from somewhere?

My pixracer is brand new and un- used (when I bought it some years back) so any mission planner setup error is likely by omission.

Clearly I have set mission planner up incorrectly! but I am hoping for some clues as to what look for…I will of course post logs and parameter files if you can help me do that please.

As far as I am aware, I have followed the main setup instructions…

Hi Damien,
MissionPlanner is just a Ground Control Station Softtware (GCS) It only displays what is send from the FC Firmware. Maniupalating Servos is done by the FC Firmware and this is different on different types of drones like rover, copter or even traditional helis so it is depending to the airframe in this case.
The log.bin file you can get by connecting the FC via USB to PC with Mission Planner. Select on Mission Planner the yellow marked tab and than download the log by the blue marked button. The log.bin file also includes your params.
Upload the log.bin via a unrestricted free filesharing service

@Juergen-Fahlbusch thanks for providing the directions for download a log!

@DamienWalker if you want to demonstrate this on the bench without arming the aircraft, then you will have to enable logging while disarmed by setting LOG_DISARMED to 1. Be sure to set it back to zero after you have completed your demonstration. Otherwise it will always log when disarmed and that will fill up your SD card.

Thanks Bill and Juergen…I’m away today but will try to send you the files upon my return tomorrow.

Hi Juergen…just a misunderstanding between us then…but this problem is clearly a problem in the FC set up. Yes, my airframe is a traditional helicopter but the problem is definitely in the FC settings…which is why I posted where I did as the T450 itself is not implicated. Mission Planner also provides access to the FC firmware settings so my problem is with ‘Mission Planner’ and nothing to do with the actual airframe - 'trad heli- yes, T450 - no. Apologies for the misunderstanding!

Again, your problem is GCS agnostic, and is most relevant to the TradHeli category, where support with such configuration is given.

You’d be having the same problem if using QGroundControl or any of the other available GCS software. Specifically, you are looking to observe servo movements that are particular to the TradHeli branch of ArduPilot, which places this issue solidly where I moved it.

This topic is in the appropriate category, and it isn’t worth debating further.

Hi Bill, here’s my log file…hopefully this will reveal my mistake!

Many thanks for your assistance.

D

2025-04-16 12-22-46.bin (470.2 KB)

@DamienWalker Your issue are these settings

SERVO1_FUNCTION 51
SERVO2_FUNCTION 52
SERVO3_FUNCTION 53
SERVO4_FUNCTION 54

Why did you change these from the defaults? I’m sure your swashplate was not working correctly either. Or did you use the Heli frame type in your RC transmitter? If you did then that is not correct. Typically I use a plane frame type in my RC transmitter which removes all of the mixings for heli’s. All of the mixing is done by the flight controller.

Please set these parameters as follows
SERVO1_FUNCTION 33 (swashplate front left servo)
SERVO2_FUNCTION 34 (swashplate front right servo)
SERVO3_FUNCTION 35 (swashplate rear servo
SERVO4_FUNCTION 36 (tail rotor)

What servo output of the controller is your engine or ESC connected to? You have a lot of servo functions with the RC pass through. You should NOT have any servo functions with a RC passthrough. The engine/ESC should be connected to servo 8 output to allow the flight controller to manage the engine for you and abide by the safety features like not allowing the engine to start unless you are armed and have motor interlock enabled.

1 Like

Hi Bill,

Thanks for looking at this for me.

The route to the current state of the set up of this FC has been rather tortuous I have to say. I don’t recall the full sequence of events to get the thing to ‘work’, but a major problem has been my ownership of Futaba RC gear which I don’t really see a need to change from (because it works!) My original Rx is conventional PWM and so not compatible with PixRacer. I purchased an R6203SB S.BUS receiver to use with the PixRacer S.BUS capability on RIN, only to find that it does not work (Juergen has suggested I try inverting the Rx output which I have not managed to do yet). It is therefore entirely possible that I changed the settings you refer to during my attempts to kick start either the Rx input or to address the problem that I now refer to (ie the FC not controlling the servos in response to movements of the airframe). I can however confirm that my swashplate is working correctly and I am confident that the helicopter would fly (but with no FC assistance). I am now working with a PWN encoder which, whilst being a neat little unit, adds a mass of wiring which I don’t like at all - it would be so much better to wire directly using S.BUS. (ie so whilst I will test the idea, using an invertor on RCIN doesn’t appeal either for reliability reasons and this may eventually force a change in radio).

Unfortunately, the swashplate settings that you recommend, do not exist in the list I have. There are too many options to list to show you what options I am offered, but ‘swashplate*’ does not appear. If I set ‘33’ directly against SERVO1_FUNCTION, this is interpreted as ‘Motor1’ (SERVO2_FUNCTION is Motor2 as might be expected). I suspect that had I seen swashplate commands here, I would have been able to fix this myself. So, that begs the question: why do I not have swashplate options against these servo functions? Is there something wrong with my airframe selection? (Frame class - image selected is that of a conventional helicopter).

My Tx only has 6 channels available, so I cannot use channel 8 for the motor as you suggest. Well, I cannot use Channel 8 and have direct correlation between the Tx stick and the airframe. The standard TREX450 setup as recommended for Futaba is:
Channel 1: Left front Swashplate
Channel 2: Centre Rear Swashplate
Channel 3: ESC
Channel 4 T/R
Channel Gyro (I am using this to select between two FC flight modes)
Channel 6 Right Front Swashplate (referred to as ‘pitch’ - that presumably being a klingon from early collective pitch helicopters which required an extra servo?:

I don’t recall seeing any of this in the online instructions I have found to be honest, so if you could direct me to the wiki that you refer to, that might help please. Equally, I haven’t
read anything that tells me to stop using Tx CCPM mixing and so still am, though I start to setup a Model that uses straight ‘Elevator’ and ‘Aileron’ mapping when trying to resolve strange swashplate behaviour (which turned out to be caused by a new servo being reversed and the FC apparently swapping Channels 1 and 2).

If my setup is now badly compromised, would it be wise to do a factory reset and start again? If so, how do I do that please?

My final thought is that my two PixRacers are both V1.0 but I cannot find any directly relevant documentation for this early version. Is it possible that I am struggling because I am following the online documentation that is more relevant to the latest version?

And I think ‘Arrrgghhhh’ would be an appropriate comment!

Your assistance is much appreciated.

Best regards,

Damien

Under configuration in the tradheli wiki, please watch the video for configuring servo, motor, and RC connections on this page. I think this will walk you through everything that you are asking.

Here is a video on the swashplate setup. It is very important that you perform the steps in this video and ensure the swashplate is setup properly

If you have questions after watching these videos, please post here. I have a futaba radio and I use the 6303 receiver and everything works fine. I haven’t used the PixRacer though. But it seems that you got it connect since the swashplate is moving with the rc passthrough.

I don’t think you need to start over. I believe you’ll just need to watch the video and change the settings to what I have shown on the heli page. When you are done, there should not be any RC pass through. You will have to move the Motor Interlock function on the RC input to channel 6. There is no screen on the Setup Tab to make this change. You will need to go to the Config Tab and then select Full Parameter List on the left side. Scroll in the left pane until you see RC6 and click on that. You can then change the RC6_OPTION to 32 (motor Interlock). Then go to RC8 and select RC8_OPTION and set that to 0. This will allow you to turn you motor on and off thru channel 6 on your transmitter. see the pic below.

Thanks again Bill, I’ll revisit this again tomorrow hopefully, though I have a busy day (Easter/family etc).

The R6303 does not work with a PixRacer V1.0 with RCIn set to sS.BUS protocol…I’m currently ‘operational’ with an R606FS, and a PWM 8 to 1encoder.

I’ll report progress.

Best regards

Damien, I never liked the 8-1 encoders. I don’t trust them. Set the RC protocol to 1 (all). Then plug in the 6303 from the SBUS out to the RC in of the Pix racer. use a cord to connect the pix racer to a computer running mission planner and connect to the pix racer. on the Data Tab, select the Status tab in the lower left panel as shown in this picture.

Then scroll over until you see the Ch1in, Ch2in … as I have shown in the picture. move your RC transmitter slowly and verify that the PWM values are changing for the Ch1in, Ch2in, Ch3in, and Ch4in. If those are changing then the pix racer is receiving the RC transmitter signals.

Hi Bill, there’s no electronic reason not to trust such an encoder but it is undoing the good work that the decoder in the Rx has already done for you. In the early days of proportional radio control, the Rx had two boards: a radio receiver and a decoder with the decoder doing the exact opposite of what one of these 8 to 1 encoders does…if the decoder can split the train of pulses into individual channels reliably, then the encoder should be able to stick them back together again! If technology hadn’t moved on, I would simply connect the radio receiver output pulse stream directly to the PixRacer, bypassing the decoder and (re)encoder circuits completely and it would work also taking out the inevitable delay that such circuits add but that’s not so easy these days. My dislike of the idea stems from the concern about reliability…extra wiring, extra circuits and all to undo something that didn’t (in this case), need to be done in the first place…but I guess you know all this!

I will follow your guidance and recheck, but at the moment, I am confident that a PixRacer V1.0 will not work with a Futaba S.BUS Rx and my confidence comes from the following:

With RCIn protocol set to All, PixRacer can see my radio if I use the 8to1 encoder as proven by the radio calibration routine in Mission Planner. If I swap to the R6303, the radio calibration routine shows no activity…there’s only three wires on the S.BUS so I can’t have a wiring fault as I power my Rx from the RCIn port and I have checked for the presence of an S.BUS signal with an oscilloscope. The other PWM outputs work on my R6303 so I think it is ok. I haven’t actually tested it in an S.BUS network but I have no reason to suspect the S.BUS functionality.

S.BUS uses inverted logic levels compared to a conventional UART so Juergen’s suggestion to try an inverter makes sense..it could be that PixRacer V1.0 doesn’t have the necessary inversion on the UART used for RCIn or even have any S.BUS capability available all…but no doubt I will find out!

I shall let you know.

D.