SBUS Out RC passthrough with relays used

ArduCopter Copter 4.0
1

I have a few questions about how PWM outputs vs relay outputs are handled on the Servo channels 9-16 with an Orange Cube in particular. It appears that the number of relay outputs can be altered with BRD_PWM_COUNT. By default it appears that AUX 5-6 are set as relays (BRD_PWM_COUNT=4).

Question 1. What is the status of Servo 15-16 in the default condition? The first rule of Servo 15-16 is not to talk about Servo 15-16 in documentation.

What I really need to do is pass RC channels 9-16 through the servo channels so that they appear on the SBUS out from the FC (controlling a gimbal etc.). I know about turning on the SBUS first and enabling the safety switch, if used.
The issue is that BRD_PWM_COUNT on the aircraft in question is set to 0 and RELAY_PIN_2 = 54 (AUX5). This relay controls a video feed switch and so is required.

Question 2. With no PWM outputs configured on AUX1-6 (see above), if I assign RC passthrough on Servos9-16, what happens? That is, does the relay still work when called for AUX5 but Servo13 is passing RC13 to the SBUS? It is unclear to me from reading the documentation what happens in the above case.

Question 3 is: Is the relay AUX5 now nothing to do with the Servo channels, or is it still linked in some way so that the RC13 channel messes with AUX5 relay or vice versa? I am seeing some strange behavior and trying to understand it.

Question 4: If one wanted to pass RC13 to Servo13 so that SBUS out channel 13 reflected RC13, is there any difference between SERVO13_FUNCTION being set to 1 (RC passthrough) and 63 RC13. Are there any circumstances when this setting results in different behavior?

Question 5: Does Ardupilot try to do anything ‘smart’ with renumbering servo channels if there are Relays set? in other words, normally SERVO13 corresponds to the AUX5 output, however, if AUX5 is a relay, is SERVO13 now mapped to CH15 (or the next spare channel)? If so, it might explain something I am seeing.

The above appears to be one of the issues with ArduCopter and the Orange Cube that cause the most confusion (mapping outputs) mainly because it is a mind bender (RC13, SERVO13, abstraction layer listening for RC13, SBUS 13 etc.), yet the documentation is a bit unclear to a novice and very scattered. For example the Relay page discusses BRD_PWM_COUNT, but makes no mention of what knock on effects it causes for Servos, if any.

Many thanks for your time.

Philip

2

Because they don’t exist? Here are the available AUX outputs for Cube Orange (from Hewdef):

-Now we start defining some PWM pins. We also map these pins to GPIO
- values, so users can set BRD_PWM_COUNT to choose how many of the PWM
- outputs on the primary MCU are setup as PWM and how many as
- GPIOs. To match HAL_PX4 we number the GPIOs for the PWM outputs
- starting at 50.
PE14 TIM1_CH4 TIM1 PWM(1) GPIO(50)
PE13 TIM1_CH3 TIM1 PWM(2) GPIO(51)
PE11 TIM1_CH2 TIM1 PWM(3) GPIO(52)
PE9 TIM1_CH1 TIM1 PWM(4) GPIO(53)
PD13 TIM4_CH2 TIM4 PWM(5) GPIO(54)
PD14 TIM4_CH3 TIM4 PWM(6) GPIO(55)

3

It is true that there are no physical pins to access for Servo 15-16, but they do exist as addressable channels and can appear on the SBUS. This is the bit I am questioning.

4

Ah, OK. I know that if you enable BRD_SBUS_OUT with a chosen Frame rate and then configure SERVO15_FUNCTION it will output on the Sbus out pin. Tested this by configuring it for RCIN6 (56) which is a pot on my radio and SBUS channel 15 is controlled (scoped it).

5

I received only partial responses and so spent some time with a spare Cube Orange trying a few things for myself. Hopefully a few keywords here may be found by others saving them some time and confusion.

A few caveats. This was tested only on a Cube Orange, it will probably not be true on some other FCs where users are responsible for configuring every port themselves and nothing is assumed (e.g. Maytek range). Finally it appears that there are major changes coming in 4.2. This may have all sorts of consequences for what is written below…

Two notes. BRD_SBUS_OUT must be changed from default 0 to 1 for 50Hz output (standard). SBUS output is not electrically enabled until after the safety switch is pressed (if fitted and used).

Question 1. What is the status of Servo 15-16 in the default condition? The first rule of Servo 15-16 is not to talk about Servo 15-16 in documentation.

A) As pointed out above, the cube does not bring servos 15-16 out as pins. However, they are still there for SBUS and appear to just be regular disabled servo channels after flashing. That is, use of them for RC passthrough is just fine.

Question 2. With no PWM outputs configured on AUX1-6 (BRD_PWM_COUNT=0), if I assign RC passthrough on Servos9-16, what happens? That is, does the relay still work when called for AUX5 but Servo13 is passing RC13 to the SBUS? It is unclear to me from reading the documentation what happens in the above case.

A) The BRD_PWM_COUNT on the cube only affects the physical outputs Aux 1-6. Setting COUNT=0 allows the AUX channels to be configured as either relays or more complex serial I/O. Setting servo passthrough on Servo channels 9-16 is correctly reflected on SBUS out. So for example even through AUX 5 (normally associated with Servo-13 if BRD_PWM_COUNT=6) was configured as a relay on my system, setting servo 13 to passthrough of RC13 worked fine and the relay on AUX 5. could still be controlled as one would hope.

Question 3 is: Is the relay AUX5 now nothing to do with the Servo channels, or is it still linked in some way so that the RC13 channel messes with AUX5 relay or vice versa? I am seeing some strange behavior and trying to understand it.

A) They apparently become decoupled. The strange behavior was an undocumented and undesirable feature of the ground station I was using.

Question 4: If one wanted to pass RC13 to Servo13 so that SBUS out channel 13 reflected RC13, is there any difference between SERVO13_FUNCTION being set to 1 (RC passthrough) and 63 RC13. Are there any circumstances when this setting results in different behavior?

A) As far as I can see, RC passthrough of 9 to 9, 10 to 10 etc. is identical to explicitly setting passthrough of RC 9, RC 10 etc.

Question 5: Does Ardupilot try to do anything ‘smart’ with renumbering servo channels if there are Relays set? in other words, normally SERVO13 corresponds to the AUX5 output, however, if AUX5 is a relay, is SERVO13 now mapped to CH15 (or the next spare channel)? If so, it might explain something I am seeing.

A) Nothing smart, just the same dumb undocumented feature of the ground station mentioned in Q3.

One aside. Mission Planner and AUTO Missions can apparently override the PWM RC signals inputted from the ground station and then be reflected on the SBUS out. So for example, if a switch on RC channel 13 of the ground station is in a low PWM output position (1000us), doing a DO_SET_SERVO 13 to 1900us will override the physical switch and change the PWM on the SBUS channel 13 to 1900 until either mission planner alters it again OR the physical switch position changes. This needs to be thought through in case your application could cause an unexpected event. Having considered a few of my applications, I cannot see and catastrophes pending, but that may not be a general statement.

Of course, this is not what the authors of Ardupilot want you to do. What you should do is to associate the RC in channel with the built in functions (gripper, parachute, gimbal position etc.) and then call the function in the mission (DO_GRIPPER etc.). The output is then always controlled my MAVLINK not by RC passthrough. Of course, the physical switch still ends up potentially in the wrong location with respect to what the PWM signal to the gripper is actually doing.

Hope this helps others.