Flow-Meter at the river source affected DJI FPV and it flew away backwards. Why so ?

[RobbieRocker]

Hello everyone.
I was shocked to see that my DJI FPV was affected by the river flow-meter device ( I do not know the brand and the model at the moment ) and the drone lost the control .. flew backwards ... towards the river flow.

I checked the flight data on airdata.com and everythig seems normal at the log files. What I have noticed is the 'ultrasound' altitude was fixed at 6 metres for some seconds ... although the other altitude value increased or decreased.

What do you think ? What might be cause ? The EM application on android showed 60 micro Tesla over there. I don't knw what else I can do there. I could hardly save the drone by fflying up but then it hit the branches of a tree.

I appreciate your advise

FIRAT

 

[dirkclod]

Can’t answer your question but would suggest you join our sister forum FPV Drone Pilots Forum. Has a section jus for what you
were flying.

 

[RobbieRocker]

Can’t answer your question but would suggest you join our sister forum FPV Drone Pilots Forum. Has a section jus for what you
were flying.

registered there as well

 

[Meta4]

I was shocked to see that my DJI FPV was affected by the river flow-meter device ( I do not know the brand and the model at the moment ) and the drone lost the control .. flew backwards ... towards the river flow.

That seems quite unlikely and the cause was probably something unrelated.
How close were you to the flow meter?

I checked the flight data on airdata.com and everything seems normal at the log files.

If you post a link to the AIrdata report, someone might be able to find something there that you didn't spot.

 

[RobbieRocker]

That seems quite unlikely and the cause was probably something unrelated.
How close were you to the flow meter?

If you post a link to the AIrdata report, someone might be able to find something there that you didn't spot.

only the ultrasound altitude was working wrong. I will check if I can make single link.

 

[RobbieRocker]

Can’t answer your question but would suggest you join our sister forum FPV Drone Pilots Forum. Has a section jus for what you
were flying.

 

[Meta4]

I'm not able to find any thing important in that flight data.
It was a very short flight and the speed was very slow.
I'm not sure where in the flight the drone started flying backwards.

The VPS height seems to have been working properly with readings up to 10 metres

Towards the end of the flight, at 55.2 seconds the drone was hovering low above the water.
The VPS was reading 0.7 metres you held the throttle down.
At 57.8 sec, with the throttle still pulled down, the drone commenced landing where it was.

Perhaps @slup can see something more in the flight data?

 

[RobbieRocker]

That seems quite unlikely and the cause was probably something unrelated.
How close were you to the flow meter?

If you post a link to the AIrdata report, someone might be able to find something there that you didn't spot.

5 meters maximum

 

[RobbieRocker]

I'm not able to find any thing important in that flight data.
It was a very short flight and the speed was very slow.
I'm not sure where in the flight the drone started flying backwards.

The VPS height seems to have been working properly with readings up to 10 metres

Towards the end of the flight, at 55.2 seconds the drone was hovering low above the water.
The VPS was reading 0.7 metres you held the throttle down.
At 57.8 sec, with the throttle still pulled down, the drone commenced landing where it was.

Perhaps @slup can see something more in the flight data?

The ultrasound altitude is the most important thing i have noticed. it was fixed at 6 meters although the other altitude data changed.

 

[slup]

...the drone lost the control .. flew backwards

...What I have noticed is the 'ultrasound' altitude was fixed at 6 metres for some seconds ... although the other altitude value increased or decreased.

If I understand you correctly ... the main problem was that the drone started to drift without stick inputs, not the height.

First of all ... you took off without a proper GPS lock, the HP was recorded 18,4sec into the flight when the GPS level reached 4 (of max 5). Shortly after that the GPS lock & level was sufficient for a HP, the drone started to drift off in a North westerly direction while you ascended with a full throttle input ... neither the elevator or aileron was touched. The drone reached a max horizontal speed of 8,5mph while you ascended. Can't find any instance where the drone flies backwards uncommanded ... it does it side ways though.

All is seen in this chart with the relevant telemetry (click on the chart to make it larger)

Blue background = no HP recorded ... Grey = HP recorded (P-mode)
The dashed graphs = stick inputs
The red graph = horizontal speed
The green graph = tilt angle (roll & pitch together)
The blue graph = tilt direction (in what direction the drone is leaning)




The odd in this is that the tilt direction doesn't match the drift direction at all ... below pic show the different data out from the log ...

All angels is on a +/-180 degree axis where north is 0, CCW from north is negative & CW is positive.

