Stopped responding to RC inputs and drifted away

Hello Everyone,

I’m experiencing a strange issue with my 13-inch FPV quadcopter and could use some help troubleshooting. Here’s what happened:

  • Copter specs:
    • Propellers: 13 inch
    • Motors: 4215 350 KV
    • Firmware: 4.5.7
    • Airframe: Quadcopter
    • Battery: 6S 8000mAh

I armed the copter using the arming switch and raised the throttle to gain height of around 1.5m. After that, I stopped giving any RC input, but the copter slowly started gaining height and drifting towards the right. I tried giving it opposite roll input, but the copter did not respond to any RC commands.

There were no error prompts or messages in the logs, and everything appeared normal in terms of the flight controller’s performance. To prevent the copter from flying away, I triggered the emergency motor stop.

I’ve flown this system many times with no issues, and this was the first time I encountered such a problem. Given the flight logs and the lack of error messages, I’m at a bit of a loss as to what might have caused this issue.

I’ve attached the Flight Logs. Any insights or suggestions would be greatly appreciated!

Thanks in advance for your help!

Just had a very quick look at the log.
In the PSCE and PSCN section the Target and desired velocities diverge.
I think it may be a compass problem. Perhaps not calibrated or not the correct orientation?

I had almost exactly the same issue last week.

@Quadzilla
Hi, how did u resolve the issue, what was your finding?
Thanks in advance

I have not had time to look at it. I am assuming it was a bad RC cable shorting or my 915 is bleeding making interference.

Hi @1afridi,

It looks like many of the arming checks have been disabled. That’s generally a bad idea because each of those tests was added in response to a user issue and having them enabled means you’re more likely to be warned before takeoff instead of finding out through a bad flight.

In any case, I think the issue is that ANGLE_MAX has been set to 60 centi-degrees. That probably should be 6000 (60 degrees).

BTW AP is moving to using the standard scaling where we can (e.g. degrees instead of centi-degrees) and that work has already begun but won’t appear until probably AP-4.8.

3 Likes

Hi @rmackay9,
Thanks to you, it works like a charm now. Yesterday I did testing at 45 degrees in the previous flights. Then when I opened the angle to 60 degrees, I wrote 60 in both loit_ang_max and angle_max(takes input in cdeg). An honest error on my behalf.
Thanks again for you help.

2 Likes

I think it was mostly user hardware error.

What goes up sometimes never come down unless you use a tree trimmer.

Please PM me for Bin file.

1 Like

Hi @rmackay9,
Sorry to bother you again, but I’m encountering another issue with my FPV UAV. I was testing the UAV today, and for the first two flights, everything was normal with no issues. However, when I swapped the batteries and attempted the third flight, I got the internal error:
0x4000 I:215 spi_fail.

I’ve read through several threads discussing this issue. In one thread, @andyp1per suggests that this could be due to faulty IMUs. However, my SpeedyBee F405 only has one IMU.

Could you suggest another way to resolve this, or is swapping the FC the only solution?

Thanks for your help!

Is this now a permanent Error or was it just a onetime error.
Was the swapped batterie fully charged?
What you have to do to swapp batteries. Is it possible that you touched the FC.
Any unprotected ESD can kill parts on the FC.

It is comes sometimes and goes away. It is repeatable at random instances
Yes the battery was fully charged
No I have not touched the FC while swapping batteries. I realize the ESD can cause a lot of damage but I have not touched the FC or any electronic comp directly.

According to your previous post, was this the first time this has happened, or has the error occurred before?
If it’s happening more frequently now, is it always related to a battery change?
Did the FC or the drone crash?
Such sporadic errors can be caused by hardware, such as a bad solder joint, a hair crack, etc.
Using the drone in such a situation is very risky.

1 Like

Hi, I ran your logs through DeepTrace. Attached is the analysis
00000093_report.pdf (52.6 KB)
output.

Even a glance through that “analysis” shows some significant hallucination. I wouldn’t put much stock in that report.

Surprisingly, it did pick up on the angle max inconsistency already identified earlier in the topic.

3 Likes

A tool that checks the parameter values against default. Wow!

Worse, as it also recommends enabling ALL logging values.

1 Like

Thanks everyone for the feedback, I really really appreciate you taking the time to look through it.

@dkemxr you’re right, at this stage it’s not very sophisticated, but I’m working on improving it. I’d love to hear what else you’d like to see in the tool, any checks or insights that would make it more useful?

@Yuri_Rage Yeah, that’s definitely something to refine. If you have time, I’d be interested in hearing what kind of analysis you’d expect from a smarter parameter reviewer, what would a “good” analysis look like to you?

I’m working on refining it to help the Ardupilot community pinpoint issues much faster. The goal is to make the tool genuinely helpful, and your input is highly appreciated.

Thanks

My unpopular opinion is that LLMs have no place in aviation (manned or unmanned). The black box reasoning and possible hallucinations that are indistinguishable from reality are extremely dangerous. This is the area of expert systems with predefined, explicit rules, and the ability to explain the reasoning step by step.

1 Like

I agree, and I’m not so sure this opinion is very unpopular.

I think the premise is flawed as it applies to default parameters. In fact a Tool that took the opposite approach would be more useful. Detect Default Parameter values for; Rate PID’s, Vertical Acceleration Controller gains and Motor Ranges and produce a Warning if they are present. We see this every day.
Here is an example from today: Default Parameters