removed saturation from the rosflight_io node

[JMoore5353]

The saturation should happen in either the firmware or before the user sends commands to the firmware. This was also raising an issue as I was implementing controls that send passthrough commands to the mixer that are on a different scale than from [-1,1].

This pull request removes saturation from the rosflight_io node, making it the user's responsibility to saturate their input. Note that the mixer also does some saturation when composing motor and servo commands.

[bsutherland333]

I agree that saturation in rosflight_io doesn't make sense, but I think we do want saturation somewhere in the rosflight side of things, where we don't assume that the user is never going to attempt to send infeasible inputs that could damage the hardware. Does the firmware have saturation? Keeping the saturation inside the firmware makes the most sense to me.

[JMoore5353]

@bsutherland333 The firmware does saturate the inputs when it goes to write motor commands to the motors/servos. In the case of a motor, it saturates the command between 0 and 1. In the case of a servo, from -1 to 1. So the saturation limits in the firmware (right before writing PWM commands to the motors/servos) match exactly the saturation limits in rosflight_io.

When we remove the saturation from rosflight_io, the difference will be that the saturation happens after computing mixing outputs instead of before. Note that this doesn't solve the problem of avoiding damaging the hardware, but the current saturation limits in rosflight_io also don't solve that problem.

What are the hardware limits you are thinking about? What are your thoughts on how we could implement something to protect those hardware limits?

[bsutherland333]

@JMoore5353 I don't think this would be an issue for our current airframes, but if we were ever controlling hardware where it would be possible to command something outside of its safe working range then we would want to saturate the command to avoid commands ever leaving that range. varmint_h7 would also probably saturate this, but I think it would be good to have at least one check somewhere in the standard software stack. At the very least, this would involve limiting PWM or command outputs to 1000-2000 or -1-1 or 0-1. We could also make this a parameter if a particular airframe needed tighter restrictions. But all this should happen after mixing, of course. We want this to be on the raw hardware commands itself, not xyz commands.