Copter: “Channel 7 already assigned 1” message

[RowanWatkins]

Issue details

Continuous output of “Channel 7 already assigned 1” message when ArduHeli is trying to initialize the helicopter rotor speed output. This message continuously loops due to the initialization request repeating and floods the USB port with this message. The message shows up using MAVProxy but is hidden on Mission Planner.

Cause: If SERVO8_FUNCTION is set to 1 (Passthrough), on initializing the code fails when it can't assign the rotor speed output to Channel 8 because it is already assigned. This generates the message “Channel 7 already assigned 1” due to the channel numbers being zero indexed, Ch8 = Ch7 in the code.

Solution: If SERVO8_FUNCTION is set to zero, on the next reboot the default will automatically be set to 31 and the issue is resolved.

Version

APM:Copter V3.4.2 (6076bdf) and APM:Copter V3.5.4 (284349c) TradHeli setup.
(ArduHeli V3.4.2 and ArduHeli V3.5.3 was initially reported but is not correct)

Platform

Copter

Airframe type

Helicopter

Hardware type

PixHawk

Logs

[OXINARF]

Hi @RowanWatkins, welcome!

Can you explain to me what exactly you are reporting? Is it just the wrong the number in the message or do you think something should be done differently?

[bnsgeyer]

@ChristopherOlson have you been made aware of this issue? I'm fairly confident that this is not specific to ArduHeli. I suspect that it would occur in ArduCopter, Trad heli frame as well. I will test this and report back. I never realized this when I saw this previously in my testing that it was reporting the wrong channel. Regardless I think that not only is the reporting of the wrong channel an issue but also the fact that the code doesn't handle the reassignment well, causing the error message.

[MidwestAire]

@bnsgeyer this is the first I have been made aware of this issue. I will test it as well and see what I come up with. The version is reported as ArduHeli 3.4.2 and 3.5.3, which is somewhat confusing since there never was a 3.4.2 build of the ArduHeli development firmware for helicopters. I suspect if valid that it does not apply just to the ArduHeli helicopter builds, but also to the ArduCopter TradHeli builds as well.

[bnsgeyer]

@OXINARF and @ChristopherOlson There are two issues here.

1. The channel number defined in the "Channel X already assigned 1" message does not reference the correct channel number. As @RowanWatkins states, it appears to be using channel numbering that starts with 0 rather than 1 thus the referenced channel is 1 less than the channel the user refers to. I believe this error to be contained in the SRV_channel_aux library in the set_aux_channel_default method.

2. It appears that heli defaults channel 8 to main rotor RSC. So if it does not see another channel assigned to the main rotor RSC, then it assigns channel 8. I guess this is happening after the channel assignment occurs based on the SERVO8_FUNCTION and when the code tries to reassign main rotor RSC to channel 8 using the set_aux_channel_default then "Channel already assigned" message appears.

So the work around for the second issue for now is that the user needs to specify the main rotor RSC on another channel before changing the function of channel 8. @R-Lefebvre would appreciate any insight on this since you designed the RSC. I believe you defaullt it to channel 8 because a heli has to have a main rotor RSC assigned.

[MidwestAire]

I believe channel 8 was selected for default heli throttle control due to 1-4 being used for normal flight controls, 5 for flight modes, 6 for tuning, 7 for functions, and 8 was all that was left so became the logical choice.

Maybe @tridge should look at this as well as I think he was involved in the design of the servo library and may have some thoughts on whether this issue is an actual bug, or if it was designed that way for a reason. It doesn't appear to actually break functionality if a user assigns a SERVOx_FUNCTION to Heli RSC. It won't let the aircraft be armed or flown if the settings are incorrect. At the worst I would say it is a bug in reporting what the actual problem is with the settings.

[RowanWatkins]

Sorry for the delay in responding.

Firstly in response to the comment from @ChristopherOlson , I apologize as the code versions were APM:Copter V3.4.2 (6076bdf) and APM:Copter V3.5.4 (284349c) TradHeli setup.

This issue was discovered by @tridge when I asked him for assistance with the “Channel 7 already assigned 1” message continuously repeating when attempting to connect via MAVProxy.

We were able to reproduced this error on 3 different PixHawks. We found that with the default heli-parameters loaded and then setting SERVO8_FINCTION = 1, that on the next reboot as the Heli RSC Output is initializing it wants to use Channel 8. When it finds a value of 1 already present this created a loop producing the message “Channel 7 already assigned 1”.

@tridge said that this is a bug and is saying Channel 7 because the Channels are zero indexed, and Channel 7 is therefore actually Channel 8. He said that this is caused due to a recent change where the code previously only tried to initialize the motors output once, but now it tries continuously to initialize and therefore enters the loop.

@tridge said that this is flooding the USB port with this message which is using a lot of the CPU and the aircraft is likely to fly badly as a result. This only shows up using MAVProxy as it is hidden on Mission Planner. Mission planner will connect while this is loop is occurring, but this has caused many timeouts and slow data rates between the PixHawk and Mission planner.

We were able to remove the problem by setting SERVO8_FUNCTION to zero and allowing the Heli RSC initialization to modify the value on the next reboot. The function then gets set to 31 and the problem is no longer present.

This issue was originally discovered when the SERVO8_FUNCTION was set to 1 = pass through for use on an external governor for rotor speed control.

[MidwestAire]

This issue was originally discovered when the SERVO8_FUNCTION was set to 1 = pass through for use on an external governor for rotor speed control.

@RowanWatkins I do now understand how the issue was found, since FBL units and external governors almost universally use Channel 8 for governor on/off function, which is of course tied up in TradHeli with the default RSC signals. The SERVO function for Heli RSC was not mappable in 3.4, but it is in 3.5.

I think we definitely need input from @tridge on how to approach this one. In my tests here with the ArduHeli development firmware, v3.5.4, if I set any other SERVOx_FUNCTION to 31 and assign SERVO8_FUNCTION a value of 1 the problem does not exist. It only happens with an invalid configuration where no SERVO is assigned to HeliRSC. The servo_init getting tied up in a loop is definitely a bug. But being it only happens with an invalid configuration it sort of muddies the waters.

[tridge]

The message will go away when we merge #8442
We should however consider adding an arming check to see that all expected functions are assigned. For example, it could report that "Function 31 (HeliRSC) not assigned to any output" as an arming failure. To do that we'd need an API that asks AP_Motors to check if all required functions are assigned to at least one output, plus an array of const strings so we can give the user a name for the function that is missing.

[bnsgeyer]

Issue corrected with PR #8442.