Solar Panels: Edge issues on maps

Hi all,

Apologies if this is a subject that has already been covered. I’m new to the forum and I wasn’t sure what exactly to search for. I’ve been using DD for about a year now, and I work for a construction company that builds Utility-Scale Solar Energy sites.

I’ve mapped DOZENS of sites that we’ve built, in various stages of construction and it seems that whatever I do, I continue to have an issue with the edges of the modules being really messed up when the map is stitched together. Example below:

As you can (hopefully) see, the edges of the modules are not correct and this can be problematic when doing inspections or installation review.

If there is an older forum post that addresses this, and someone can point me in that direction, I’m happy to read the discussion in that location. I’m also happy to provide more details about the equipment and flight parameters that I’m using, if that is relevant (although I’ve seen the same effect with different equipment and parameters)

Thanks in advance.

-Jeff Crabtree

Here’s a thread that is one of many that would help your results, but panels being free-standing structures and pretty small dimensionally in depth that they are going to be tough without allot of images at a low altitude.

Can you describe or share snippets of your flight plan?

Thanks for the reply.

Here’s a screenshot of the most recent flight parameters and settings.

I’ve tried varying altitudes and varying overlap. This particular map was flown at 140 feet because I needed to maximize ground details/resolution for specific reasons.

It seems like most other aspects of the map render properly, but DD really hates the edges of things. The only thing I haven’t attempted is changing the image overlap to the minimum (30%), but like with most other things, my rational has always been “more is better”.

Once I get below 200ft I start running at least 75/75 and by the time I get down to 140ft I would probably be at 80/75 if not 85/75. I think it would help, but I think this map really needs obliques probably from the Enhanced 3D Crosshatch. I don’t think you need the perimeter option included. Keep in mind that the crosshatch option does eliminate nadirs, so an extra flight including them couldn’t hurt and try different methods of processing. IE, obq and nad with one on terrain and another on structure. Then another with just obq on structure. My only reservation is that there has been problem with structure mode processing lately cutting out objects, but it has only been trees and might be limited to that.

How did you process this map?

I processed this particular map (LINK) in Terrain Mode (2D), but I’ve tried both ways, on this and other projects, using crosshatch flights (with and without perimeter shots). The same thing happens on pretty much every map.

My goal would be to eliminate this effect so that visual inspection of modules would be possible. Often debris on the modules that shade a cell or broken modules (rocks from mowing…or, believe it or not: bullet holes (most of these sites are very rural)) are the cause for reduced output. It would be extremely beneficial to be able to fly a site and inspect the modules in a zoomable map, as opposed to doing it in real time.

This effect renders that impossible.

If possible, could you please re-send the link to the former post that you referenced earlier? i don’t see it in your first reply.

What were your settings for the oblique flights? Building a better 3D model helps the appearance of a 2D map. Flying nadirs alone, using terrain mode and doing structure mode with nadirs only probably won’t get the results you need. Flying two missions at different heights can help as well. I wish I had something like that to fly so I could be of more help. Maybe someone will come across this who actually does solar. Here’s a couple of threads dealing with cleaning up 3D models.

Hello,

I’m sorry to revive a dead thread but I am having a similar problem, and I’m wondering if @wjcrabtree ever found a solution to this problem?

I have flown many solar sites and have found that 80/80 at 140’ AGL has worked out the best so far, but I’m still having issues like this:

And this:

In addition to flying with nadir camera parallel to the rows, I have flown parallel to the rows with a 75 degree camera angle and perpendicular to the rows with 75 degree angle to the camera. I processed the maps many different ways and the best I can get is show in the images above.

Any ideas would be appreciated.

Personally I think the overlaps are too high. I like the altitude but I would try it higher. What drone and device are you using?

Thanks for the response, Michael. I am using an Autel EVO 2 Pro with their mapping software that’s built into the Autel Explorer app. It is easy to set different flight parameters, so I’ve been trying a few different things.

Do you think 80/65 or something like that might work for overlaps? Also, I will definitely try a higher altitude next time. I was thinking of trying somewhere around 175-200’ AGL.

1 Like

Here’s what I have tried (with some success:

Higher altitude flight. Yes, less resolution, but also less stitching.
Fly perpendicular to the tables, not parallel.
Set the gimbal angle to counter the angle of the modules (Explainer below)

My tactic is to capture the modules as rectangles in an image, not parallelograms. If it’s a tracker system, try to fly at or as close to solar noon as possible so that the tables are flat and set your gimbal to 90°. If it’s a fixed tilt system and the tables are at 25°, the counter angle is 65°, so set your gimbal to that.

I really think that the processing software wants the modules to be perfect rectangles with right angles instead of the parallax shapes that we end up with while capturing.

Here’s an example of a map that I created recently where I used these tactics on a SW facing (prioritizing production in the afternoon), fixed-tilt system:

GF NC

Because of an installation error, it was critical that we be able to count mods and share this map with the system owner to demonstrate/prove that the table/string counts were correct.

While there are some weird artifacts from the stitiching process, the tables look damn good, compared to previous creations.

1 Like

Here’s my flight parameters for this project.

2 Likes

If you are running an oblique crosshatch I would try 75/65 @ 175ft. I didn’t think about that when I said 80… Did you say you did a nadir flight as well?

Thanks so much for this information @wjcrabtree. I’ll try out this method the next time I’m out there. What drone did you use for this job?

@MichaelL 75/65 seems to be the numbers to use, so I’ll definitely try that next time. And yes, I did do a nadir flight as well. The nadir flight outputs looked the worst of all the ones I tried.

Thank you for all the info guys, I now have a plan for the next time I’m out flying over an array. It will be nice to not be guessing and running out of batteries.

1 Like

Just to clarify, I was suggesting that you do both obliques and nadir. This will probably clean up those top surface edges.

Mavic 2 Pro…hoping to convince the company I work for to upgrade me to a Matrice 300…shhhhyeahright!

2 Likes

Same here my friend. We’ve done too good a job with Phantom 4’s and eventually got the Yuneec RTK which was $6500 out the door but $35k+ is a different animal.