The drone is pointed according the red arrow ... @RobbieRocker , was that the case or did it pointing in another direction? The drone drifted away according to the blue arrow ... while you ascended with full throttle. The yellow arrow shows approx in which direction the drone was tilted ... which not correspond to the drift direction at all? (it wasn't any strong winds by the way).

If the pointing direction between the 2 red crosses wasn't according to the red arrow ... this could mean a yaw error possibly due to that you powered on your drone in magnetic interference ... would be interesting to look into the DAT log from the Goggles also. If you want to try to retrieve the DAT log follow what's written about that here --> .DAT available ... then come back & share it in this thread (the correct DAT log ends with FLY019.DAT).

 

[RobbieRocker]

Here is the .dat file : ( this includes 3 or 4 flights one after another. The drone does the same effect right at tha location and height. Until that point or anywhere out of that poin it flew very good.

dji-firat - Google Drive

drive.google.com

 

[RobbieRocker]

Here is the .dat file : ( this includes 3 or 4 flights one after another. The drone does the same effect right at tha location and height. Until that point or anywhere out of that poin it flew very good.

dji-firat - Google Drive

drive.google.com

and I have added the video as well

 

[slup]

Here is the .dat file

That one is the DAT from the drone itself ... it's encrypted & can't be read by others than DJI staff ... go back to the thread I linked to & read thoroughly how you should retrieve the Goggle stored DAT via the DJI FLY app ... if you didn't use the goggles then you're out of luck unfortunately.

and I have added the video as well

... the video on the other hand seems to confirm a probable yaw error though, the drone flies off backwards in reality & this isn't reflected in the log... the difference between reality & the yaw direction in the log differs with about 90 degrees.

Where did you power on the drone ... was it close to anything magnetic, what was under that concrete paving?

 

[Defens]

Just some thoughts - stream gauges are often sending their data to their control station by telemetry, often in a narrow beam. Also, could it be possible that the ultrasound you picked up was a wireless water level gauge that determines water depth (height) by pinging the water surface with an ultrasound distance meter?

 

[slup]

...sending their data to their control station by telemetry, often in a narrow beam.
...the ultrasound you picked up was a wireless water level gauge

As the yaw direction recorded in the log was off by approx 90 degrees if comparing the drone direction shown in the video, this incident most likely was caused by a yaw error ... meaning that the IMU don't have correct information about the direction the drone points. The consequence of this will cause rapid flyaway's as soon as the IMU senses that it needs to hold position due to wind influence for instance ... the problem is that the IMU will command the wrong motors due to the yaw error & instead make the positional error larger instead of correcting the drone back to where it should be ... so the IMU tries rapidly again & again ... & the drone flies away.

What you're referring to, would at most cause problems in the RC-drone connection & a triggered failsafe RTH.

 

[eEridani]

The video has an unusual brightness change at the same moment the drone loses it. I'd also consider battery or thermal issues inside the drone power system. These may not show up on logs.

 

[slup]

The video has an unusual brightness change at the same moment the drone loses it. I'd also consider battery or thermal issues inside the drone power system. These may not show up on logs.

Can you clarify that a bit ... in what way will battery or thermal issues cause the yaw angle between the log & video to differ by approx 90 degrees?

 

[eEridani]

Can you clarify that a bit ... in what way will battery or thermal issues cause the yaw angle between the log & video to differ by approx 90 degrees?

I'm thinking a bit outside the box here. But having no clear cause, and the video also being odd, just bringing up things that do happen in electronics.

E.g., an infant mortality event in the electronics. Something going intermittent - a battery dendrite shorting, a cap dielectric shorting, fast events that can rattle the voltage bus enough to cause multiple systems to glitch. Readings from the IMU would be unreliable as the bus rattles around, for example. Such events can be fast - microseconds - and missed by the monitoring code.

There is a battery voltage drop and current spike in the logs, though it's probably the initial branch strike also shown in the video.

What has me curious is the change in video brightness about the time the GPS locks just before the drone moves backwards; obtaining GPS lock should not affect the video, and there is nothing in view that should cause an exposure change, either.

ps: but I'd concur a simpler explanation is more likely.

 

[slup]

I'm thinking a bit outside the box here...
There is a battery voltage drop and current spike in the logs...

It's no need to stay at just "thinking" ... you have access to the log & can easily verify all that.

The uncommanded speed increase happens at 19,6sec ... compare the red speed graph with the dashed stick graphs (value 1024=neutral)... & as seen, the coming voltage drop isn't a trigger instead it's a consequence of the rapid speed increase.



As the PhantomHelp CSV doesn't include the current ... below is from the AirData CSV instead ... the same here regarding the current, it's a result of the speed increase & isn't triggering the event.

GPS lock should not affect...

That's correct ... the GPS level reaches 4 (of max 5) & a HP is recorded at 17.9sec & the incident starts at 19,6sec. Furthermore a bad GPS reception doesn't cause IMUYaw to be off by approx 90 degrees... at most it will trigger ATTI which will cause horizontal drifts... but without any effects to yaw.

ps: but I'd concur a simpler explanation is more likely.

You can't just disregard the very clear facts the log & video together provides ... it's crystal clear that the IMU have wrong information about where the drone points.

Have cut & pasted a bit below to show the difference between what the IMU think's regarding the yaw direction compared to what the video (reality) says about the yaw direction.

The original sat pic was black due to that a mountain peak is shadowing the flight location ... so difficult to judge how the flight path is located in relation to the river.

But could find a better one from Google Earth ... on which I copied in the logs path & the drones yaw direction (green bar). This shows a yaw direction in a south westerly direction.

But looking in the video at the time where the incident starts ... it shows a real yaw direction to south east.



So it's no question mark regarding what caused this ... yaw errors on 90 degrees will cause flyaways as soon as the IMU tries to hold position.

The only unknown in this stage is the cause of the yaw error ... power on in a magnetically disturbed location or a IMU failure? And as the DAT log isn't available we can't say more than this.

 

[RobbieRocker]

Just some thoughts - stream gauges are often sending their data to their control station by telemetry, often in a narrow beam. Also, could it be possible that the ultrasound you picked up was a wireless water level gauge that determines water depth (height) by pinging the water surface with an ultrasound distance meter?

I also think like you think. This device should be having ultrasound system.