Hello Fellow Yuneec Pilot!
Join our free Yuneec community and remove this annoying banner!
Sign up

H520E RTK From the Box Up

Good morning from Texas! Is Datapilot Planner 1.5.0.1 the latest version? I couldn't find any links that work online or in other threads. Or should I just stick with 1.4.44.40?
Take a look here....sorry for the site, it's full of advertising ?‍♂️

 
Take a look here....sorry for the site, it's full of advertising ?‍♂️

Thanks, but this is the Android app. I am looking for the desktop planner. I think when they mention Windows they are using an emulator. It is confusing though that both the mobile and desktop had a v1.5.0.1.
 
Good morning from Texas! Is Datapilot Planner 1.5.0.1 the latest version? I couldn't find any links that work online or in other threads. Or should I just stick with 1.4.44.40?
This link was published here on the forum, but it is for H520:
US Firmware
The file "DataPilotPlannerWINDOWS.msi" is Version 1.5.10.19 for Windows desktop with survey, structure and corridor.

Under this Link in the folder for the H520E only seems to be the APK for the ST16E (Data-Pilot-APK-File.zip):
Yuneec Downloads
 
  • Like
Reactions: chascoadmin
This link was published here on the forum, but it is for H520:
US Firmware
The file "DataPilotPlannerWINDOWS.msi" is Version 1.5.10.19 for Windows desktop with survey, structure and corridor.

Under this Link in the folder for the H520E only seems to be the APK for the ST16E (Data-Pilot-APK-File.zip):
Yuneec Downloads
I was able to get the file (1.5.0.1) from Yuneec (ATLabs) and they said that was the latest supported but will try your link as well. Thanks!
 
  • Like
Reactions: vr-pilot
Never used manual exposure myself so no but I could give it a try. The original H520? PM me your FW versions.

Here the "Vehicle/About" on my H520's ST16S:

Screenshot_2021-04-24-16-27-53.png

Here 3 screenshots showing the "White Screen of blind flight" that only comes when "Manual Exposure" is used: DP (?) sets exposure time "automatically" to 4 seconds after interrupting a mission.
Mission interruption in "Automatic Exposure" mode, no problem:

Screenshot_2021-04-24-17-17-37.png
before mission interruption in "Manual Exposure" mode (here 1/1000s):

Screenshot_2021-04-24-17-17-07.png
after Mission interruption in "Manual Exposure" mode comes the "WHITE OUT":

Screenshot_2021-04-24-17-18-01.png



In addition to this old "white screen effect" it looks like since the January-2021-update photo depiction on the map and even the photo counter (under the UI shutter button) stopped working. There were photos on my SD card though.

Finally I can confirm weird flight behaviour during corridor missions. Abeam every corridor waypoint my H520 started turning inbound the "inner way point" but rejected to do so some seconds later and then returned to the initial track... That is also happening since the last January-2021-update.
 
Last edited:
  • Like
Reactions: chascoadmin
Abeam every corridor waypoint my H520 started turning inbound the "inner way point" but rejected to do so some seconds later and than returned to the initial track...
Not sure I can visualize the action of this but I have a meeting with them in about 45 minutes and Linear Flight is definitely one of the items on my list. We will be focusing on the E models but could end up affecting the v1 as well.
 
Last edited:
  • Like
Reactions: vr-pilot
I was able to get the file (1.5.0.1) from Yuneec (ATLabs) and they said that was the latest supported but will try your link as well. Thanks!
I don't know if it is a good idea ;-) Maybe RTK etc. doesn't show up?
In Qgroundcontrol all these RTK features and itmes are available by default, but I don't know about the H520E's ST16E-DataPilot APK...
Today I got this newsletter from Yuneec EU:
Yuneec – Quadcopters & Aerial Drones
You may know it already, but I was looking at their statements about RTK and especially their PPK workflow "announcements":

