Spectral sensor data

Storing spectral data

• Management Tips:

  • Always back up all data to at least 2 separate locations
    • If more than two locations are being used to save data, it is also good practice to have an easily-accessible document to track what device holds which projects for quick reference
  • Store data in the file format Client/Company --> Project --> Location of Flight --> Date
    • This depends on your application and purpose for the data and who the end user is. Project can be replaced with purpose (e.g. "Crop Monitoring" or "Utility Inspection") or Client/Company can be negated if the there are not multiple projects for one client. (See File Organization for more discussion)
    • Storage needs to make sense so that someone not directly related to the data management process can go select a specific data set
    • Typical date convention: Year.Month.Day. This is the easiest way to locate data that is being compared over a period of time, or where the end user know the date in which the operation was flown
  • Keep all "raw" imagery
  • Metadata to keep (in the form of filenames)
    • Date of flight (year.month.day)
    • Platform utilized
    • Altitude flown
    • Sensor type
    • Location
    • Pertinent weather information (anything that will affect the data output-- clouds, excessive wind, etc...)
      • This may not be necessary if this kind of metadata is already being saved in conjunction with the data collected
    • See UAS Metadata for more discussion
  • Use metadata information to name exports of data to efficiently describe the data set
    • Year.Month.Day, location, platform, sensor, altitude, additional descriptor(s)
      • For example, an exported orthomosiac would have the name: 2017.06.21 FarmLocation S1000 RedEdgeNIR 400ft (Windy)
      • Additional descriptors can tell the end user why the data set turned out the way it did. "Windy" can indicate that some of the pictures couldn't stitch together, which would explain why there would be holes in a data set
      • Metadata should be arranged in a way that makes sense for the project. If the main goal of a dataset is to compare outputs of different altitudes then move the atltitude in the front of the name, or put it last, so that it can be quickly spotted.
  • When working with photogrammetric processing software (in which you cannot just 'undo' mistakes), save new files along the way with a descriptor at the end
    • Example: 2017.06.21 Pix4dDataset Before Refinement
    • Once desired outputs are exported these files can easily be deleted using the end descriptor to save space
    • See Data Processing Software for discussion on data processing software

• Outline of suggested file format naming:

  • Project/Customer
    • Platform
      • Date, Location, Sensor (if same sensor was used for all flights that day)
        • Altitude
        • GCP
          • Sensor
            • Raw
            • JPEG
            • Video
            • Exports
            • ...
  • This is a good example for organizing data in which data from different platforms have different applications, and different sensors that may be flown at different altitudes on one day at one location. File formatting should be made standard across all projects and naming conventions should make sense so that someone outside of the project could go in and locate a specific data set.

---

Flight Operations

(The following are best practices for preparing and conducting flight operations in regards to collecting quality data. Legal requirements and safety concerns for flight operations are not addressed.)

• Tips for preparing flight ops:

  • Week of:

    • Ensure all batteries are fully charged (flight batteries, payload batteries, computer/other electronics to be used)
    • Make sure flight crew is properly trained and understands the mission
    • Determine flight boundaries; create the flight plan if possible
    • Generally, 75% overlap and sidelap is a good rule of thumb for data collection (controlled with the GCS software)
      • More than 85% generally over-saturates data sets and is unnecessary to stitch together a model, but this is dependent on the application
      • It is good practice to trigger the camera by distance (rather than by time), which is often determined by the GCS software based upon the mission altitude, overlap parameters, and sensor
        • This is mostly because, even though you can control the speed of your mission, sometimes the UAV can be impacted by the wind, or it can sit at one waypoint waiting to find its location, and that can over-saturate your data set
      • Ensure to save the flight plan under a naming convention that will easily distinguish between other flight operations (Include flight location, sensor type, altitude, etc.)
      • See Sensor Triggering Settings for more discussion over selecting overlap/sidelap and triggering practices
    • Determine the plan for geotagging
      • If Ground Control Points (GCPs) will be used, use Google Earth to determine where they will be placed
        • Good practice is to space them evenly about 150-200 meters apart and ensuring that they are not all in a straight line
        • Drop pins roughly where the GCPs should be located, and use the measuring tool to space them approximately 150 meters apart
        • Screenshot the image created and give to the flight crew that will be placing them during the mission as a guide
      • See Georeferencing Data for more discussion on other ways to georeferencing data sets
    • Clear SD cards (or other data storage devices) that will be used
    • Determine what sensor/platform is most appropriate for the mission requirements and field size
      • Make sure no major software/hardware changes have been made without a test flight before operations

  • Day before:

    • Double-check all batteries
    • Get together all equipment to be used to be easily loaded for the next day
      • Creating and following checklists are a good way to make sure nothing is forgotten

• Tips for conducting flight operations:

  • Workflow for GCP collection (this process can vary depending on location size and personal preference, see GCP Collection for more discussion):
    • Set up surveying equipment
      • Other tasks can be done while waiting for the survey equipment to find its exact location, such as calibrating the sensor or setting up the aircraft
    • Once the surveying equipment is ready, start placing GCPs and tagging them immediately after they are placed
      • GCPs can also be placed before the flight and tagged after, but if the field is large sometimes it is better to tag them right after they are placed so that they are not lost or skipped over during the tagging process
    • Leave the GCPs in the field during flight, and pick them up after good data collection is assured
  • Make sure to calibrate the sensor based on mission requirements before installing it on the platform
  • Ensure an SD card is properly installed in the camera
  • Set parameters in the GCS to have the camera start triggering at the first waypoint and stop at the last to avoid the collection of unnecessary data during takeoff and landing
    • This process will be different for all kinds of GCS software, and some automatically do this
  • Before takeoff, use the Ground Control Station (GCS) software to manually trigger the camera, and listen for the shutter to ensure the camera is properly connected and triggering
  • After each flight, check the SD card immediately to make sure there are approximately the number of pictures on there that you would expect
  • Copy the pictures from the SD card to a field processing laptop to begin a low align on the data collected to ensure there are no gaps or holes
    • Never delete the raw images from the SD card until they are copied onto at least 2 backup locations
  • Do this for every flight for the day, and do not leave the location until the data is verified if possible