Bill VS

Members
  • Content Count

    11
  • Joined

  • Last visited

  • Days Won

    1

Bill VS last won the day on August 25

Bill VS had the most liked content!

Community Reputation

1 Neutral

About Bill VS

  • Rank
    Member

Recent Profile Visitors

103 profile views
  1. Thanks Harry, for your perspective and counsel! I have the RTK ground control and markers, and am much closer now to a solution after adjusting the altitude. I'm also very fortunate to have a survey benchmark visible on the imagery to use as a checkpoint. I'm going to have to develop some serious Pix4D muscles to get within my intended accuracy of an inch or so, but I hope to get it done next week. Do you happen to know how best to share the resulting product to someone who uses AutoCAD Civil 3D?
  2. I have good news! I went out and flew a test mission straight up and down, capturing images at 0, 50, 100,... 400, 375, 325, 275, etc., to get relative and absolute elevation values every 25', ascending and descending. Used Exiftools to export the metatags from the imagery, and... the problem is linear (r-squared equals 1!) , and the units are indeed in meters: Apparently DJI uses a weird ellipsoid (model of the earth's surface) in their calculations, so in my area, the elevations are 70.5 m (231.4') below what they should be. That explains why the UAV thought it was below the roadway I was overflying, and it should be resolved by adding 70.5 to all GPSAltitude values. Although DJI doesn't seem super exited about fixing the problem, Pix4D has a workaround. It's in their Image Properties editor, and it looks sort of like this: (source: https://support.pix4d.com/hc/en-us/community/posts/205984103-Negative-Altitude-Values) This doesn't fix the problem entirely, but it gets the visual plane up above the GCP's, which should allow me to see them and use them. You can also use ExifTool to fix the problem, along these lines: exiftool -n -GPSAltitudeRef=0 -tagsFromFile @ -RelativeAltitude>GPSAltitude DJI_0807.JPG I don't know if that will work, but if the P4D fix doesn't work, I'll certainly give it a try. Thanks, all, for your consideration and comments!
  3. Hey all, thanks so much for responding to this post. My ability to spend time on the project waxes and wains due to higher priority stuff, but I think I'll be able to get back on it pretty soon. CaseyC reached out, so I'm going to provide them some info soon, but I'll cc this post if you guys would like more nuts n bolts. Just to clarify, here are some bullet points to clarify the error we're talking about here: By my calculation, the GPS units that DJI is recording (on both the Phantom and the Inspire) are 1 unit equals about 50', so that's going to account for a pretty huge difference in the EXIF tag. It's possible, for instance, that DJI's firmware may be recording in U.S. Survey Chains (60') or Indian Bamboos (42', established by Akbar the Great in the mid-1500's). To quote Adam Savage, "THERE'S YOUR PROBLEM", or at least part of it. Values are also negative. So instead of 100' above the roadway, the UAV thinks it's flying 50' BELOW it, putting the surveyed target ABOVE the UAV, and therefor not in the picture in order to be selected as a GCP. The barometer values are not too bad, actually, and the calibration was a few minutes before the first observation, taken at the same XY location but hovering at different altitude. So speed should not be an issue here. I'm not sure how to make Pix4D use the barometer elevation instead of the "GPS Elevation", which is the extra-screwy one. This GPSAltitude problem has been reported before, and has been discussed at https://forum.dji.com/forum.php?mod=viewthread&tid=154027, and https://forum.dji.com/thread-117047-1-1.html, but not in a very satisfactory way. So far, everything seems to point to a bad Geoid (geometric model of the earth) conversion. The nearest answer I can see so far is to write a program to dump the RelativeAltitude data into the GPSAltitude tag in the EXIF file. It'd be nice if I could figure out how to get Pix4D to look at the RelativeAltitude instead of the GPSAltitude.
  4. Hey Nadine and Casey! It's good to hear from both of you! It's also good to hear I'm not the Lone Ranger regarding the vertical error problem. We placed and surveyed a dozen survey targets on the Lake Apopka Levee at the time of flight, so I have GCP data. The problem is that Pix4D doesn't seem to accept the GCP input, either in "automagic" mode or manual edit. And the folks at Pix4D are little or no help. If you have Pix4D and Skype, could we set a time this week or next to share my screen and go through the steps together?
  5. Can anyone advise me about the problem with vertical GPS values on DJI units? The horizontal values seem to be just fine. We have an Inspire 1 and an Phantom 4 Pro. We have been using them, along with DroneDeploy and Pix4D, to map wetland vegetation for wetland restoration projects in Florida. The problem arose when we started combining imagery with survey to create and deliver 3D models to our engineering colleagues. Both UAVs report accurate altitude to the RC, but the EXIF tags tell an entirely different story: A photo taken at ground level (let's say, 65' above sea level), is tagged with an elevation of -88.0 (no indication of what the units are, but .5 units represents about 100'). If we fly 100' into the air and take another picture, it now reports an altitude of -87.5 units. Per the DJI helpline folks, we've tried recalibrating the unit right before flight, and that doesn't seem to make a difference. Unfortunately, the images captured indicate that, rather than 200' over the levee (which is about 70' on the NAVD88 datum), the image thinks that it was captured from a position 20' or so below the roadbed. Flying another 100' or 200' up still doesn't get us above ground level. So Pix4D and Simactive both have trouble resolving this, and even manually editing the GCPs (at least in Pix4D) doesn't seem to fix things. DroneDeploy does a decent job of creating a model, but it's not georeferenced, and that's part of scope. Plus, 1) I'd like a more detailed model than they generally provide, and 2) my management will not support the subscription upgrade necessary to use GCPs, especially since we already purchased a license of Pix4DMapper. Dishing out $20K for an RTK unit is not on-budget for a few more years, so let's just assume that's not a solution. Besides, we don't need centimeter accuracy for the flight, just for the solution after the GCPs are incorporated. Just being within a few meters of reality (as advertised) during flight would be fine. We could probably write a python script to write pressure altitude values to the GPS field, but that seems like kind of a sloppy workaround. Any other ideas? Does anyone have a buddy at DJI who might fix this? Kindest regards, - Bill William E. VanSickle Professional Geographer, Commercial Remote Pilot GIS Analyst III, Office of Information Technology St. Johns River Water Management District P.O. Box 1429 ● Palatka, FL 32178-1429 Office: (386) 329-4580 Email: bvansickle@sjrwmd.com Website: www.sjrwmd.com Connect with us: Newsletter, Facebook, Twitter, Instagram, YouTube, Pinterest
  6. If you're talking about reading sectional charts, the purpose is for you as a commercial remote operator to find out where you're not allowed to fly. I've learned that, since we have to yield right of way to all manned aircraft, I still spend lots of time dropping the drone and burning battery time near the deck as someone in a Cessna loiters over the marsh at a few hundred feet, doing lazy turns and maneuvers and just enjoying the low-density air coming off all that warm water. I put in NOTAMs, I contact all the local airports and warn them, and still I get the little single-props and seaplanes cruising into the work zone. I get it, it's my job to stay out of their way, but it can be frustrating.
  7. I suspect that EPA will be a bit shy about "surveilling" private property with UAVs. They've gone all the way to the Supreme Court with high altitude aerial imagery, but that doesn't mean they want to do it again over drones. My guess is that they'll likely stick with satellite imagery for large scale monitoring, and go to the state regulatory agency and/or contractors for local monitoring, SuperFund compliance, etc. BLM and USACE, on the other hand, appear using the heck out of drones, as are some of the state Department of Natural Resources agencies. At the State level, Florida has been contracting drone work out (probably for blameshed management purposes), but I suspect that will change as case law develops, and once the technology settles a bit. City and county agencies seem to be charging ahead with their drones, especially for Fire / Rescue. Topography requires LiDAR, and, at least in the state of Florida, requires a licensed Professional Land Surveyor / Mapper (PLSM, aka "surveyor") to produce a finished product. If it's bare ground, we can make a photogrammetric model from the point cloud where photopoints coincide (Pix 4D and DroneDeploy both offer this), but in Florida you're only going to find bare ground on disrupted land, such as construction sites or open mines (like Phosphate or Sand). Without bare ground, photogrammetry provides a surface of the vegetation, not the land. LiDAR cuts through that problem by sending a bunch of little laser pulses (several to hundreds per square meter) through the vegetative canopy to the ground, providing point clouds at canopy level and at ground level. The canopy-level point clouds are "scraped off" algorithmically to expose a "bare earth" model under the veg. Most of our LiDAR projects are large enough (~100,000 ac -> statewide) that they make more sense to do with manned aircraft. However, when once get the statewide LiDAR topography layer in place, it might make more sense to 'drape' smaller datasets on top of it.
  8. I don't know the answer to that question yet, but I suspect it will be a moving target, depending on 1) what our annual mission backlog starts to look like as we get more requests from internal clients, 2) The features and prices offered in the marketplace over the coming years and 3) what our management is willing to support with budget resources. Right now, we have a Phantom 4 Pro and an Inspire 1. Long term, I suspect a VTOL system may do a better job, but for now, we have what we need in order to figure out what we're gonna need. I haven't flown the Phantom yet (it's stationed in a field office about 200 miles away from my office). With the Inspire, I can fly about 125 ac (imagine a square area of about 1km per side) in about 15 minutes, at 395' AGOL, on one battery, without going beyond visual line of sight (imagine a square area of about 1km per side). So I fly these 100 ac flight missions and upload them to DroneDeploy in batches of 4 missions each, which totals about 1000 images (the limit of the number of images per batch that we can process under our current license agreement with them). When I get these 400 ac georef'd mosaicked solutions back, I stitch them together in ArcGIS and load them up to our server. With a VTOL system, I'd most likely create long 1km deep rectangles and post observers every 1 km along a levee, I would keep them in constant (ground) radio communication with the pilot so that he has continual observation of the unit and the surrounding airspace at all times. That keeps us within Part 107 compliance without a waiver, and keeps the overhead traffic safe, which is of course Job 1.
  9. Guys, as a GIS/IT/Environmental Sciences professional who uses sUAVs, I want to say that I agree with and appreciate what I'm hearing from you guys! This stuff belongs on its own FAQ page. Well done. The only thing I might add is that 1) getting part 107 certificated is a pretty good/easy/inexpensive place to start, if you haven't done that already (obvious, but worth mentioning?) 2) I would check in with the Army Corps of Engineers (they're doing lots of LiDAR and storm damage assessment work with drones these days). Also, what about Border Patrol? Who wouldn't expect those guys to be up to their necks in UAVs in the next year or ten? Finally... 3) have you considered pursuing a master's in biogeochemistry and/or remote sensing? That would take advantage of your previous college experience and position you well for wetland ecology drone work. Florida, for instance, has 5 water management districts (I work for one of them) that manage millions of acres of wetlands that change from one week to the next. We're finding that satellite imagery plus "drone truthing" (for wetlands over a few thousand acres) plus drone imaging (hyperspectral and LiDAR) for the smaller ones and supervised data classification are really useful tools in managing natural systems, water quality and quantity, and flood protection (our 4 core mission areas). I suspect that, like GIS, Part 107 will eventually be part of minimum requirements for field ecologists, but for right now, it's a way to stand out from the crowd, and ensure that you get some field time in every month or so. We are also required by statute to give hiring preference to those who served in defense of our country. Kindest regards, and thanks for your service.