The RTK module enables precise positioning even in challenging environments and is fully integrated into the H520E, hardware and software wise. This means that you still have the full range of functions of the award-winning DataPilot software. All data, including raw GNSS data, can be logged on board. Thus, the system is also already for PPK (Post Processed Kinematics).

and
  • All data including raw GNSS data and real-time solution can be logged on board - ready for PPK (Post Processed Kinematics)
I am "investigating" since months already to get RTK/PPK with 1-3 cm X/Y/Z-accuracy into my imagery. So your thread is really gving me the necessary real-world-view...
Apropos:
Just yesterday I saw in a seller video that the M2EA-RTK does only work for RT-positioning, and not (yet) for RTK/PPK geo tagging the imagery.
Boy! I was mm away from pushing the order button on that bird to get RTK/PPK 48 MP RGB mapping including 640x480 R-JPG photogrammetry. But that seems not to be included.
Also: the 48 MP resolution seems to derive from a 12 MP sensor with interpolation only... So the 20 MP E90 seems to be superior.

EDIT:
Here the original newsletter content:

Centimeter-level accuracy with the H520E RTK​

Thanks to Real Time Kinematics technology, the H520E-RTK* is able to stand in the air with centimeter positioning, enabling precise imagery, faster 3D mapping and accurate inspection flights.

Key Features:
  • Keep cm precision even in GNSS challenging environments
  • 5 Hz update rate of position, velocity and time
  • Support signals of up to 3 GNSS constellations among GPS, GLONASS, Galileo and BeiDou
Learn more

And its applications?​

The RTK GPS technique has revolutionized the industry. Power lines and Offshore Rig inspections, surveying and mapping have never been safer, cost- effective, and with this accuracy level. Not only its centimeter accuracy allows pilots to operate in small spaces and close to objects, but also, it provides protection from interference from radio frequency (RF) and electromagnetic fields (EMF).

These benefits make the H520E-RTK an ideal choice for industrial applications.
 
Last edited:
  • Love
Reactions: chascoadmin
I don't know if it is a good idea ;-) Maybe RTK etc. doesn't show up?
In Qgroundcontrol all these RTK features and itmes are available by default, but I don't know about the H520E's ST16E-DataPilot APK...
Today I got this newsletter from Yuneec EU:
Yuneec – Quadcopters & Aerial Drones
You may know it already, but I was looking at their statements about RTK and especiually their PPK workflow "announcements":

The RTK module enables precise positioning even in challenging environments and is fully integrated into the H520E, hardware and software wise. This means that you still have the full range of functions of the award-winning DataPilot software. All data, including raw GNSS data, can be logged on board. Thus, the system is also already for PPK (Post Processed Kinematics).

and
  • All data including raw GNSS data and real-time solution can be logged on board - ready for PPK (Post Processed Kinematics)
I am "investigating" since months already to get RTK/PPK with 1-3 cm X/Y/Z-accuracy into my imagery. So your thread is really gving me the necessary real-world-view...
Apropos:
Just yesterday I saw in a seller video that the M2EA-RTK does only work for RT-positioning, and not (yet) for RTK/PPK geo tagging the imagery.
Boy! I was mm away from pushing the order button on that bird to get RTK/PPK 48 MP RGB mapping including 640x480 R-JPG photogrammetry. But that seems to be included.
Also: the 48 MP resolution seems to derive from a 12 MP sensor with interpolation only... So the 20 MP E90 seems to be superior.
That was a good choice. The M2EA is not a mapping drone. It is designed for inspections and it along with the Autel EVO II Pro RTK tout their "effective 48mp" sensor. Problem is that writing an image of that size that it processed (stitched) internally would mean that you would have to stop and hover at every image. On top of that the 1/2" (yes 1/2in...) Quad Bayer sensor is not good in low-light situations. Very noisy.

