Pixhawk 6C, PM07. Brand new at this. Just trying to get a basic plane configuration working before attempting a multicopter setup, you know to verify things are working. They’re not, at least not as I expect them to. I have verified radio calibration, and what I believe to be actual servo outputs which change with Tx stick movement on the “Servo Output” screen. I have tried connecting the servos to the PM07 FMU-PWM-out pins (with an external BEC supplying power to the “+” rail, and the cable connected between the FMU-PWM-OUT on the Pixhawk and the FMU-PWM-in connector on the PM07) as well as the GPIO set via the PWM output adapter that comes with the Pixhawk. If the servo isn’t “centered” (at least I’m assuming centered is what the FMU is putting out) when it’s connected it moves to a new position, so the servo is getting power, just not being commanded when I move the sticks. I know the throttle servo won’t move until it’s armed. I’m sure it’s something simple, but I’m lost.
Sounds like your servo is powered and getting a valid pwm its just that the pwm is not changing with your rc, main pwm has the first four( or is it 8) pwm going to the pads on the power module for the escs the auxiliary pwm out has the next 8. I just swapped the plugs for plane so that the first 8 went to the servo pin header. If you’re getting movement on the servo out bars in mp you are pretty close
There’s some confusion around the Holybro Pixhawk output naming I think.
I/O PWM OUT
is the Main output: Servo1, Servo2 … Servo8
FMU PWM OUT
is the Aux output: Servo9, Servo10 … Servo16
Yep its all designed around a copter use case, the first 8 go to the little s1 s2 pads designed for esc, the servo header board included plugs into aux and pwm outputs are 9…16, i just plug the servo aux header into the pm07 main out connector on the fc for fixed wing use, actually i ditches the pm07 all together as it’s far too bulky to go in a fuselage
Update. It seems that what I thought was the servo positioning itself was actually it merely going to a random position upon getting power. It does not even attempt hold it’s position so it is obviously not getting any PWM signal, or the pulse-width/-frequency in the PWM signal are so far away from what the servo is expecting that it doesn’t know what to do with it. I have tried it on all 16 ports, same thing. I also tried a different model servo, and it doesn’t do ANYTHING when plugged in. Tried the servos on a centering box and they move as expected. I tried assigning the rudder channel to all 16 channels in MP (servo output page), but only the first 8 “outputs” respond to the Tx stick movements, the high numbered 8 show a value of zero even though they are assigned the rudder value. Gonna go out on a limb and guess that “0” means no PWM at all–maybe further indication of what I’m doing wrong? Is there someplace I need to enable the upper 8 channels?
@scubabeme a tlog or a bin log with LOG_DISARMED=1 would tell us what is going on.
It could be as simple as not disabling the safety, which is on by default. Did you change BRD_SAFETY_ENABLE?
Yes I forgot about board safety,
@tridge i was recently trying to find out how safety differs from arming, I realise safety is released from a physical button connected to the fc instead of a mag command or rc command but it’s all just software controlled like arming right?
Or is board safety actually an electrical hardware function that prevents power or pwm output somehow seperately from the flight controller software?
It’s under software control. There’s no special latching hardware.
In a lot of cases, especially with large copters and big props, the “safety switch” is opposite of it’s intended purpose → you dont want to be anywhere near the props to even press that button for arming, and it would be impossible to get near it to disarm a misbehaving vehicle.
I always have the emergency stop configured on an RC channel (and Arm/Disarm on a transmitter switch too)
RC13_OPTION,31
for those times when landing may not be detected or things are getting out of control.
Ok so it’s all software controlled and I think I worked out that the safety switch was only good for the application where the bot has no rc or gcs so you can just boot into auto armed and press the safety switch to make it start the mission.
From an actual safety point of view the only thing we have that doesn’t rely on software is to unplug the power, everything else (arming, estop, safety sw) is the same level of protection from a risk assessment point of view where a malfunction could cause unintended motor starting etc,
Is the above statement on the mark?
Probably, except that the code is stringently reviewed in regard to the safety switch and estop and it is well understood. None of the flight controllers that I’m aware of have any harware-based safety more than any other flight controllers.
I think competitions such as the Outback Challenge dont have any additional safety hardware requirement over and above what we all have now. The rules only talk about a functioning failsafe on link-loss or exceeding the geofence. The arming status LED is changed to a traffic light system, but that’s inconsequential.
Commercial operations are able to gain insurance with the current system. Although that alone doesnt mean everything is right with the world, it could be a key indicator 
Ok, it makes sense, I noticed on the bench just last night while trying to change from SBUS/SPort to ELRS/CRSF at one point the rc input on mp started showing noise on all channels while the transmitter was on and not being touched (a result of mismatch of connections and protocols during changes and testing) this resulted in arming and throttle inputs to the flight controller which tried to spin up the motors on the bench. Nothing was wrong with arming code or any other code but it was just an example of how there is no actual isolation of the motors and a fault can cause unintended operation.
Industries who have no appetite for risk and are very used to machine whole current isolation policies and hard wired e-stop systems would be difficult to convince that a switch on a transmitter over an rf link which controls a software variable will ensure that the big prop cannot start and cut their fingers off.
I don’t have a better idea at the moment, maybe a timed latching relay for the power up so you can plug it in and have 20s to get out of the way and a gpio which somehow releases the hold in on the same power relay and renders the entire thing dead would work. I’ll keep thinking of options in prep for if and when I get pushback from potential end users I guess
Also check BRD_SAFETY_MASK is set correctly, so your motors would have no way to operate until the FC is actually armed.
It was armed by the variation in the rc input, at the time all the channels were randomly varying all over the place, including the arming chanel
But yes I will recheck the parameter to ensure it doesn’t allow pwm when not armed
Ah I see. I’ve never used ELRS/CRSF and not had that problem with conventional RC or SBUS.
I have my arm/disarm channel working of a switch combination, so maybe that would prevent the effect you are seeing.
I still haven’t got it working either, I went back to sbus for now, I moved the wiring to a different uart and then was changing parameters to suit new connections and in the middle of all that it armed and started motors without rc transmitter being touched, (was on but no stick or switch input)
Downloading the long-winded log now. (Assuming changing LOG_DISARMED and writing the parameters turns on mega-logging). However, I don’t think I need it now. I was not aware that one needed to use the safety switch to enable anything to work! Pressing and holding it turned the LED solid red and the servos work. I’ve not noticed anything in the documentation that indicated that was necessary no matter what you were trying to do. Now to press on with everything else–after the log download finishes and I turn off LOG_DISARMED. Thanks for the clue! BTW, the FMU PWM pins are the ones for servos in “plane” for those that suggested that the labeling was confusing. IMHO, it’s not, the work exactly as I expected–once I used the safety switch!.
Well, nuts. I’m back to no servos working (powered but no PWM), but now the safety switch HAS been pressed, LED is solid red. I have NO idea what I did to cause this. I have tried to “start from scratch” by loading a different firmware (copter) and then reloading plane. No change. Does such an action make the Pixhawk “forget” all previous parameters, and if not, what is the procedure for that? (I.e., a complete factory reset on the Pixhawk and possibly MP) I can still see the servo “outputs” change when moving the sticks, but clearly what MP is calling an “output” on that page is just what they should/would be in a perfect world with all devices and parameters in EXACTLY the right configuration. Beginning to think this purchase was a “lessons learned” (“too many options, it’ll be too hard or impossible to get it configured correctly”, versus “lots of options, I can get it to do what I need”) mistake.