b) put a switch on the RC receiver signal line to toggle between the actual RC receiver and my surrogate micro-controller “receiver.” (This I don’t get)
e) switch all of their signal lines to another source (only downside to this is: I have to physically connect stuff; e.g., need connectors for it.
With your proposed approach, every peripheral device (servo, relay, etc) needs two connections: one to the autopilot, and one to the microcontroller. To completely separate the signal paths (as you should), you’d need a bank of toggle switches or a large multi-throw switch to transfer control.
I’d rather use a single DPDT switch to toggle the autopilot’s RC receiver input lines between an RC receiver and the microcontroller for manual control and leave all of the peripherals connected to and operated by the autopilot via RC signaling.
c) keep the “flight mode” channel switched to MANUAL (I assume there is a channel for this, but what does it do; I am also not clear how many channels I even need; do I have enough with the gear I have got)
ArduPilot vehicles are switchable between many different control modes (colloquially called “flight modes”). The active mode is selectable via GCS messaging (Mission Planner) or, more conveniently, an RC transmitter using a multi-position switch assigned via the MODE_CH parameter.
MANUAL mode is essentially RC passthrough for all channels, which is the mode you’d use for ride-on manual control and/or for unassisted RC control via the transmitter (no course/speed assistance as in ACRO or STEERING modes). The microcontroller’s RC output for that channel would be fixed to MANUAL mode to ensure constant, unwavering RC passthrough with no chance to accidentally select an automated mode while you are onboard.
d) write code for servo drivers (this is really simple, essentially PWM)
Simple to do poorly. Harder to do well, since many microcontrollers have limited timers for use with precise PPM signaling (Arduino, in particular). You can use a servo driver board to abstract that away, but that often results in a loss of resolution.
Much easier to read encoder positions and output a single serial stream of channel states. Most RC protocols are just some flavor of serial communication. ExpressLRS and Crossfire share a common serial protocol that shouldn’t be hard to implement. SBus uses an inverted serial protocol that is frustrating to replicate on certain microcontrollers, so I’d not use that one.
So what about all the safety logic; e.g., if this switch is ON|OFF, that function does work or not? Would this be programmed on the flight controller? What language? LUA?
Probably a combination of physical switches (emergency stop that physically kills power, for example) and microcontroller code. I can envision a microcontroller-side failsafe where any anomaly (like unexpected input range or signal loss) would slew the motion control servos to neutral at a rate that wouldn’t eject you from a sudden stop. There could also be logic to disarm the autopilot (which zeroes and disables the throttle outputs) if the brake is applied, the control arms trigger the neutral switches, or the seat switch is open.
I’d keep most, if not all of the manual control logic on the microcontroller. There may be a few odds and ends where Lua scripting on the autopilot could help, but nothing comes to mind right away.
E.g., those who give me a helping hand, do not need to consider my ‘manual’ controller for any automation work (as long as I ensure the required pass-throughs have been catered for).
No one would have to care. The autopilot and firmware would be unmolested in either approach. With my suggested approach, you’d just have an extra set of RC receiver lines that wouldn’t matter in the least to anyone attempting to help solve an ArduPilot related issue.
if someone tells me the the flight controller is not at risk of failing
I have experienced ZERO autopilot failures that weren’t directly my fault for doing something stupid like shorting a pin with a misconnected ground/power wire. Those failures were immediate, embarrassing, and not something that would happen during routine use. So I have faith that routing the signals through the autopilot solves more problems than it creates.
Lastly, for those reading who may be scratching their skulls at the discussion of manual/automated control, please reference post 6 by Randy on this topic.