They and us both have rolling shutters which we all know is frowned upon but I have not seen any issues in processing or deviation from intrinsics with DroneDeploy or SimActive Correlator 3D with nadir images. Obliques on the other hand may be a problem the higher you AGL because of the increased GSD and warping at the top of the frame. I did 150ac yesterday at 200ft AGL with a 70deg pitch and am processing now. The reason was because it was for existing conditions before construction demo so getting under trees and verticals was more important than ground. We shall see.
 
  • Like
Reactions: vr-pilot
Problem is that writing an image of that size that it processed (stitched) internally would mean that you would have to stop and hover at every image. On top of that the 1/2" (yes 1/2in...) Quad Bayer sensor is not good in low-light situations. Very noisy.
Thank you for clearing that up for me. I "thought" they were "stealing" shutter time and trade it for higher ISO. i.e. taking 4 images with 1/4000s shutter in sequence at ISO 400 that would result in a processed image at "12-MP-quadrupled-resolution". The image then would look like a 48 MP image with 1/1000s exposure time "motion blur level" indicating ISO 100 but looking 4 times as noisy ;-) But if 48 MP from the M2EA requires intermitting stops and hovers for every image, it is not my option.

They and us both have rolling shutters which we all know is frowned upon but I have not seen any issues in processing or deviation from intrinsics with DroneDeploy or SimActive Correlator 3D with nadir images. Obliques on the other hand may be a problem the higher you AGL because of the increased GSD and warping at the top of the frame.
The rolling shutter is only a problem when the movement of image content is not the same as the line forwarding motion ("line feeding" direction) of the sensor. Actually by using a rolling shutter camera (mounted in the correct orientation) taking nadir images is like flying a flatbed scanner at a certain AGL ;-)
Amazing: even at slow shutter times like e.g. 1/25 s the E90 at 34 m AGL (GSD 1 cm/px) vertically scans 36.48 m (3648 px) within 0.04 s. That results in a top-to-button "scan over ground speed" of 36.48 m / 0.04 s = 912 m/s that is 3283.2 km/h.
Nevertheless getting sharp images up to pixel level requires 1/1000 s shutter time when flying with 10 m/s at 34 m AGL with the E90... where 10 m/s equals 1000 px/s for a GSD of 1 cm/px.
 
  • Like
Reactions: chascoadmin
Thank you for clearing that up for me. I "thought" they were "stealing" shutter time and trade it for higher ISO. i.e. taking 4 images with 1/4000s shutter in sequence at ISO 400 that would result in a processed image at "12-MP-quadrupled-resolution". The image then would look like a 48 MP image with 1/1000s exposure time "motion blur level" indicating ISO 100 but looking 4 times as noisy ;-) But if 48 MP from the M2EA requires intermitting stops and hovers for every image, it is not my option.


The rolling shutter is only a problem when the movement of image content is not the same as the line forwarding motion ("line feeding" direction) of the sensor. Actually by using a rolling shutter camera (mounted in the correct orientation) taking nadir images is like flying a flatbed scanner at a certain AGL ;-)
Amazing: even at slow shutter times like e.g. 1/25 s the E90 at 34 m AGL (GSD 1 cm/px) vertically scans 36.48 m (3648 px) within 0.04 s. That results in a top-to-button "scan over ground speed" of 36.48 m / 0.04 s = 912 m/s that is 3283.2 km/h.
Nevertheless getting sharp images up to pixel level requires 1/1000 s shutter time when flying with 10 m/s at 34 m AGL with the E90... where 10 m/s equals 1000 px/s for a GSD of 1 cm/px.
Exactly! I have seen very minor intrinsic focal point errors into the thousandths of a percent with nadirs but a 70% oblique produced 0.04% due to the warping at the top of the frame which essentially moves the principal point away from the CCD center. That may not seem like allot but it is definitely there and I wouldn't map any faster than about 14mph.
 
  • Like
Reactions: vr-pilot
I can't tell you how happy I am with the OFDM radio! Did a 200ac project yesterday which had me at my VLOS limits at a few points and the OFDM signal never dropped. Good at 2800ft now. There still seems to be some occasional stuttering of the video feed but no blackouts.
 
  • Like
