Good morning, today I had an accident with version 3.5 of ardupilot, yesterday I made a perfect 20 minute flight using loiter.
The crash happened when I was using alt hold flight mode. He fired left, I quickly switched to stablized, and managed to control but he hit a tree lightly, I had too little data, but I think it’s a very serious bug.
Follows flight logs for voice apprehension.
Attached .log and .bin
certainly not a bug until proven otherwise, usually people feel shame after saying stuff like that before understanding what happened.
edit: the arr is fine, I am just on a new device… will take a look
What the log tell:
you are in a lazy hover, going nowhere fast, good GPS fix, attitude does not indicate any speed. suddently, you have FULL left input on the RC roll stick, and switch to Stabilize , speed starts to build up, then you center the stick, and not equally fast, make a FULL input to the other side. , then enter Loiter…
there is nothing that indicate any speed before commanded, but the full roll input could be a defective potentiometer or otherwise an RC-equipment failure. - or just crazy input 
According to the log, nothing happened until you switched to stabilize. Then simultaneously RC1 channel went to 900 (full roll).
I don’t see any “firing” before switching to stabilize. (neither GPS or POS lat/lon underpins it).
During alt-hold, it moved 5 meters, pretty much in sync with your stick movements…
(I see Andre was faster 
)
One thing, in altHold you control attitude the same way as in stabilize (except altitude) so correcting sudden horizontal movement by switching to stabilize does not changes anything…
I understand, but this movement on the left was not done by me, the radio is healthy and the communication is by uhf everything with FS configured, the correction in loiter after the shot was made by me in order to regain control, without success already in Fall, rebuild the drone is applied version 3.4.6 and everything is working very well, I insist on a possible failure in alt hold he fired left without some eating my, hug and grateful for the attention
This equipment had more than 25 hours of flight in version 3.4.6 without any error, I am not inexperienced, soon I am flying again and comes with the downgrade
What RC system are you using ? How it is connected to the fc ? (PWM, Sbus ?)
Look at the RCIn when you? switched to stab, RC8 also switched to full, and RC1 to minimum… however other channels remained as they were.
Did you switched to stabilize ? Or you switched to loiter… ?
DId you check your RC failsafe recently ?
To using 8ppm channel 8 is rtl configured as failsafe, after rebuilding I tried to simulate what happened and everything went well, the first time I fired the althold in version 3.5 it fired up there brought stablize again should find this in the log , Grateful for the attention.
I used stablize for takeoff, I activated althold there he shoots the left and active loiter to try to recover there he collides … what happened but in no time did he command to derive the left, failsafe activates rtl nothing else the drone was within 10 meters From me on uhf system very tested and trusted by me.
Samuel I guess you have a problem with your radio.
The copter reacted to Rc1 input , the fact that you did not touch the stick of Rc1 confirm that theory.
Recently I have a very strange behavior with Ardupiane 3.7.1 , I do not know if it is related to your problem but it was really, really weird .
https://discuss.ardupilot.org/t/left-aileron-do-not-respond-in-fbwa-mode/18640
The most weird thing was that looking at Mission Planner radio calibration page everything was as usual but the problem remains, moving the throttle makes moving the ailerons.
I guess that the output from Pixracer was somehow corrupted.
Everything return to normal after a new radio calibration.
I used this same radio without yesterday’s day to drive racer, after the downgrade to version 3.4.5 there is no problem using the same radio, I see a lot of resistance in crediting without problem, use this pixhawk a long time and this “failure” So it happened in version 3.5 as soon as I activated the first time in alltholdective a high firing.
I insist on saying that there is no hardware failure for the server today flies perfectly with the same configuration, but with older firmware.
My goal is to alert and help, and this behavior I saw does not match the pixhawk.
The logs disagree. They logs clearly show the control signal coming from the receiver commanded the movement. And the copter did exactly what the receiver was telling it to do. I believe you have your receiver configured incorrectly and possibly your transmitter configured incorrectly.
You mentioned the RC used UHF, please learn about about how a PPM stream looks (that’s what those UHF radios get from your TX), then you need to understand it is “decoded” (very time critical) , then retransmitted in an efficient way over UHF (some systems send only changes, and skip smaller changes), most often without very good checksums to reduce transmission time, then the RX outputs as PPM again.
I would not bet it was not a software glitch somewhere.
Unless you have a bidirectional telemetry system like Grauper HoTT , where ther radio have full logs of your input, transmission conditions (recording S/N of the channels used in the FHSS) , then you get to know how many frames the RX recieved since last report, if there were drops or ad frames , their strenght/quality and much more… unless you have that kind of logging, it’s a very off thing to blame on AP,
BTW: typical PPM decoding error would not affect only one channel. - never. (and not lost that long) - but a bad potentiometer, or channel priority/update logic like in UHF, may do so.
