FPV wing crash 9.0.1 in RTH Track Back

[jwmjwm2025]

I just had my chupito fpv wing crash 2 days ago in RTH Nav mode track back using 9.0.1 on a TBS Lucid Wing AIO 2-6S AIO. This was the second flight of this wing. First flight was successful in 8.0.1. Compared to the first flight it seemed that the FC was struggling: difficult to keep wings level and under control in Horizon mode after auto launch. In fact did not take my corrective inputs and was out of control after auto launch sequence ended. Saved it by hitting RTH, but even in that mode it was struggling flying at a strange roll angle entire flight. I also noted on OSD playback that it gave a system message of Emergency Landing for a few seconds while it was in RTH.

Note: i check out fc operation day before each flight outing: control surfaces were perfectly centered, servos at 1500 and pitch/roll indications at zero on outputs tab at home on the bench and model sitting on bench level and correct connected to configurator. Control surface throws were good and moving in correct direction upon stick inputs and wing movement in stabilized flight modes.

No physical changes to wing after first flight. Some FC setting changes: 0. updated firmware from 8.0.1 to 9.0 to 9.0.1 kept same 9.0 CLI which was from the 8.0.1 re-enter and save off. 1. RTH- enabled track back. 2. changed altitude in rth and loiter settings. 3. changed from angle to horizon mode for flight mode after auto launch sequence.

Bottom line: wing returned overhead and then FC essentially acted like it turned off-- still had FPV in goggles all the way to impact. Last minute of flight progression as follows: OSD froze no longer updating, OSD then went away, wing would not take any control inputs and dove into ground about 20 feet from launch point. This wasn't a battery issue you can see the 6S had plenty of power in OSD video.

Post flight inspection: wings intact and no damage to elevons/servos/control linkages so this wasnt some sort of physical failure causing it to fly like this. Port wing control surface perfectly centered, Starboard wing elevon slightly up 1-2mm. (after testing on bench it went back to neutral when battery reconnected.)

No wire disconnects noted on FC except those caused by impact- female VTX cable conntector knocked off of O4 lite VTX board, GPS detatched from its end of cable as it was attached to hatch that broke away on impact.

After reattaching all electronics and powering with battery (except VTX-- i have to solder conector or wires back on the board to test it) all worked normally on bench including motor/esc.

Attached: CLI, black box log file, vid links

https://drive.google.com/open?id=1h4N-VmIfNup4hptlcmzjdl_Ljjn6riUv&usp=drive_fs
See files: DJI_0001 (2) and Chupito Maiden

LOG00008.TXT

INAV_9.0.0_cli_20260227_093044_Chupito.txt

LOG00006.TXT

LOG00007.TXT

INAV_8.0.1_cli_20260116_101720_Chupito.txt

[Jetrell]

There appears to be two issues you have here.
Since you don't have a mag. The only other thing that could cause such an extreme divergence between COG heading and IMU heading. Is if the IMU is picking up severe vibrations from the motor or prop.
And the fact the greatest effect of this was seen when you where at higher throttle after launch.. Then it got better after the throttle was lowered, when you entered RTH... This would seem to backup that idea.
The filtered gyro data doesn't appear too bad. But you weren't logging raw gyro data. So its hard to know what it would actually be like. And what noise might have been making it through to upset the AHRS.
That being the case, its more of a user setup issue.

But the lockup isn't.
I take it you read through the report from my FS Trackback lockup issue last year.. I think its ironic that in both cases the FC's locked-up around the first track marker out from home.
Both @breadoven and @stronnag ran some SITL and HITL tests of the code. But didn't find anything concerning RTH Trackback.
After looking over your log and diff. Nothing out of the ordinary stands out.. Meaning there must be an edge case that is somehow triggering this.

@breadoven Trackback was moved to it's own library by someone other than you. I wonder if something was changed or left out at that time ? I remember you saying to him at that time. "As long as it still works".
I certainly know it used to work very well. And as I said in my report back in August. That was the first time I had got around to using it again since those changes. And due to the lack of desire to needlessly trash another plane from multiple testing lockups of late. I haven't used RTH Trackback since.

I know @sensei-hacker and @daijoubu have fixes in place for a couple of H7 and F76 lockup issues. That seem to occurred under different situations... But as some of the other guys who have ran testing have also seen. It's far from easy to replicate these issues on the ground when you want them to happen.. And far from desirable to replicate in the air. Because the log just stops recording and provides no beneficial data.. Just a damaged aircraft.

[breadoven]

The only thing I can think of regarding the lockup is that when trackback finishes close to home it initializes normal RTH which then incorrectly restarts trackback which then immediately finishes reinitializing normal RTH again ... and you end up stuck in a loop that locks up the FC.

