ChOut9 through ChOut14 not working

I’m trying to control servos with these channels on a quadcopter. I can get channels 5,6,7, and 8 to do what they are told, but I can’t get any values to come up on the last 5. This would be for use with the “DO_SET_SERVO” waypoint type, or with the mission planner servo tab, the servo tab is how I am testing.

Thanks
Josh

Please be more specific. What parameters are you setting? Are you using a safety switch? If yes, are you testing after pressing the safety switch or before? What value does the BRD_SAFETY_MASK parameter have?

Thanks for taking a look

BRD_SAFETY_MASK = 16368
BTN_ENABLE = 0 (I turned this off because I’m playing on my desk trying to get them to work)
SERVO10_FUNCTION = 0 (all servos set this way 5-16)
BRD_PWM_COUNT = 6
RELAY_PINx - all set to -1

Using the servo tab on teh flight data screen I can get the outputs for 5,6,7 and 8 to output a PWM signal as commanded, but nothing on 9,10,11,12,13, or 14.

-Josh

I’ve looked at the code and I’m not sure why it isn’t working. Have you tested this with 3.4? Was it working?

Just rolled back to 3.4.5 and tested. After having to do some re-calibration I verified that the behavior is the same. I have the code and can build it, if you could point me to the general area this is in I could do some hunting there myself as well.

Ok, so it’s not related to 3.5, in the bad, that’s good. Code goes like this:

The mask is set when initiating Copter: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/system.cpp#L190

Given this I’m not sure where the problem is, but I think it can only be in the PX4 HAL layer (https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL_PX4/RCOutput.cpp). There are some messages printed there but only to the console - you might want to connect to it and see if you have any message there.

Alright, looking now, I assume this is all something that has been deemed working for sometime (sorry I just started looking at the code-base recently, but I’m familiar with autopilots and C and C++ in general)?

I think this code has been untouched for a while. And I think people usually just set the functions for their needs instead of doing the servo testing you are doing.

Cool, thanks for the tips. I did try to set Servo10 to be the parachute and that did not work, but setting servo8 to be the parachute did work. So I’m not sure how they would have gotten around this? But Now I’m pondering, because I have an X8 that has a gimbal that works that I am also running 3.5 on, the gimbal is the Tarrot type, it using Servos 9 and 11 it looks like.

Humm, ok, then we need to start considering a bad board. What board is it?

The one on my desk is a holybro PX4 (I have a couple of these so I could try another), The one in the x8 is a 3DR PX4. I’m trying to remember, and I’m not 100% that I have actually used the gimbal since switching to 3.5

Also I just built a little cable with an FTDI part to see the console, so far no messages, but I inserted a call to hal.console->printf to verify my sanity and got nothing on that also. I have to take a break, I’ll probably be hitting this again tomorrow.

Oh, and I do not think that it is a board, because the status for ch10out etc…always says 0. and when I monitor px4io with the console I see that the servo values for those channels are set to 0. Those settings should be agnostic of a board problem correct?

Just to make sure you have covered the simple bases…
You are aware that the upper ports are not powered like the lower ports? 1-8 motor ports have power so they will work with a servo directly connected, even tho it is not a good idea. But the aux ports are not powered, if you connect a servo directly nothing is going to happen, unless you power the output rail with a power source.

I have noticed that gimbal control on upper 9-14 ports does not work on the octo firmware and it was broken at 3.3.3. So it might be interesting to go back to 3.2.1 and see if it works.

It is also possible Michael has not gotten Mission Planner updated so it supports the extra channels on the tab. Can you test at a lower level like a parameter change.

I’m aware that the power for those servos does not exist but I expected the PWM ourput and the status for that chanel to report correctlty. Its interesting that you say the gimbal stopped working, like I said, I didn’t remember exatly if I tried that ginbal with 3.5, and that machine is on my desk at work.

It makes sense though that if the gimbal is broken then this would be broken as well. It sounds like there is maybe an initialization that got taken out at the point in time of 3.3.3. I’ll try reverting all the way back to 3.2.1 in the morning. Then it will be a diff-hunt to try and find the root cause.

My tests with trying to use gimbal control on 9-14 show that quad and hex firmware works and fails on octo and octo-quad. If you have the output rail powered then it looks like you have all you tees crossed to me.

LIke I mentioned Michael did not have the gimbal control page dialog boxes updated so you can’t choose 9-14 for gimbal control but you can do it manually by setting the appropraite parameters. Is there a way you can test without using the servo tab?

Its my understanding that the DO_SET_SERVO waypoint is the only other way to do this, but Its needs to set on the ground before getting int he air. To be clear, I have not put 5V in 9-14 yet, I’m still just trying to get the PWM out.

The console I was referring to is on the USB port. The one you are using is the debug console.

I’m missing something then Francisco. How do I connect to the USB console you are describing?

Simplify the problem. Set 9-14 on passthrough and see if they work that way.