I am having trouble using the manual override on my Pixhawk. I expected that if channel 8 was >1750us then the RC controller would have control and the autopilot’s outputs would be overridden. This is the behaviour we used to get on the APM 1.
I tested with APM:Plane 2.78b. I used an S.Bus input and channel 8 was my flight mode switch. Toggling the switch enables me to flick between manual, FBW-A and auto (1950us, 1500us, 1100us).
- In FBW-A I can rotate the pixhawk and the servos move as expected- showing that the autopilot has control
- When I switch into manual, I have manual control, rotating the pixhawk does not move the servos - as expected
- Remaining in manual mode (1950us on channel 8), I click change mode on the mission planner into FBW-A. Now rotating the pixhawk moves the servos- which means that the autopilot’s output is being sent to the servos, even though my flight mode switch is in the override position.
Please could someone tell me if I have misunderstood how to use the manual override, or is there a bug in the firmware.
It works on a transition, not a ‘steady state’. You need to toggle out and back into manual mode to effect a mode change.
Thanks for your answer. I understand that toggling the flight mode switch controls just the transition between flight modes, rather than holding it within a particular one. Actually the flight mode that the autopilot (main processor) has activated is not of great importance here- rather I just used it as a way of demonstrating whether servo commands were coming from the main FMU chip or directly from the receiver.
My requirement for the flight mode switch in the high position is not to simply move into manual, but rather to prohibit the code running on the FMU to interfere with the commands being sent from my transmitter. Even whilst in flight mode manual, my test indicates that software on the FMU is capable of interfering with my transmitter inputs / rx outputs.
I thought that the co-processor / IO chip would route signals directly from the receiver to the servos when the flight mode switch sends a high signal. Specifically I am looking at the product feature: “14 PWM/servo outputs (8 with failsafe and manual override, 6 auxiliary, high-power compatible)“.
If this feature is not possible then I will have to purchase a couple of these: store.3drobotics.com/products/failsafe-mux I used these with the APM2, but wiring gets pretty messy when you have 7 channels on failsafe.
Perhaps this explains the issue slightly better? Please do let me know if a manual override feature that functions similarly to the failsafe-mux boards is or could be available for APM:Plane on the Pixhawk. If it has yet to be implemented, perhaps someone could point me towards the relevant code that I’d need to modify?
I’ve been digging around the code a bit and I’m not misunderstanding what should be going on here. There appears to be a bug.
I logged on to NSH via an FTDI cable and when I type
it tells me that the manual override flag is not enabled. On planes we need
to be enabled. I tried modifying line 290 of PX4Firmware\src\modules\px4iofirmware\controls.c so that it didn’t check for this flag. This helped a little bit as now when I flick my flight mode switch (which it turns out MUST be on channel 5) into the low!! position then the px4io status command tells me that PX4IO_P_STATUS_FLAGS_OVERRIDE has been set. Unfortunately manual passthrough is still not occuring. My guess is it is something to do with the PX4IO_P_STATUS_FLAGS_RAW_PWM flag, but I don’t know yet. I’ll keep digging.
If someone knows the answer to this please let me know!!
With the current APM code on Pixhawk you can’t enable manual bypass of the FMU. As Bill has pointed out there is a flag for this in the px4io code, but just enabling that flag won’t work as it assumes a mixer setup that the PX4 native stack uses but APM doesn’t.
The key difference between the PX4 native stack and the APM stack on Pixhawk is that the APM stack works with raw PWM values in the FMU. The PX4 native stack works with scaled values (all inputs are scaled to -1…1) and users setup a mixer file on the SD card (or builtin to the firmware) that provides the mapping for their aircraft. That means that when the FMU is offline the IO board can continue to mix as it knows how to do mixing.
We will add support for manual override in the future in APM, but for now if you want it you need to use an external manual override board. I’ve used this one previously with an APM2.
The main hold up with adding this feature for APM is handling the more complex mixing setups like V-tail, elevons, flaperons etc. We need some code to map the APM mixing parameters to an equivalent set of PX4 IO mixing rules.
Many thanks for your reply, this now makes sense to me.
I’ve gone through the mixer code and played around a bit with loading mixers from the NSH terminal and I’m starting to work out how I might be able to modify the code to get this to work. For now I think I’m going to try and get just a straight pass-through working, i.e. no actual mixing.
I’ve been modifying the control laws a bit and having this safety feature gives a bit more piece of mind. I recently installed two multiplexers similar to yours on my APM2, which is great, but it gets awfully messy with all the wires.
It’s (hopefully) unlikely that I’ll need to bypass the FMU in the field, but it could be possible. For example when I was using python scripting to do some step input tests on the elevator I had no way to regain control of the elevator if the telemetry link went down. I noticed this on the ground so modified the code before flying. When switching into manual (>=1750) all the overrides get zeroed. I can share this relatively simple patch with you if you want it.