UAV Toolbox Organization

[mpalmsten]

Hi! Richie Slocum made this observation:

From reading through the wiki, it seems like there are a few main categories of "toolboxes":

1. Mission Planning (simulation of cameras, overlay on google earth, pixel size estimates, fov estimation, etc)
2. Camera Calibration (Calculate Interior Orientation)
3. Camera Pose Estimation(Calculate Exterior Orientation)
4. Data Projection/Registration (Orthophotos, pixel stacks)
5. Data Interpretation (cbathy, optical flow, timestack analysis, etc)

What are people's thoughts on reorganizing the toolbox into some organized sub-directories?

Any other suggestions? @allisonpenko @KateBrodie @Levi-Gorrell @RobHolman @jstanleyx

[RobHolman]

Seems like a good start to discussions about our eventual structure. I’d have to think about how all of our current routines fit in the CIL. If I think about the last category, it includes all of our pixel analysis routines including runup, vBar, cBathy, etc, so it would have to be an overarching directory with lots of sub-directories. On the other hand, camera calibration is just the caltech toolbox and maybe something to format the output.

Needs thinking, for sure.

Rob Holman SECNAV/CNO Chair in Oceanography

104 Ocean Admin Bldg. CEOAS-OSU Corvallis, Oregon, USA 97331-5503 ph: 1-541-737-2914 holman@coas.oregonstate.edu http://cil-www.coas.oregonstate.edu

On Apr 12, 2017, at 1:27 PM, mpalmsten notifications@github.com wrote:

Hi! Richie Slocum made this observation:

From reading through the wiki, it seems like there are a few main categories of "toolboxes":

• Mission Planning (simulation of cameras, overlay on google earth, pixel size estimates, fov estimation, etc) • Camera Calibration (Calculate Interior Orientation) • Camera Pose Estimation(Calculate Exterior Orientation) • Data Projection/Registration (Orthophotos, pixel stacks) • Data Interpretation (cbathy, optical flow, timestack analysis, etc) What are people's thoughts on reorganizing the toolbox into some organized sub-directories?

Any other suggestions? @allisonpenko @KateBrodie @Levi-Gorrell @RobHolman @jstanleyx

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[hokiespurs]

@RobHolman @mpalmsten

I think the big question Rob alluded to is: how do you decide if something should be a standalone repository, vs subfolders in an existing repository.

The two ends of the spectrum are: 1) Every new algorithm gets its own repository 2) Everything goes in one giant repository in subfolders, and branching rules are clearly spelled out.

Where on the spectrum do you all think CIRN should fall?

Check out some of these bigger development projects on github that fall closer to (2) on the spectrum... They have a very diverse set of subfolders, and appear to be well organized with many branches. Cloud Compare (3D pointcloud viewer with various user plugins) Cura (open source 3D printer slicer)

May be useful to tag any more experienced programmers who use version control frequently for some insight on this. A list of pros/cons from some experienced users would probably be useful.

@thesser1

[RobHolman]

Concur on the issues. I feel like we need to spend quality time thinking about how this all will flesh out in the next year or more. We have a good first cut in that we have accumulated CIL routines over many decades in a set of toolboxes, some of which are clearly structured and some of which are completely random. But at least we have a good cut at the range of routines we will run into. One difference with the CIL is that we assume our local database support structures, so we need to be able to isolate those from core routines, etc. It will take some thought and I would rather think now before we get too deeply into an evolving structure. This all said, I think it is something that we can easily manage and I think it will be good to re-think our toolbox organization from a top down perspective.

Is there where I write @allisonpenko @KateBrodie @RobHolman @jstanleyx @mpalmsten @SRHarrison ?

[jstanleyx]

I think the question is "how does this package/thing fit into the overall remote sensing using video picture?" Is it a UAV-specific thing dealing with how you manage UAV images, or is it a general purpose all-encompassing tool? cBathy is not limited to UAVs, thus it is not a sub-dir under UAV. Managing pixel lists and instruments is not limited to UAV, ditto. In the long run, undistorting/distorting a UAV image is not specific to UAVs either -- it is a process that has to occur for all image processing. It is in the UAV toolbox only because there was no other "tools" area to put it, and because Rob created it outside the scope of the existing un/dis functions.