@sensei-hacker can qodo-code-review super bot be used to analyse the RTH trackback code to find issues that might cause a feedback loop ?

[stronnag]

The only thing I can think of regarding the lockup is that when trackback finishes close to home it initializes normal RTH which then incorrectly restarts trackback which then immediately finishes reinitializing normal RTH again ... and you end up stuck in a loop that locks up the FC.

However, RTH went seriously wrong from the moment it was actived (RTH track in yellow):

Good RTH from 8.1

Crazy RTH from 9.0

[breadoven]

The GPS eph/epv collapsed shortly before it all went wrong even though they were fine at take off. Plus the AHI went haywire which would explain the poor RTH attempt up to the point both position and altitude became invalid leading to the emergency landing. But even that didn't work well because the Baro wasn't being used due I think to a mismatch with the seriously inaccurate GPS altitude. Is there a source of interference in that area ?

However, the log was using 1/2 sample rate which might have been helpful because it shows that the target positions X and Y went to 0 in the last 2 frames before it cut off. That doesn't fit with what would be expected if it had switched from Trackback to a normal RTH. And this happened when the last Trackback point had been reached so it seems it's trying to set a bogus position which causes a problem. I need to double check that Trackback refactor to see that it didn't change the logic somehow ... or maybe it was never right in the first place. Strange it can't be replicated on HITL though.

[breadoven]

OK I think I can see a mistake which goes back to the original code before the refactor ... so my bad. Looks like this problem can happen if you don't set more than the max of 50 track points so the trackback point array doesn't wrap around. In that case when you reach the last trackback point it will decrement to the next expected point which would be for array index -1 which isn't possible. Not sure why that hasn't caused more problems before, maybe because most flights set more than 50 trackback points which triggers the array wraparound which negates the problem. Need to test and see if this can be replicated.

[jwmjwm2025]

Thanks for your inputs everyone.

I'll address some questions that have come up in the discussion and have a couple comments/observations:

Regarding wing setup, this is a standard Chupito electronics installation using the FC made for the model. That being said, of course, having an AIO FC with ESC board right underneath the FC board and then encased in plastic, well, that's inviting problems such as EMI and heat (which you do see as an issue because on both flights the wing was launched with the FC temperature shutdown warning in the OSD which may have some effect on the intial headers at time of launch?). In addition, this wing has an aprox 6 in glass fiber motor mount cross-shaped spar that slips throught the rear of model and is locked in place by one of the two glass fiber wing spars and a vertical stabilizer stiffening glass fiber spar. Glueing motor mount in is optional, which I did not. Though a tight press in fit, un-glued this spar could probably transmit and amplify motor/prop vibrations through the wing spar and throughout the airframe with out glue holding the mount to the soft, resilient foam for a dampening effect.

Regarding interference sources in area: I didn't see any antenna masts or transmission towers within a cursory view of the area. I had already looked at several places to fly that morning and passed on a couple of them due to having cell towers close by.

On my drive home pondering the crash, I wondered if possibly the RTH Track Back had been initiated inside of the distance where track back was supposed to end and confused the FC. I believe this distance is a setting in Configurator. And I really was puzzled and bothered by how poorly it flew with the continually slanted AH compared to the first flight, especially how I could not control it when it came out of AL and went into Horizon Mode.

Regarding Logs and ways to pinpoint noise/vibration issues: Log 7 is the continuation of Log 6 flight, in which I accidentally disarmed and quickly rearmed in flight. You may be able to see something there to isolate causes/sources of interference/vibration because it was basically a glider flight with motor not coming back on after rearm. If helpful (let me know) I can also upload logs 1-5 which are pre-maiden bench checkout run logs, ie is everything working right with full throttle motor with prop running (such as do control inputs work, is the gyro moving control surfaces, did the AL sequence go as expected etc.) , and a leaf blower blasting into fuselage for cooling. A couple of the first short Logs are probably with no prop attached.

If if fly this again I will glue motor mount in, use a couple rubber isolation pads (heat resistant) between motor and mount, EMI tape the motor wires. I will explore taking the AIO FC/ESC out of the plastic case and figure out how to mount it. The fuselage is in four pieces and top hatch is split in two. But the soft tough foam is very resilient and does not disinigrate at the breaks like styrofoam so it pieces back together well. I don't know about the O4 lite VTX board yet, though it does power up and show up on the DJI flash program. I'm having a hella hardtime with soldering the tiny pads at the VTX connector. I will probably go back to 8.0.1 and load my pre-maiden CLI, too, haha!