Tradheli users,
I just determined that changes to the handling of the motor interlock in ArduCopter 4.0 could affect the RC passthrough mode of the RSC. This problem could result in the motor shutting down in flight however it would happen at low PWM settings.
Instead of enabling motor interlock (throttle hold off) at 10 PWM above RC8_MIN (logic of AC 3.6 and earlier), It would enable it above 1200 PWM. So if your settings while the motor is running take the RC in PWM below 1200 then it would shutdown your engine. So be careful and check your settings. I hope to get a PR in within the next few days.
Tradheli users,
AC 4.0.1 rc2 was released for beta testing as indicated Here. This contains the fix for the subject issue. I’ve functionally checked this but any user testing would be great. Remember that if you are using the RC passthrough for the RSC mode then you must set your transmitter failsafe to hold last value otherwise if the aircraft loses transmitter signal the aircraft could crash.
Let me clarify. The receiver must be set up to hold last value on whichever channel is the motor interlock RC channel. This is only if you are using the RC passthrough rotor speed control mode. All other modes can be setup with any of the failsafe methods described here
Bill,
Sorry I forgot to reply to your warning above, but here now my experience few weeks ago.
Yes, I am using in my two Helis the Mode 1 = RC Pass-through for my own reason.
Before I changed the Fail Safe in my FrSky receivers in both Helis I tested on the bench if the FC would disarm in flight. And I can confirm it did happen when the receiver were setup FS = No Pulse.
The test was not done by switching the TX-Horus off. When the Helis were running on the bench without blades in Stabilize mode I moved the Horus very close to the RX antennas, nearly touching. This always will cause a FS in the flight-controller as No signal. I than move away and the signal comes back. Occasionally the FC in Fail Save would disarm. In reality the Heli would crash if the pilot is not doing a Auto-rotation landing.
My next Test was with the RX-Fail Safe set to FS- Hold. With both Helis I did many repeated test. Not ones did any of the 2 FC in the Helis disarm on its own. It proves your software in Mode 1 is working when the receiver FS = Hold.
Thank you Bill for your work and the warning for those who use Mode 1.
This is a different issue than having no failsafe set at all. And it indicates a problem in the 4.0 software.
With No Pulses set the failsafe bit should be set on SBus. As far as the flight controller is concerned this is the same as setting to hold last value. When the SBus failsafe bit is set the software should do that.
The problem occurs on re-bind of the signal when there is a frame that is late. Sometimes this can result in SBus zero, pwm value of 874 for a few milliseconds, which can cause ANY channel to go to minimum.
In the 3.6 version of the software, at least, there was a patch done in two commits to ignore out-of-bounds pwm values for this very reason
The Aux Switch functions (formerly switches.cpp in the main code) was moved to the RC_Channel object in 4.0. Your test indicates there is still a problem with this in 4.0. The same problem, in fact, that existed in 3.6 before it was patched.
I did one test with the TR600 before I upgraded the FW from 3.6.11 to 4.0.3 and RX: No pulse and it disarmed ones on the bench. I did get a shock because I had done a mission weeks earlier where the Heli was away quite a distance. Must not had lost the signal. It is a shame that I have not saved my log files. Usually I clear my log files when no event happened.
But now with FW 4.0.3 I have not done any mission with RX: Hold. Because of a total Lock Down here in NZ I’m not sure when I can test in real again and not on the bench.
It could be related to improper handling of the SBus failsafe bit too. Which would be in the HAL. I fly NuttX builds, have not moved to ChibiOS, the two have different HAL libraries. There was confusion in 3.6 due to running ChibiOS on the FMU but PX4 on the I/O. And then a switch was made to ChibiOS on the I/O but I don’t remember where - I think at 3.6.10.
I have jotted it down on my list of stuff to look at in 4.0.