I finally had time to burn through batteries watching this happen. No wonder the Solo ESCs were going bonkers and I was crashing left and right before the Green Cube!! The throttle is output is cutting off when switching from RTL to Guided. It doesn’t happen when switching from any other mode to guided that I have found. Finally these logs show I haven’t been totally losing my mind the last two weeks! This happens running 3.5 or running 3.6dev. This happens with both the stock PH2 and the 2.1. Two log files below.
This is 100% reproducible on the bench too. Just sitting on my table with no props on, I can make it happen under the same circumstances. Invoke Arducopter RTL mode. Companion computer takes over in guided mode. motor output goes to idle for a split second.
RTL begins. It will start climbing as normal about 5 feet or so. Switches to guided because that’s what a Solo does. Motors cut off for a split second. Motors come back on.
I tried this on the bench with my normal stock solo, running the 3DR solo firmware. It appeared to be happening but much more subtle. Almost couldn’t tell, and sometimes you can’t tell. I would wager money the slew rate on the stock solo is masking it!
Don’t know if it’s at all related, but I’m working on a similar problem.
AC3.3 for TradHeli. When flying in Auto, with the Failsafe_Throttle set to “Continue if in Auto” and it is flying in auto, the motor output switches off briefly when the RC Rx comes in and out of range. It seems that this only happens if the Telemetry is also lost. I haven’t been able to isolate the condition, I don’t know if it’s while flying in Auto only, or what.
Just several people pointed me at your issue as maybe being related.
@Rob_Lefebvre, last night I traced this problem down to the Solo’s smart shot execution. The motors are going to minimum… because that’s exactly what the the companion computer’s smart shot code erroneously told it to do. It turns out to be nothing at all related to ArduCopter or the changing of modes.
So, the problem I’m tracking, appears to be an SBUS parsing problem. Not sure if it’s a problem in the FrSky X6R, or if it’s i the Ardupilot SBUS parsing code. And it may or may not be fixed in 3.4/3.5 already. I’m still using 3.3.
I have a patch to protect for it now, but I still don’t fully understand the root cause.
This is a problem with AC_PosControl::get_stopping_point_z when transitioning from modes that use the vertical velocity feedforward to modes that do not.
