- Joined
- Feb 22, 2017
- Messages
- 2,093
- Reactions
- 1,301
- Location
- 48°18'25"N 11°52'10"E
- Site
- skydrone-systems.com
As @Meta4 already stated in post #6, the problem was not the wind.It was only 11 mph at 328 feet, she was only about 120 feet.
As @Meta4 already stated in post #6, the problem was not the wind.It was only 11 mph at 328 feet, she was only about 120 feet.
I totally agree graham, the wind shouldn't be a factor in this. Very possible what Meta4 suggests that taking off from a dirty magnetic area. I know he is really into the magnetic/compass areas. Need a Skydio 2 drone as it has no compass.It was only 11 mph at 328 feet, she was only about 120 feet.
![]()
Ventusky - Weather Forecast Maps
Live wind, rain, radar or temperature maps, more than 50 weather layers, detailed forecast for your place, data from the best weather forecast models with high resolutionwww.ventusky.com
It was only 11 mph at 328 feet, she was only about 120 feet.
![]()
Ventusky - Weather Forecast Maps
Live wind, rain, radar or temperature maps, more than 50 weather layers, detailed forecast for your place, data from the best weather forecast models with high resolutionwww.ventusky.com
As has been suggested, that flight certainly looks like a classic yaw error, usually induced by a magnetically distorted launch point. But I haven’t seen a proper log file analysis yet (and I’m not qualified to do it). This may require the help of @sar104 .Am bringing this over from the DJI forum with the pilot's permission.
A word or 2 about the IMUCalcs stuff which I've been meaning to document. IMUCalcs are calculations done by CsvView based on data in the .txt.I have already analyzed this crash in the other forum.
I used both CsvView and also FRAP to analyze the flight log.
IMHO it is no fault of the pilot or wind.
1) Everything is fine except the GPS health being 4 instead of 5 during the whole flight.
2) The IMU had velocity and direction failure about 27 seconds into the flight.
View attachment 88760
Please let me know what VeIN & VeIE stand for.A word or 2 about the IMUCalcs stuff which I've been meaning to document. IMUCalcs are calculations done by CsvView based on data in the .txt.
The calculations are based on two separate data sets.
Ideally, integrating VelN and VelE should produce values that exactly match GpsLatitude and GpsLongitude. Also, differentiating the GpsLongitude and GpsLatitude values should produce values that exactly match the VelN and Vel values. When there is mismatch it’s usually caused by an incorrect Yaw value. In turn, an incorrect Yaw value can be caused by either 1) incorrect magnetometer data, or 2) the FC making incorrect decisions about how to compute Yaw.
- VelN and VelE are computed by the Flight Controller using mostly the data coming from the accelerometers and gyros.
- GpsLatitude and GPSLongitude are computed by the Flight Controller using mostly the data coming from the raw GPS data.
The IMUCalcs does the integration and differentiation described above. It also compares the differentiated GPS position values against VelN and VelE.
The Velocity and Position error signals become true when a threshold is exceeded. Presently, the velocity threshold is 3.5 m/s and the position threshold is 6 meters.
VelN == true North velocityPlease let me know what VeIN & VeIE stand for.
Sorry but I'm still learning how to anialize flight logs.
Thank youVelN == true North velocity
VelE == true East velocity
Thanks a lot for your help, so what is your take on this fly away.VelN == true North velocity
VelE == true East velocity
Almost certainly caused by a geomagnetically distorted launch site. I have posted this back over on the original DJI forum thread.Thanks a lot for your help, so what is your take on this fly away.
BTW, the IMUCalcs calculations that CsvView does is due to @sar104. CsvView now implements what he is able to do with the data analysis package he uses. The post before this one is an example.Thanks a lot for your help, so what is your take on this fly away.
Additionally, the high frequency oscillations are unusual.This was not caused by high winds. The txt log doesn't really provide enough information since it only records the IMU sensor fusion solution rather than the raw sensor data, but comparison of the time derivative of position with the recorded velocity shows significant disagreement:
View attachment 88783
That's generally indicative of a yaw error, but not definitive. Additionally, the high frequency oscillations are unusual.
The mobile device DAT file may shed more light on this:
How to retrieve a mobile device DAT file: How to retrieve a V3.DAT from the tablet
Additionally, the high frequency oscillations are unusual.
Overall, the IMUCalcs that CsvView does looks the same as the calcs you do with Igor.
View attachment 88789
But, the CsvView calcs have some of the finer detail missing. I suspect that Igor does a better job of calculating the GPS position time derivative to obtain the velocities. Is it possible that the Igor derivative routine is introducing an artifact that makes it look like oscillations are occurring?
Additionally, the high frequency oscillations are unusual.
Overall, the IMUCalcs that CsvView does looks the same as the calcs you do with Igor.
View attachment 88789
But, the CsvView calcs have some of the finer detail missing. I suspect that Igor does a better job of calculating the GPS position time derivative to obtain the velocities. Is it possible that the Igor derivative routine is introducing an artifact that makes it look like oscillations are occurring?
I suspect this is the result of the fusion scheme having to make relatively large corrections. The Lat/Long isn't pure GPS data - the time integrated VelN and VelE are being used a little to compute Lat/Long. The relatively large errors in VelN and VelE cause larger errors in Lat/Long values. Presumably, the GPS data (if we had the .DAT) will be smoother.The oscillations seem to be in the data, rather than numerical artifacts. If you plot the lat/long data directly against each other:
View attachment 88791
Converting to distance north and east, and differentiating with respect to time:
View attachment 88792
The resulting velocities appear to correctly reflect the discontinuities in the position data.
I suspect this is the result of the fusion scheme having to make relatively large corrections. The Lat/Long isn't pure GPS data - the time integrated VelN and VelE are being used a little to compute Lat/Long. The relatively large errors in VelN and VelE cause larger errors in Lat/Long values. Presumably, the GPS data (if we had the .DAT) will be smoother.
We use essential cookies to make this site work, and optional cookies to enhance your experience.