It was facing ENE actually. It was looking at me, so it was globally positioned a few meters west from me.
Last edited:
Fly-away and crash at 30mph...
- Thread starter Fracapouille
- Start date
Let me go back and review the data again. Do you have any photos from just before the crash?
I don't think there were many later pictures, this is one of the latest. There are none just before the crash.
IIRC there were the 4 last pictures thumbnails in the flight log?
As mentionned in the post, the picture was taken around 802s. The orientation (yaw) of the drone shouldn't change much during the main part of the flight...
IIRC there were the 4 last pictures thumbnails in the flight log?
As mentionned in the post, the picture was taken around 802s. The orientation (yaw) of the drone shouldn't change much during the main part of the flight...
Did you forget to attach an image? The txt flight log does not include images - you may have those separately on your mobile device.
The image I'm talking about is the one in post 25.
These 4 images are available when loading the txt file (attached in post #1) with Airdata UAV log reader:
"The following files were extracted from the log. The log contains only up to the last 4 photos/video thumbnails, in low-resolution."
OK - I think I have all the data I need now. It turns out that even when the FC does not have good enough GPS data to engage P-GPS mode, it is still logging what it has. For most of this flight the aircraft had 7 satellites, and was recording location in the DAT file. Extracting those and converting to KML gives the following track:
The end of the track is consistent with your reported crash site. North is up, and note that the aircraft was flying approximately NE at the time, but we can quantify that further by differentiating position with respect to time:
This is consistent with the track (of course) and shows that at impact the aircraft track (actual direction of travel) was 63.5° true. We can compare that to the pitch, roll and yaw data:
This shows that the aircraft was facing a heading of 37°, rolled right at nearly 30°, and pitched forwards at just under 20° - in other words flying right and forwards, consistent with the track of 63.5° and stick input of right aileron and forward stick.
So, unambiguously, the aircraft was flying as commanded, and these data show how it was flying to the right and still hit the cliff.
The end of the track is consistent with your reported crash site. North is up, and note that the aircraft was flying approximately NE at the time, but we can quantify that further by differentiating position with respect to time:
This is consistent with the track (of course) and shows that at impact the aircraft track (actual direction of travel) was 63.5° true. We can compare that to the pitch, roll and yaw data:
This shows that the aircraft was facing a heading of 37°, rolled right at nearly 30°, and pitched forwards at just under 20° - in other words flying right and forwards, consistent with the track of 63.5° and stick input of right aileron and forward stick.
So, unambiguously, the aircraft was flying as commanded, and these data show how it was flying to the right and still hit the cliff.
Also, just for the record, the aircraft was travelling at approximately 30 mph at the time of the crash.
Thanks a lot sar104, you've been really helpful.
Could you please confirm that the vertices of the track are positions measured at a regular interval?
I would try to better understand the drone movements synched with the stick inputs...
Considering the interval is homogenuous, the picture below should indicate the position at roughly 827s, just before the "Great Manoeuvers". The sequence should last from 815s to 834s, time of crash.
I'm surprised by 3 things:
- Before this point, the drone has been moving quite fast (regarding the distance between the vertices) to the NW direction, during about 9 to 10 seconds. A heading change has occured between 825 and 827s: the heading changed from roughly 70° to roughly 37°. So with this initial heading of 70° (roughly ENE), to move quite fast in the NW direction, there should quite a strong input from 815s with sticks mainly on the left and a bit on the back. I don't find these inputs in post #5 were you report the log about stick inputs, so I'm still a bit confused...
- With a heading of 37° - so not very different of 45°, NE direction - the trajectory followed by the drone from 827s to the end (even with quite a lot of inertia) looks more orientated to the front than to the right side of the drone. Even if I was pushing a bit front, the main input was full right all along...
- The position of the drone at 827s seem a bit far away from where I was standing. To me, things started going bad with the drone nearby its 815s position, quite close to me, a position where one of the last pictures was taken. Maybe I'm wrong here, but this is how I remember the scene.
Please don't think I'm questioning your analysis, I just would like to understand...
Yes - the intervals are uniform (0.1 s).
I'm not quite sure what you are getting at here, but if you look at parts of the flight just before the end where you were applying no stick inputs, it is clear that there was a significant wind from the north, and it is clear that you repeatedly corrected for that with left aileron:
If you then look at the end of the flight, you can see that all the recorded changes in velocity are accounted for by stick inputs plus the acceleration south due to wind:
I can't help you with that one - the GPS data, while not good enough for P-GPS mode, are very smooth and I would estimate that they are good to a few meters at worst.
So the lesson here is that you did appear to lose orientation and it caused pilot error into the crash point. Flying in ATTI is no joke and should be practiced extensively. If you fly an RC heli, or even better a 3D heli that can fly inverted, this will help a lot. Otherwise practice with the drone in a wide open area doing a lot of different things. It teaches you muscle memory to quickly realize when the orientation is not what you think. Definitely something to look into! Sorry for the crashed drone though.
Well, I've gone further in the analysis, and it shows clearly that there is something going wrong with the drone, and nothing I could do about as a pilot.So the lesson here is that you did appear to lose orientation and it caused pilot error into the crash point. Flying in ATTI is no joke and should be practiced extensively. If you fly an RC heli, or even better a 3D heli that can fly inverted, this will help a lot. Otherwise practice with the drone in a wide open area doing a lot of different things. It teaches you muscle memory to quickly realize when the orientation is not what you think. Definitely something to look into! Sorry for the crashed drone though.
I'll share that ASAP, it's been quite a tough work, so I still need a few hours (days) to make it available.
That’s all good- would it be a huge problem if it was operator error? We ALL make mistakes.
The data from the drone paints a very clear picture of what happened. All data from the drone lines up. The data doesn't lie. I'm curious what more there is to analyze?
OK, here is what I got from overlaying the stick inputs (with their strength) on the path followed by the drone, every second (gif delay between frames also 1s, so the movements are synched what happened "real time").
It records the movements during 60s before the crash.
Here is what I understand from this animation (debatable, of course). As for time references, I'm refering to vertex numbers on the right panel. I'm sorry about the bad resolution, but you should manage to get a glimpse to tie it with a position. There is a 10 marks spread between 2 screenshots.
- sar 104 seems right about some hovering in the south direction: as you can see from 7153 on, without any shift inputs, the drone tends to brake from its upwards orientated direction and begin to hover south. I'm quite doubtful about the wind beeing the reason though, as there wasn't a single breeze that day. Anyway, a little hovering is nothing to worry about and it could be easily compensated.
- After a 2 seconds medium input in the east direction at the 7304 mark, and no inputs after that, I'm quite surprised that the drone has been keeping accelerating in the east direction around the 7344 mark. A single 1s input in the opposite direction managed to stop its movement though, as you can see at the 7364 mark.
- Then there is a medium input in the NW direction around the 7384 mark, mostly to end a slow drift. From that moment on, the drone began moving NW, very fast. This is the phase I can't explain, and where I felt I was loosing the drone. From that mark to 7485, where the drone starts drifting east - so for 10 seconds - I can't see any relation between the shift inputs and the drone movements (except one short mistake at the 7455 mark, it last less than 1s...). I don't understand why it kept on this general track, why its speed remained so fast, with strong inputs on a different or opposite direction. A 1s input had been previously sufficient to make it brake to a hold... If there had been some wind - and, I repeat it's very highly unlickely - it would have been drifting it southwards. Even with a sudden direction change, it would require very high winds to have such an effect...
- And at last, there is the part leading to the crash (from 7485). The drone was out of my sight then. The track is then quite consistent with the inputs, and this last move is my bad. If I could have seen it before the direction change, I would have dropped the shifts and it may have been possible to take the control back. I'm at fault for this part.
So, to sum up, I assume my responsability on the last seconds leading to the crash, and the data is consistent there.
However, I wouldn't have been in such a situation if the drone had not "flown away" to the NW. I know the ATTI mode can be touchy, that I was in a risky environment, and so on. Regardless of these considerations, do you confirm that 80m drift in 10s a normal, or acceptable behavior in ATTI mode? Did I miss something? Or maybe do you totally disagree with my interpretation of these data?
It records the movements during 60s before the crash.
Here is what I understand from this animation (debatable, of course). As for time references, I'm refering to vertex numbers on the right panel. I'm sorry about the bad resolution, but you should manage to get a glimpse to tie it with a position. There is a 10 marks spread between 2 screenshots.
- sar 104 seems right about some hovering in the south direction: as you can see from 7153 on, without any shift inputs, the drone tends to brake from its upwards orientated direction and begin to hover south. I'm quite doubtful about the wind beeing the reason though, as there wasn't a single breeze that day. Anyway, a little hovering is nothing to worry about and it could be easily compensated.
- After a 2 seconds medium input in the east direction at the 7304 mark, and no inputs after that, I'm quite surprised that the drone has been keeping accelerating in the east direction around the 7344 mark. A single 1s input in the opposite direction managed to stop its movement though, as you can see at the 7364 mark.
- Then there is a medium input in the NW direction around the 7384 mark, mostly to end a slow drift. From that moment on, the drone began moving NW, very fast. This is the phase I can't explain, and where I felt I was loosing the drone. From that mark to 7485, where the drone starts drifting east - so for 10 seconds - I can't see any relation between the shift inputs and the drone movements (except one short mistake at the 7455 mark, it last less than 1s...). I don't understand why it kept on this general track, why its speed remained so fast, with strong inputs on a different or opposite direction. A 1s input had been previously sufficient to make it brake to a hold... If there had been some wind - and, I repeat it's very highly unlickely - it would have been drifting it southwards. Even with a sudden direction change, it would require very high winds to have such an effect...
- And at last, there is the part leading to the crash (from 7485). The drone was out of my sight then. The track is then quite consistent with the inputs, and this last move is my bad. If I could have seen it before the direction change, I would have dropped the shifts and it may have been possible to take the control back. I'm at fault for this part.
So, to sum up, I assume my responsability on the last seconds leading to the crash, and the data is consistent there.
However, I wouldn't have been in such a situation if the drone had not "flown away" to the NW. I know the ATTI mode can be touchy, that I was in a risky environment, and so on. Regardless of these considerations, do you confirm that 80m drift in 10s a normal, or acceptable behavior in ATTI mode? Did I miss something? Or maybe do you totally disagree with my interpretation of these data?
- Joined
- Jul 14, 2017
- Messages
- 987
- Reaction score
- 303
In ATTI mode, it will always drift, any wind or currents will take IT like a balloon, which can be misinterpreted as the drone moving on its own. There is always more motion to air than just wind, updraft, down draft, sink, chop, turbulence, just to name a few. Most of these are not detected at ground level.
With reference to the figure above, from O – A the aircraft arrests its eastward motion due to back elevator and left aileron. In A – B it starts to move to the NW, initially due to left aileron but then continues to accelerate to B. That would appear to be driven by wind or stagnation air currents and is the only behavior not clearly driven by stick inputs. From B – C forward elevator (on a heading of 70°) orthogonal to the direction of travel causes a change in track but little change in speed, as expected. Left aileron plus a heading shift to around 30° from C – D reverses that trend briefly. From D – E, sustained right aileron plus forward elevator initially slows it and turns it to the east, at which point continued forward elevator accelerates it towards the cliff.
I really see very little to declare to be unexplained, given the unknown air currents in that topography. The basic behavior is clearly stick-driven, ATTI-mode response. We could analyse this until the cows come home, but it's not going to change the basic conclusion or provide a hardware failure reason for the crash.
"As expected", seriously? A 3 s full throttle input, orthogonal to its direction (it's not even orthogonal, it's more opposite, but wathever...), and it just very smoothly changes its trajectory? You would expect that?
Ok, I give up. Wind explains eveything. It must have been particularly mischievous that day.
Similar threads