Reactions: vr-pilot
Who's bird watching who?
Is it a red/grey kite? From my experince they are the birds most "interested" in drones.
When the bird of prey's tail looks similar to the one of a swallow bird the only escape maneuver (for the drone) is PULL UP!
 
Is it a red/grey kite? From my experince they are the birds most "interested" in drones.
When the bird of prey's tail looks similar to the one of a swallow bird the only escape maneuver (for the drone) is PULL UP!
It's a red tail hawk and they do like approaching the drone aggressively. Buzzards like to follow them as well but never really get close and aren't fast enough to keep up with it in straight line flight.
 
Flew in 16-18mph sustained with 30mph gusts today and I think that is about the limit that I am comfortable with. I flew head/tail winds and while there wasn't much bucking the turns were a little uncomfortable. I have yet to be able to test it yet but we have come to the conclusion that the odd behaviour in turns might be due to the RTK and how it is trying to hit the exact coordinate of the turn waypoint. Hopefully the wind will die down this afternoon but I will definitely run some comparisons tomorrow.

As far as accuracy goes I am get 4-5cm checkpoints on RTK alone and all of the PPK verifications have been good on the RTK so far except for one day we had issues with GLONASS. I turned off GLONASS in RTKLIB and retagged the images and that map went from 7-8cm to 4-5cm. I am also seeing some strange variances when I use GCP's rather than calibrating the map using checkpoints and/or benchmarks when they are available. For some reason the GCP's in very large maps seem to be making the camera location RMSE's worse. A slight shift in the map is expected when using GCP's but a warping wasn't. I'll have to do quite a bit more comparison to really see what is happening because it is not consistent.
 
  • Like
Reactions: vr-pilot
For some reason the GCP's in very large maps seem to be making the camera location RMSE's worse.
Are GCPs making the "little planet effect" more visible? (I.e. is bending becoming noticeable from zero-Z-level viewpoints?)
 
Are GCPs making the "little planet effect" more visible? (I.e. is bending becoming noticeable from zero-Z-level viewpoints?)
It's more of a horizontal shift that is not consistent across the map. In theory the whole map would shift in a consistent direction and distance with maybe a little rotation if the GNSS rover and the drone's RTK are at similar relative accuracies. Both are receiving the same corrections via NTRIP but as an example on one of the maps the east checkpoint moved about 1ft further to the east than the west checkpoint did. This was across about 1,200ft. The increased error in Z is very minimal and still within our +/-0.10ft tolerance and there doesn't seem to be any bowling/doming when a cut/fill analysis is done between the two maps once aligned.

Problem is that I have verified every flight with PPK and the flight data so far is 100% good in 87% of the flights but I trust my rover more in both relative and global accuracy so I am just going to have to find a common denominator and localize the error in CAD which is a part of the workflow that happens regardless of how the data lands after photogrammetry. The end goal is for the flight to be relative to the site control, not global datum. Sometimes the site is on true WGS84 and State Plane coordinates but most of the time there is still a little movement in the CAD once it has gone through a surveyor and engineer and gets to us.
 
  • Like
Reactions: vr-pilot
Using the E90X we are 24 flights in now and we have had 3 occasions where the mSD wasn't recognized and one instance where the camera wasn't recognized even though there was video feed. All occasions we with different mSD cards.
 
Is anyone else noticing issues with the GPS date in the EXIF data? I am getting images reporting incorrect dates and it is causing problems with some of our reporting software that depends on that and GPS location for proper filing. As you can see it is reporting the correct GPST but the date is wrong. It is happening on every image. I just happened to have fixed the others except for this one to show. Strange is that it doesn't seem to be affecting any of the photogrammetry software.

Image
1620419856989.png
 

New Posts

Members online

No members online now.

Forum statistics

Threads
20,955
Messages
241,599
Members
27,286
Latest member
lahorelaptop