Please change the way arming works, always send a PWM signal

[julianoes]

As discussed the stock ESCs do not initialize unless they are sent a PWM low during the first 3s after startup.

Also ESCs with stock and simonk firmware start to beep when they are disarmed and lack a low PWM signal.

Therefore the mixer should determine if the standard (disarmed) position of the channels is low (for ESCs) or neutral (for servos) and set them accordingly.

[px4dev]

It's not clear what you mean by "stock" ESCs. There are a number of different arming behaviors that off-the-shelf fixed-wing ESCs implement; some are sensible (e.g. some period of PWM < ~1100µs required to arm), others are less so (e.g. period < 1100µs, period > 1900µs, period < 1100µs).

It's definitely not safe for us to start sending a signal until we know what is connected to each PWM port, and it would be very unsafe for us to send a signal that caused the ESC to arm when the controller is not armed, if the controller's default output state is such that on controller arming the PWM output jumps to something unsafe.

Given that users have to pick from a subset of ESCs already, it makes sense to pick ones that do something sensible when the PWM signal is turned off.

Consider e.g. the following setup scenario:

• power on, PWM outputs are high and idle
• enable PWM mode outputs go low, remain idle
• mixer loads, sets default 990µs output pulse for outputs connected to an ESC
• all ESCs are now armed, and will remain armed until battery power is removed

Now consider for example:

• controller is initialised, loads e.g. stale configuration setting servo offset of 300µs for a channel now connected to an ESC
• controller is armed, PWM output for the ESC jumps to 1290µs (30%) causing the motor to start

In this scenario, if we had not armed the ESC in the idle/non-armed state, there would be no risk. Instead, we have introduced two independent "zero" values with no mechanism for reconciliation.

It seems clear from this that "armed" needs to be a function of the controller, rather than of the actuator and mixing subsystems, or alternatively if we want to move the actuator setup that's currently bundled into the R/C input side out into the mixer, that it could be implemented on the input side of the mixing framework.

[LorenzMeier]

Points taken, but there still seems to be a very clean way out here:

• The mixer output for an input value of 0 is a safe disarming value, as it is inherently the neutral / zero position of the system. It also ensures that if a mixer has an offset, the arming value is including that offset (so it ensures one-value-while-disarmed, which rules out something like the last example from happening)
• If the system is transitioning from disarmed to armed and a controller outputs a non-zero actuator value, we actually want the motors to spin, because nothing else should be interfering with the arming / safety state machine once the system is armed
• The mixer config is available at last after EEPROM readout, so presumably within the time frame before ESCs time out.
• The less sensible ESCs requiring full throttle before they arm are the problem of their respective owners, there is never going to be a safe way of arming those

What could potentially else go wrong with outputting the value the mixer produces with zero inputs at startup?

[zul00]

maybe you can relate this case with my question in this link

[LorenzMeier]

Fixed.