Find research datasets worth reusing
Search datasets from major research repositories and use ShareScore to quickly assess how well each record supports discovery, access, and reuse.
1,308
datasets available to search
ShareScore release 0.9.0
Dataset results
1,308 results for “Vehicle”
Underwater images collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10
<i>This dataset was collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10.</i> <br> <br><br>Underwater or aerial images collected by scientists or citizens can have a wide variety of use for science, management, or conservation. These images can be annotated and shared to train IA models which can in turn predict the objects on the images. We provide a set of tools (hardware and software) to collect marine data, predict species or habitat, and provide maps.<br><br> This dataset is part of larger collection referencing numerous underwater and aerial images <a href="https://doi.org/10.5281/zenodo.11125847" target="_blank">Seatizen Altas</a>. Methods, tools and scientific objectives are also described in a dedicated data paper.<br> <h2>Image acquisition</h2> This session has 21.7 GB of MP4 files, which were trimmed into 6405 frames (at 2997/1000 fps). <br> The frames are georeferenced. <br> 100.0% of these extracted images are useful and 0.0% are useless, according to predictions made by <a href="jacques-v0.1.0_model-20240513_v20.0" target="_blank">Jacques model</a>. <br> Multilabel predictions have been made on useful frames using <a href="https://huggingface.co/lombardata/DinoVdeau-large-2024_04_03-with_data_aug_batch-size32_epochs150_freeze" target="_blank">DinoVd'eau</a> model. <br> <h2> GPS information: </h2> The data was processed with a PPK workflow to achieve centimeter-level GPS accuracy. <br> Base : Files coming from rtk a GPS-fixed station or any static positioning instrument which can provide with correction frames. <br> Device GPS : Emlid Reach M2 <br> Quality of our data - Q1: 93.23 %, Q2: 5.78 %, Q5: 0.98 % <br> <h2> Bathymetry </h2> The data are collected using a single-beam echosounder <a href="https://www.echologger.com/products/single-frequency-echosounder-deep" target="_blank">ETC 400</a>. <br> We only keep the values which have a GPS correction in Q1.<br> We keep the points that are the waypoints.<br> We keep the raw data where depth was estimated between 0.2 m and 50.0 m deep. <br> The data are first referenced against the WGS84 ellipsoid. Then we apply the local geoid if available.<br> At the end of processing, the data are projected into a homogeneous grid to create a raster and a shapefiles. <br> The size of the grid cells is 0.194 m. <br> The raster and shapefiles are generated by linear interpolation. The 3D reconstruction algorithm is ballpivot. <br> <h2>Photogrammetry</h2> OpenDroneMap software was used to create an orthophoto from the raw images. <br> Here is the list of parameters different from the default values for the orthophoto generation. <br> For more details, you can read the log.json file or the 000_photogrammatry_report.pdf report. <br><br> <code> {'auto_boundary': True, 'cog': True, 'fast_orthophoto': True, 'feature_quality': 'ultra', 'gps_accuracy': 0.1, 'max_concurrency': 44, 'optimize_disk_space': True, 'orthophoto_resolution': 0.1, 'rolling_shutter': True, 'skip_3dmodel': True} </code> <h2> Generic folder structure </h2> YYYYMMDD_COUNTRYCODE-optionalplace_device_session-number <br> ├── DCIM : folder to store videos and photos depending on the media collected. <br> ├── GPS : folder to store any positioning related file. If any kind of correction is possible on files (e.g. Post-Processed Kinematic thanks to rinex data) then the distinction between device data and base data is made. If, on the other hand, only device position data are present and the files cannot be corrected by post-processing techniques (e.g. gpx files), then the distinction between base and device is not made and the files are placed directly at the root of the GPS folder. <br> │ ├── BASE : files coming from rtk station or any static positioning instrument. <br> │ └── DEVICE : files coming from the device. <br> ├── METADATA : folder with general information files about the session. <br> ├── PROCESSED_DATA : contain all the folders needed to store the results of the data processing of the current session. <br> │ ├── BATHY : output folder for bathymetry raw data extracted from mission logs. <br> │ ├── FRAMES : output folder for georeferenced frames extracted from DCIM videos. <br> │ ├── IA : destination folder for image recognition predictions. <br> │ └── PHOTOGRAMMETRY : destination folder for reconstructed models in photogrammetry. <br> └── SENSORS : folder to store files coming from other sources (bathymetry data from the echosounder, log file from the autopilot, mission plan etc.). <br> <h2> Software </h2> All the raw data was processed using our <a href="https://github.com/SeatizenDOI/plancha-workflow/releases/tag/v1.0.3" target="_blank">worflow</a>. <br>All predictions were generated by our <a href="https://github.com/SeatizenDOI/plancha-inference/releases/tag/v1.0.0" target="_blank">inference pipeline</a>. <br>You can find all the necessary scripts to download this data in this <a href="https://github.com/SeatizenDOI/zenodo-tools" target="_blank">repository</a>. <br>Enjoy your data with <a href="https://github.com/SeatizenDOI" target="_blank">SeatizenDOI</a>! <br>
Underwater images collected by an Autonomous Surface Vehicle in Boucan, Réunion - 2023-11-21
<i>This dataset was collected by an Autonomous Surface Vehicle in Boucan, Réunion - 2023-11-21.</i> <br> <br><br>Underwater or aerial images collected by scientists or citizens can have a wide variety of use for science, management, or conservation. These images can be annotated and shared to train IA models which can in turn predict the objects on the images. We provide a set of tools (hardware and software) to collect marine data, predict species or habitat, and provide maps.<br><br> This dataset is part of larger collection referencing numerous underwater and aerial images <a href="https://doi.org/10.5281/zenodo.11125847" target="_blank">Seatizen Altas</a>. Methods, tools and scientific objectives are also described in a dedicated data paper.<br> <h2>Image acquisition</h2> This session has 24.03 GB of MP4 files, which were trimmed into 8608 frames (at 2997/1000 fps). <br> The frames are georeferenced. <br> 97.19% of these extracted images are useful and 2.81% are useless, according to predictions made by <a href="jacques-v0.1.0_model-20240513_v20.0" target="_blank">Jacques model</a>. <br> Multilabel predictions have been made on useful frames using <a href="https://huggingface.co/lombardata/DinoVdeau-large-2024_04_03-with_data_aug_batch-size32_epochs150_freeze" target="_blank">DinoVd'eau</a> model. <br> <h2> GPS information: </h2> The data was processed with a PPK workflow to achieve centimeter-level GPS accuracy. <br> Base : Files coming from rtk a GPS-fixed station or any static positioning instrument which can provide with correction frames. <br> Device GPS : Emlid Reach M2 <br> Quality of our data - Q1: 91.99 %, Q2: 7.07 %, Q5: 0.94 % <br> <h2> Bathymetry </h2> The data are collected using a single-beam echosounder <a href="https://www.echologger.com/products/single-frequency-echosounder-deep" target="_blank">ETC 400</a>. <br> We only keep the values which have a GPS correction in Q1.<br> We keep the points that are the waypoints.<br> We keep the raw data where depth was estimated between 0.2 m and 50.0 m deep. <br> The data are first referenced against the WGS84 ellipsoid. Then we apply the local geoid if available.<br> At the end of processing, the data are projected into a homogeneous grid to create a raster and a shapefiles. <br> The size of the grid cells is 0.434 m. <br> The raster and shapefiles are generated by linear interpolation. The 3D reconstruction algorithm is ballpivot. <br> <h2>Photogrammetry</h2> OpenDroneMap software was used to create an orthophoto from the raw images. <br> Here is the list of parameters different from the default values for the orthophoto generation. <br> For more details, you can read the log.json file or the 000_photogrammatry_report.pdf report. <br><br> <code> {'auto_boundary': True, 'cog': True, 'fast_orthophoto': True, 'feature_quality': 'ultra', 'gps_accuracy': 0.1, 'max_concurrency': 50, 'optimize_disk_space': True, 'orthophoto_resolution': 0.1, 'rolling_shutter': True, 'skip_3dmodel': True} </code> <h2> Generic folder structure </h2> YYYYMMDD_COUNTRYCODE-optionalplace_device_session-number <br> ├── DCIM : folder to store videos and photos depending on the media collected. <br> ├── GPS : folder to store any positioning related file. If any kind of correction is possible on files (e.g. Post-Processed Kinematic thanks to rinex data) then the distinction between device data and base data is made. If, on the other hand, only device position data are present and the files cannot be corrected by post-processing techniques (e.g. gpx files), then the distinction between base and device is not made and the files are placed directly at the root of the GPS folder. <br> │ ├── BASE : files coming from rtk station or any static positioning instrument. <br> │ └── DEVICE : files coming from the device. <br> ├── METADATA : folder with general information files about the session. <br> ├── PROCESSED_DATA : contain all the folders needed to store the results of the data processing of the current session. <br> │ ├── BATHY : output folder for bathymetry raw data extracted from mission logs. <br> │ ├── FRAMES : output folder for georeferenced frames extracted from DCIM videos. <br> │ ├── IA : destination folder for image recognition predictions. <br> │ └── PHOTOGRAMMETRY : destination folder for reconstructed models in photogrammetry. <br> └── SENSORS : folder to store files coming from other sources (bathymetry data from the echosounder, log file from the autopilot, mission plan etc.). <br> <h2> Software </h2> All the raw data was processed using our <a href="https://github.com/SeatizenDOI/plancha-workflow/releases/tag/v1.0.3" target="_blank">worflow</a>. <br>All predictions were generated by our <a href="https://github.com/SeatizenDOI/plancha-inference/releases/tag/v1.0.0" target="_blank">inference pipeline</a>. <br>You can find all the necessary scripts to download this data in this <a href="https://github.com/SeatizenDOI/zenodo-tools" target="_blank">repository</a>. <br>Enjoy your data with <a href="https://github.com/SeatizenDOI" target="_blank">SeatizenDOI</a>! <br>
Underwater images collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10
<i>This dataset was collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10.</i> <br> <br><br>Underwater or aerial images collected by scientists or citizens can have a wide variety of use for science, management, or conservation. These images can be annotated and shared to train IA models which can in turn predict the objects on the images. We provide a set of tools (hardware and software) to collect marine data, predict species or habitat, and provide maps.<br><br> This dataset is part of larger collection referencing numerous underwater and aerial images <a href="https://doi.org/10.5281/zenodo.11125847" target="_blank">Seatizen Altas</a>. Methods, tools and scientific objectives are also described in a dedicated data paper.<br> <h2>Image acquisition</h2> This session has 29.72 GB of MP4 files, which were trimmed into 7720 frames (at 2997/1000 fps). <br> The frames are georeferenced. <br> 99.77% of these extracted images are useful and 0.23% are useless, according to predictions made by <a href="jacques-v0.1.0_model-20240513_v20.0" target="_blank">Jacques model</a>. <br> Multilabel predictions have been made on useful frames using <a href="https://huggingface.co/lombardata/DinoVdeau-large-2024_04_03-with_data_aug_batch-size32_epochs150_freeze" target="_blank">DinoVd'eau</a> model. <br> <h2> GPS information: </h2> The data was processed with a PPK workflow to achieve centimeter-level GPS accuracy. <br> Base : Files coming from rtk a GPS-fixed station or any static positioning instrument which can provide with correction frames. <br> Device GPS : Emlid Reach M2 <br> Quality of our data - Q1: 80.53 %, Q2: 14.66 %, Q5: 4.81 % <br> <h2> Bathymetry </h2> The data are collected using a single-beam echosounder <a href="https://www.echologger.com/products/single-frequency-echosounder-deep" target="_blank">ETC 400</a>. <br> We only keep the values which have a GPS correction in Q1.<br> We keep the points that are the waypoints.<br> We keep the raw data where depth was estimated between 0.2 m and 50.0 m deep. <br> The data are first referenced against the WGS84 ellipsoid. Then we apply the local geoid if available.<br> At the end of processing, the data are projected into a homogeneous grid to create a raster and a shapefiles. <br> The size of the grid cells is 0.19 m. <br> The raster and shapefiles are generated by linear interpolation. The 3D reconstruction algorithm is ballpivot. <br> <h2>Photogrammetry</h2> OpenDroneMap software was used to create an orthophoto from the raw images. <br> Here is the list of parameters different from the default values for the orthophoto generation. <br> For more details, you can read the log.json file or the 000_photogrammatry_report.pdf report. <br><br> <code> {'auto_boundary': True, 'cog': True, 'fast_orthophoto': True, 'feature_quality': 'ultra', 'gps_accuracy': 0.1, 'max_concurrency': 44, 'optimize_disk_space': True, 'orthophoto_resolution': 0.1, 'rolling_shutter': True, 'skip_3dmodel': True} </code> <h2> Generic folder structure </h2> YYYYMMDD_COUNTRYCODE-optionalplace_device_session-number <br> ├── DCIM : folder to store videos and photos depending on the media collected. <br> ├── GPS : folder to store any positioning related file. If any kind of correction is possible on files (e.g. Post-Processed Kinematic thanks to rinex data) then the distinction between device data and base data is made. If, on the other hand, only device position data are present and the files cannot be corrected by post-processing techniques (e.g. gpx files), then the distinction between base and device is not made and the files are placed directly at the root of the GPS folder. <br> │ ├── BASE : files coming from rtk station or any static positioning instrument. <br> │ └── DEVICE : files coming from the device. <br> ├── METADATA : folder with general information files about the session. <br> ├── PROCESSED_DATA : contain all the folders needed to store the results of the data processing of the current session. <br> │ ├── BATHY : output folder for bathymetry raw data extracted from mission logs. <br> │ ├── FRAMES : output folder for georeferenced frames extracted from DCIM videos. <br> │ ├── IA : destination folder for image recognition predictions. <br> │ └── PHOTOGRAMMETRY : destination folder for reconstructed models in photogrammetry. <br> └── SENSORS : folder to store files coming from other sources (bathymetry data from the echosounder, log file from the autopilot, mission plan etc.). <br> <h2> Software </h2> All the raw data was processed using our <a href="https://github.com/SeatizenDOI/plancha-workflow/releases/tag/v1.0.3" target="_blank">worflow</a>. <br>All predictions were generated by our <a href="https://github.com/SeatizenDOI/plancha-inference/releases/tag/v1.0.0" target="_blank">inference pipeline</a>. <br>You can find all the necessary scripts to download this data in this <a href="https://github.com/SeatizenDOI/zenodo-tools" target="_blank">repository</a>. <br>Enjoy your data with <a href="https://github.com/SeatizenDOI" target="_blank">SeatizenDOI</a>! <br>
Underwater images collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10
<i>This dataset was collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10.</i> <br> <br><br>Underwater or aerial images collected by scientists or citizens can have a wide variety of use for science, management, or conservation. These images can be annotated and shared to train IA models which can in turn predict the objects on the images. We provide a set of tools (hardware and software) to collect marine data, predict species or habitat, and provide maps.<br><br> This dataset is part of larger collection referencing numerous underwater and aerial images <a href="https://doi.org/10.5281/zenodo.11125847" target="_blank">Seatizen Altas</a>. Methods, tools and scientific objectives are also described in a dedicated data paper.<br> <h2>Image acquisition</h2> This session has 27.62 GB of MP4 files, which were trimmed into 8922 frames (at 2997/1000 fps). <br> The frames are georeferenced. <br> 100.0% of these extracted images are useful and 0.0% are useless, according to predictions made by <a href="jacques-v0.1.0_model-20240513_v20.0" target="_blank">Jacques model</a>. <br> Multilabel predictions have been made on useful frames using <a href="https://huggingface.co/lombardata/DinoVdeau-large-2024_04_03-with_data_aug_batch-size32_epochs150_freeze" target="_blank">DinoVd'eau</a> model. <br> <h2> GPS information: </h2> The data was processed with a PPK workflow to achieve centimeter-level GPS accuracy. <br> Base : Files coming from rtk a GPS-fixed station or any static positioning instrument which can provide with correction frames. <br> Device GPS : Emlid Reach M2 <br> Quality of our data - Q1: 96.0 %, Q2: 3.92 %, Q5: 0.08 % <br> <h2> Bathymetry </h2> The data are collected using a single-beam echosounder <a href="https://ceruleansonar.com/products/sounder-s500" target="_blank">S500</a>. <br> We only keep the values which have a GPS correction in Q1.<br> We keep the points that are the waypoints.<br> We keep the raw data where depth was estimated between 0.2 m and 50.0 m deep. <br> The data are first referenced against the WGS84 ellipsoid. Then we apply the local geoid if available.<br> At the end of processing, the data are projected into a homogeneous grid to create a raster and a shapefiles. <br> The size of the grid cells is 0.444 m. <br> The raster and shapefiles are generated by linear interpolation. The 3D reconstruction algorithm is ballpivot. <br> <h2>Photogrammetry</h2> OpenDroneMap software was used to create an orthophoto from the raw images. <br> Here is the list of parameters different from the default values for the orthophoto generation. <br> For more details, you can read the log.json file or the 000_photogrammatry_report.pdf report. <br><br> <code> {'auto_boundary': True, 'cog': True, 'fast_orthophoto': True, 'feature_quality': 'ultra', 'gps_accuracy': 0.1, 'max_concurrency': 50, 'optimize_disk_space': True, 'orthophoto_resolution': 0.1, 'rolling_shutter': True, 'skip_3dmodel': True} </code> <h2> Generic folder structure </h2> YYYYMMDD_COUNTRYCODE-optionalplace_device_session-number <br> ├── DCIM : folder to store videos and photos depending on the media collected. <br> ├── GPS : folder to store any positioning related file. If any kind of correction is possible on files (e.g. Post-Processed Kinematic thanks to rinex data) then the distinction between device data and base data is made. If, on the other hand, only device position data are present and the files cannot be corrected by post-processing techniques (e.g. gpx files), then the distinction between base and device is not made and the files are placed directly at the root of the GPS folder. <br> │ ├── BASE : files coming from rtk station or any static positioning instrument. <br> │ └── DEVICE : files coming from the device. <br> ├── METADATA : folder with general information files about the session. <br> ├── PROCESSED_DATA : contain all the folders needed to store the results of the data processing of the current session. <br> │ ├── BATHY : output folder for bathymetry raw data extracted from mission logs. <br> │ ├── FRAMES : output folder for georeferenced frames extracted from DCIM videos. <br> │ ├── IA : destination folder for image recognition predictions. <br> │ └── PHOTOGRAMMETRY : destination folder for reconstructed models in photogrammetry. <br> └── SENSORS : folder to store files coming from other sources (bathymetry data from the echosounder, log file from the autopilot, mission plan etc.). <br> <h2> Software </h2> All the raw data was processed using our <a href="https://github.com/SeatizenDOI/plancha-workflow/releases/tag/v1.0.3" target="_blank">worflow</a>. <br>All predictions were generated by our <a href="https://github.com/SeatizenDOI/plancha-inference/releases/tag/v1.0.0" target="_blank">inference pipeline</a>. <br>You can find all the necessary scripts to download this data in this <a href="https://github.com/SeatizenDOI/zenodo-tools" target="_blank">repository</a>. <br>Enjoy your data with <a href="https://github.com/SeatizenDOI" target="_blank">SeatizenDOI</a>! <br>
Underwater images collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10
<i>This dataset was collected by an Autonomous Surface Vehicle in St-Leu, Réunion - 2023-11-10.</i> <br> <br><br>Underwater or aerial images collected by scientists or citizens can have a wide variety of use for science, management, or conservation. These images can be annotated and shared to train IA models which can in turn predict the objects on the images. We provide a set of tools (hardware and software) to collect marine data, predict species or habitat, and provide maps.<br><br> This dataset is part of larger collection referencing numerous underwater and aerial images <a href="https://doi.org/10.5281/zenodo.11125847" target="_blank">Seatizen Altas</a>. Methods, tools and scientific objectives are also described in a dedicated data paper.<br> <h2>Image acquisition</h2> This session has 32.67 GB of MP4 files, which were trimmed into 9381 frames (at 2997/1000 fps). <br> The frames are georeferenced. <br> 98.32% of these extracted images are useful and 1.68% are useless, according to predictions made by <a href="jacques-v0.1.0_model-20240513_v20.0" target="_blank">Jacques model</a>. <br> Multilabel predictions have been made on useful frames using <a href="https://huggingface.co/lombardata/DinoVdeau-large-2024_04_03-with_data_aug_batch-size32_epochs150_freeze" target="_blank">DinoVd'eau</a> model. <br> <h2> GPS information: </h2> The data was processed with a PPK workflow to achieve centimeter-level GPS accuracy. <br> Base : Files coming from rtk a GPS-fixed station or any static positioning instrument which can provide with correction frames. <br> Device GPS : Emlid Reach M2 <br> Quality of our data - Q1: 97.14 %, Q2: 2.84 %, Q5: 0.03 % <br> <h2> Bathymetry </h2> The data are collected using a single-beam echosounder <a href="https://ceruleansonar.com/products/sounder-s500" target="_blank">S500</a>. <br> We only keep the values which have a GPS correction in Q1.<br> We keep the points that are the waypoints.<br> We keep the raw data where depth was estimated between 0.2 m and 50.0 m deep. <br> The data are first referenced against the WGS84 ellipsoid. Then we apply the local geoid if available.<br> At the end of processing, the data are projected into a homogeneous grid to create a raster and a shapefiles. <br> The size of the grid cells is 0.27 m. <br> The raster and shapefiles are generated by linear interpolation. The 3D reconstruction algorithm is ballpivot. <br> <h2>Photogrammetry</h2> OpenDroneMap software was used to create an orthophoto from the raw images. <br> Here is the list of parameters different from the default values for the orthophoto generation. <br> For more details, you can read the log.json file or the 000_photogrammatry_report.pdf report. <br><br> <code> {'auto_boundary': True, 'cog': True, 'fast_orthophoto': True, 'feature_quality': 'ultra', 'gps_accuracy': 0.1, 'max_concurrency': 50, 'optimize_disk_space': True, 'orthophoto_resolution': 0.1, 'rolling_shutter': True, 'skip_3dmodel': True} </code> <h2> Generic folder structure </h2> YYYYMMDD_COUNTRYCODE-optionalplace_device_session-number <br> ├── DCIM : folder to store videos and photos depending on the media collected. <br> ├── GPS : folder to store any positioning related file. If any kind of correction is possible on files (e.g. Post-Processed Kinematic thanks to rinex data) then the distinction between device data and base data is made. If, on the other hand, only device position data are present and the files cannot be corrected by post-processing techniques (e.g. gpx files), then the distinction between base and device is not made and the files are placed directly at the root of the GPS folder. <br> │ ├── BASE : files coming from rtk station or any static positioning instrument. <br> │ └── DEVICE : files coming from the device. <br> ├── METADATA : folder with general information files about the session. <br> ├── PROCESSED_DATA : contain all the folders needed to store the results of the data processing of the current session. <br> │ ├── BATHY : output folder for bathymetry raw data extracted from mission logs. <br> │ ├── FRAMES : output folder for georeferenced frames extracted from DCIM videos. <br> │ ├── IA : destination folder for image recognition predictions. <br> │ └── PHOTOGRAMMETRY : destination folder for reconstructed models in photogrammetry. <br> └── SENSORS : folder to store files coming from other sources (bathymetry data from the echosounder, log file from the autopilot, mission plan etc.). <br> <h2> Software </h2> All the raw data was processed using our <a href="https://github.com/SeatizenDOI/plancha-workflow/releases/tag/v1.0.3" target="_blank">worflow</a>. <br>All predictions were generated by our <a href="https://github.com/SeatizenDOI/plancha-inference/releases/tag/v1.0.0" target="_blank">inference pipeline</a>. <br>You can find all the necessary scripts to download this data in this <a href="https://github.com/SeatizenDOI/zenodo-tools" target="_blank">repository</a>. <br>Enjoy your data with <a href="https://github.com/SeatizenDOI" target="_blank">SeatizenDOI</a>! <br>
Underwater images collected by an Autonomous Surface Vehicle in Boucan, Réunion - 2023-11-22
<i>This dataset was collected by an Autonomous Surface Vehicle in Boucan, Réunion - 2023-11-22.</i> <br> <br><br>Underwater or aerial images collected by scientists or citizens can have a wide variety of use for science, management, or conservation. These images can be annotated and shared to train IA models which can in turn predict the objects on the images. We provide a set of tools (hardware and software) to collect marine data, predict species or habitat, and provide maps.<br><br> This dataset is part of larger collection referencing numerous underwater and aerial images <a href="https://doi.org/10.5281/zenodo.11125847" target="_blank">Seatizen Altas</a>. Methods, tools and scientific objectives are also described in a dedicated data paper.<br> <h2>Image acquisition</h2> This session has 16.13 GB of MP4 files, which were trimmed into 6058 frames (at 2997/1000 fps). <br> The frames are georeferenced. <br> 99.75% of these extracted images are useful and 0.25% are useless, according to predictions made by <a href="jacques-v0.1.0_model-20240513_v20.0" target="_blank">Jacques model</a>. <br> Multilabel predictions have been made on useful frames using <a href="https://huggingface.co/lombardata/DinoVdeau-large-2024_04_03-with_data_aug_batch-size32_epochs150_freeze" target="_blank">DinoVd'eau</a> model. <br> <h2> GPS information: </h2> The data was processed with a PPK workflow to achieve centimeter-level GPS accuracy. <br> Base : Files coming from rtk a GPS-fixed station or any static positioning instrument which can provide with correction frames. <br> Device GPS : Emlid Reach M2 <br> Quality of our data - Q1: 94.03 %, Q2: 5.19 %, Q5: 0.78 % <br> <h2> Bathymetry </h2> The data are collected using a single-beam echosounder <a href="https://www.echologger.com/products/single-frequency-echosounder-deep" target="_blank">ETC 400</a>. <br> We only keep the values which have a GPS correction in Q1.<br> We keep the points that are the waypoints.<br> We keep the raw data where depth was estimated between 0.2 m and 50.0 m deep. <br> The data are first referenced against the WGS84 ellipsoid. Then we apply the local geoid if available.<br> At the end of processing, the data are projected into a homogeneous grid to create a raster and a shapefiles. <br> The size of the grid cells is 0.493 m. <br> The raster and shapefiles are generated by linear interpolation. The 3D reconstruction algorithm is ballpivot. <br> <h2>Photogrammetry</h2> OpenDroneMap software was used to create an orthophoto from the raw images. <br> Here is the list of parameters different from the default values for the orthophoto generation. <br> For more details, you can read the log.json file or the 000_photogrammatry_report.pdf report. <br><br> <code> {'auto_boundary': True, 'cog': True, 'fast_orthophoto': True, 'feature_quality': 'ultra', 'gps_accuracy': 0.1, 'max_concurrency': 44, 'optimize_disk_space': True, 'orthophoto_resolution': 0.1, 'rolling_shutter': True, 'skip_3dmodel': True} </code> <h2> Generic folder structure </h2> YYYYMMDD_COUNTRYCODE-optionalplace_device_session-number <br> ├── DCIM : folder to store videos and photos depending on the media collected. <br> ├── GPS : folder to store any positioning related file. If any kind of correction is possible on files (e.g. Post-Processed Kinematic thanks to rinex data) then the distinction between device data and base data is made. If, on the other hand, only device position data are present and the files cannot be corrected by post-processing techniques (e.g. gpx files), then the distinction between base and device is not made and the files are placed directly at the root of the GPS folder. <br> │ ├── BASE : files coming from rtk station or any static positioning instrument. <br> │ └── DEVICE : files coming from the device. <br> ├── METADATA : folder with general information files about the session. <br> ├── PROCESSED_DATA : contain all the folders needed to store the results of the data processing of the current session. <br> │ ├── BATHY : output folder for bathymetry raw data extracted from mission logs. <br> │ ├── FRAMES : output folder for georeferenced frames extracted from DCIM videos. <br> │ ├── IA : destination folder for image recognition predictions. <br> │ └── PHOTOGRAMMETRY : destination folder for reconstructed models in photogrammetry. <br> └── SENSORS : folder to store files coming from other sources (bathymetry data from the echosounder, log file from the autopilot, mission plan etc.). <br> <h2> Software </h2> All the raw data was processed using our <a href="https://github.com/SeatizenDOI/plancha-workflow/releases/tag/v1.0.3" target="_blank">worflow</a>. <br>All predictions were generated by our <a href="https://github.com/SeatizenDOI/plancha-inference/releases/tag/v1.0.0" target="_blank">inference pipeline</a>. <br>You can find all the necessary scripts to download this data in this <a href="https://github.com/SeatizenDOI/zenodo-tools" target="_blank">repository</a>. <br>Enjoy your data with <a href="https://github.com/SeatizenDOI" target="_blank">SeatizenDOI</a>! <br>
NO2 levels inside vehicle cabins with pollen and activated carbon filters: A real world targeted intervention to estimate NO2 exposure reduction potential
<p>In-vehicle and on-road (ambient) NO<sub>2</sub> measurements in different car cabin from Birmingham, UK. This dataset was used for the publication NO2 levels inside vehicle cabins with pollen and activated carbon filters: A real world targeted intervention to estimate NO<sub>2</sub> exposure reduction potential, Science of The total environment,160395 <a href="https://doi.org/10.1016/j.scitotenv.2022.160395">https://doi.org/10.1016/j.scitotenv.2022.160395</a></p>
Wildlife–vehicle collisions (WVC) on interurban roads in Spain (2016-2021)
<p>CSV that contains 1.000 records of wildlife–vehicle collisions (WVC) on interurban roads in Spain between 2016 and 2021. If you are interested in the whole country dataset, please do not hesitate to <strong>contact me and I will forward it to you</strong>. </p> <p>Data source of each WVC record is the Spanish General Directorate of Traffic (DGT), but the dataset has been enhanced by the integration of other sources: OpenStreetMap (OSM), Global Biodiversity Information Facility (GBIF), the National Geographic Institute of Spain (IGN), State Meteorological Agency (AEMET).Therefore, each record describes an accident by the following fields:</p> <p>• <strong>id_num </strong>(int8): the unique identifier for an accident.<br> • <strong>ind_accda </strong>(int8): a binary variable for property damages involved or not (encoded).<br> • <strong>nombre_ind_accd </strong>(str): a statement for property damages involved or not (decoded).<br> • <strong>ind_acciv </strong>(int8): a binary variable for personal damages involved or not (encoded).<br> • <strong>nombre_ind_acciv </strong>(str): a statement for personal damages involved or not (decoded).<br> • <strong>total_mu30df </strong>(int8): the total number of deaths from the accident.<br> • <strong>total_hg30df </strong>(int8): the total number of injured with hospitalization from the accident.<br> • <strong>total_hl30df </strong>(int8): the total number of injured without hospitalization from the accident.<br> • <strong>fecha_accidente </strong>(date): the reported date of the collision, following ISO 8601 date-time standard. <br> • <strong>hora_accidente </strong>(str): the reported hour of the collision in 24-hour notation. <br> • <strong>mes_1f </strong>(int8): the month as integer of the event date (encoded).<br> • <strong>nombre_mes </strong>(str): the month name of the event date (decoded).<br> • <strong>anyo </strong>(int8): the four-digit year of the event date.<br> • <strong>ccaa_1f </strong>(int8): the autonomous region code from INE where accident is registered (encoded).<br> • <strong>nombre_ccaa </strong>(str): the name of the autonomous region where accident is registered (decoded).<br> • <strong>provincia_1f </strong>(int8): the province code from INE where the accident is registered (encoded).<br> • <strong>nombre_provincia </strong>(str): the province name where the accident is registered (decoded).<br> • <strong>cod_municipio </strong>(int8): the municipality code from INE where the accident is registered (encoded).<br> • <strong>nombre_municipio </strong>(str): the municipality name where the accident is registered (decoded).<br> • <strong>carretera </strong>(str): the road attending to the national road numbering system in Spain where the accident is located.<br> • <strong>km </strong>(float): the kilometre point of the road where the accident is located.<br> • <strong>sentido_1f </strong>(int8): the vehicle’s direction of traffic reported as integer when the accident occurred (encoded).<br> • <strong>nombre_sentido </strong>(str): the vehicle’s direction of traffic reported when the accident occurred (decoded).<br> • <strong>tipo_via_3f </strong>(int8): the type of road as integer attending to the project road classification (encoded).<br> • <strong>nombre_tipo_via </strong>(str): the type of road description attending to the project road classification (decoded).<br> • <strong>titularidad_via_2f </strong>(int8): the road ownership type as integer (encoded).<br> • <strong>nombre_titularidad_via </strong>(str): the road ownership type description (decoded).<br> • <strong>tipo_animal_1f </strong>(int8): the animal species involved in the accident as integer (encoded).<br> • <strong>nombre_tipo_animal_1f </strong>(str): the animal species name involved in the accident (decoded).<br> • <strong>tipo_animal_2f </strong>(int8): the reported animal type of breeding as integer (encoded).<br> • <strong>nombre_tipo_animal_2f </strong>(str): the type of animal breeding description (decoded).<br> • <strong>longitud </strong>(float): the length of the accident location coordinate in decimal degrees.<br> • <strong>latitud </strong>(float): the latitude of the accident location coordinate in decimal degrees.<br> • <strong>geom </strong>(geometry): geometry from latitude and longitude position. Developed for this project.<br> • <strong>dia_semana </strong>(int8): the integer day of the week when the accident occurred (encoded).<br> • <strong>nombre_dia_semana </strong>(str): the name of the day when the accident occurred (decoded).<br> • <strong>tipo_dia </strong>(str): the category name of the day type to separate weekday from weekend (decoded).<br> • <strong>parte_dia </strong>(str): the part name of the day when the accident is registered including day, night and the transitions.<br> • <strong>luna </strong>(int8): the portion of illuminated moon surface represented as an integer value from 0 to 100.<br> • <strong>prec </strong>(float): the daily rainfall measurement of the event day based on pluviometric days.<br> • <strong>tmin </strong>(float): the minimum temperature in Celsius of the event day.<br> • <strong>tmed </strong>(float): the average temperature in Celsius of the event day.<br> • <strong>tmax</strong> (float): the maximum temperature in Celsius of the event day.<br> • <strong>sol </strong>(float): the accumulated sun hours of the event day.<br> • <strong>uso_suelo </strong>(str): the main land usage of the accident area.<br> • <strong>altitud </strong>(float): the altitude in meters above sea level.<br> • <strong>pendiente </strong>(float): the slope median value of a 30 meters buffer around the accident location.<br> • <strong>taxonkey</strong> (str): a taxon key from the GBIF backbone.<br> • <strong>imd_total </strong>(float): the average daily traffic intensity of the accident year.<br> • <strong>maxspeed </strong>(int): the maximum speed of the road section where the reported collision.</p> <p>The context is the Final Master's Degree Project 'Analysis and Predictive Modelling of Wildlife–Vehicle Collision on Interurban Roads in Spain' (Data Science Master’s Degree of Universitat Oberta de Catalunya - UOC).</p> <p>This dataset is the output of the wildlife–vehicle collision analysis and the <a href="https://github.com/alba620/analisis-prediccion-accidentes-trafico-animales">code repository</a> is available on GitHub.</p>
Lithium-Ion Batteries in Automated Guided Vehicles (AGVs) dataset for article "Automated Battery Power Fade Estimation for Fast Charge and Discharge Operations"
<p>Dataset of aggregated information related to discharge-only cycles of lithium-ion battery packs employed in Automated Guided Vehicle systems.</p> <p>The dataset supports the study in conference article "Automated Battery Power Fade Estimation for Fast Charge and Discharge Operations"</p>
Life cycle inventories for on-road vehicles
<p>Life cycle inventory datasets for current on-road vehicles in Switzerland and Europe. These datasets can be consumed by brightway2 (https://brightway.dev/) and Simapro 9.x (https://simapro.com/), and link to either ecoinvent 3.6 (cut-off), ecoinvent 3.7.1 (cut-off), ecoinvent 3.8 (cut-off), ecoinvent 3.9 (cut-off) or UVEK:2018.</p> <p>These datasets can be cited as:</p> <p>Sacchi, R., Bauer, C. (2023) Life cycle inventories for on-road vehicles. Paul Scherrer Institut, Villigen, Switzerland.</p>
Unmanned Aerial Vehicle Image Dataset of the Built Environment for 3D reconstruction (UAVID3D)
<p>Unmanned Aerial Vehicles (UAV) provide increased access to unique types of urban imagery traditionally not available. Advanced machine learning and computer vision techniques when applied to UAV RGB image data can be used for automated extraction of building asset information and if applied to UAV thermal imagery data can detect potential thermal anomalies. However, these UAV datasets are not easily available to researchers, thereby creating a barrier to accelerating research in this area. </p> <p>To assist researchers with added data to develop machine learning algorithms, we present UAVID3D (Unmanned Aerial Vehicle (UAV) Image Dataset of the Built Environment for 3D reconstruction). The raw images for our dataset were recorded with a Zenmuse XT2 visual (RGB) and a FLIR Tau 2 (thermal, https://flir.netx.net/file/asset/15598/original/) camera on a DJI Mavic 2 pro drone (https://www.dji.com/matrice-200-series). The thermal camera is factory calibrated. All data is organized and structured to comply with FAIR principles, i.e. being findable, accessible, interoperable, and reusable. It is publicly available and can be downloaded from the Zenodo data repository. </p> <p>RGB images were recorded during UAV fly-overs of two different commercial buildings in Northern California. In addition, thermographic images were recorded during 2 subsequent UAV fly-overs of the same two buildings. UAV flights were recorded at flight heights between 60–80 m above ground with a flight speed of 1 m s and contain GPS information. All images were recorded during drone flights on May 10, 2021 between 8:45 am and 10:30 am and on May 19, 2021 between 2:15 pm and 4:30 pm. Outdoor air temperatures on these two days during the flights were between 78 and 83 degree fahrenheit and between 58 and 65 degree fahrenheit respectively. </p> <p>For the RGB flights, UAV path was planned and captured using an orbital flight plan in PIX4D capture at normal flight speed and overlap angle of 10 degree. Thermal images were captured by manual flights approximately 5 m away from each building facade. Due to the high overlap of images, similarities from feature points identified in each image can be extracted to conduct photogrammetry. Photogrammetry allows estimation of the three-dimensional coordinates of points on an object in a generated 3D space involving measurements made on images taken with a high overlap rate. Photogrammetry can be used to create a 3D point cloud model of the recorded region. UAVID3D dataset is a series of compressed archive files totaling 21GB. Useful pipelines to process these images can be found at these two repositories <a href="https://github.com/LBNL-ETA/a3dbr">https://github.com/LBNL-ETA/a3dbr</a>, and <a href="https://github.com/LBNL-ETA/AutoBFE">https://github.com/LBNL-ETA/AutoBFE</a></p> <p>This work was supported by the Assistant Secretary for Energy Efficiency and Renewable Energy, Building Technologies Program, of the U.S. Department of Energy under Contract No. DE-AC02-05CH11231. </p> <p> </p> <p> </p>
Livorno, Urban driving, Connected vehicle detects fallen bicyle
<p><strong>Scenario description</strong>:</p> <p>Test session for fallen bicycle with connected but not automated vehicle</p> <p><strong>Session description</strong>:</p> <p>The fallen bicycle use case aims to demonstrate the possibility for a vehicle to detect in advance, using V2X communication, the presence of a fallen bicycle on the road. In case of fall, the bicycle signals its presence to the other vehicles using DENM messages.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Driving in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
Brainport, Automated valet parking, dropoff scenario TNO vehicle
<p><strong>Scenario description</strong>:</p> <p>The AD-vehicle receives parking command message (AutoPilot.VehicleCommand) containing the destination parking spot and the free obstacle route and drives from the drop-off position and parks to the destination parking spot. During the parking process the vehicle send two type of messages (AutoPilot.PositionEstimate and AutoPilot.VehicleAVPStatus)</p> <p><strong>Session description</strong>:</p> <p>The dropoff scenario with TNO vehicle. TNO vehicle parks autonomously from the dropoff location to the selected parking spot at the parking area on the automotive campus.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DroneAvpCommand</strong>: Data sent from drone</p> <p>Dataset Description This dataset contains route information for a vehicle to a designated parking spot</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_ParkingSpotDetection</strong>: Data sent from drone to parkingService</p> <p>Dataset Description This dataset contains informaton about detected parking spots</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed, longitude, latitude, heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystemResampled</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS, resampled to 100 milliseconds</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpCommand</strong>: Data sent from ParkingService to vehicle</p> <p>Dataset Description This dataset contains route to parkingspot, and some other environmental information</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpStatus</strong>: Data sent from vehicle to ParkingService</p> <p>Dataset Description This dataset contains information about the current status and parkingstatus of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Automated valet parking, TNO vehicle, automated pickup
<p><strong>Scenario description</strong>:</p> <p>The AD-vehicle receives parking command message (AutoPilot.VehicleCommand) containing the destination pickup location and the free obstacle route and drives from the parking spot and parks to the destination pickup location. During the collection process the vehicle sends two type of messages (AutoPilot.PositionEstimate and AutoPilot.VehicleAVPStatus)</p> <p><strong>Session description</strong>:</p> <p>The pickup Scenario with TNO vehicle. TNO vehicle parks autonomously from the parking spot to the pickup location at the parking area on the automotive campus.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DroneAvpCommand</strong>: Data sent from drone</p> <p>Dataset Description This dataset contains route information for a vehicle to a designated parking spot</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_ParkingSpotDetection</strong>: Data sent from drone to parkingService</p> <p>Dataset Description This dataset contains informaton about detected parking spots</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed, longitude, latitude, heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystemResampled</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS, resampled to 100 milliseconds</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpCommand</strong>: Data sent from ParkingService to vehicle</p> <p>Dataset Description This dataset contains route to parkingspot, and some other environmental information</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpStatus</strong>: Data sent from vehicle to ParkingService</p> <p>Dataset Description This dataset contains information about the current status and parkingstatus of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Automated valet parking, dropoff scenario, DLR vehicle
<p><strong>Scenario description</strong>:</p> <p>The AD-vehicle receives parking command message (AutoPilot.VehicleCommand) containing the destination parking spot and the free obstacle route and drives from the drop-off position and parks to the destination parking spot. During the parking process the vehicle send two type of messages (AutoPilot.PositionEstimate and AutoPilot.VehicleAVPStatus)</p> <p><strong>Session description</strong>:</p> <p>The dropoff scenario with DLR vehicle. DLR vehicle parks autonomously from the dropoff location to the selected parking spot at the parking area on DLR test area in Brunswick.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DroneAvpCommand</strong>: Data sent from drone</p> <p>Dataset Description This dataset contains route information for a vehicle to a designated parking spot</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_ParkingSpotDetection</strong>: Data sent from drone to parkingService</p> <p>Dataset Description This dataset contains informaton about detected parking spots</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed, longitude, latitude, heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystemResampled</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS, resampled to 100 milliseconds</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpCommand</strong>: Data sent from ParkingService to vehicle</p> <p>Dataset Description This dataset contains route to parkingspot, and some other environmental information</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpStatus</strong>: Data sent from vehicle to ParkingService</p> <p>Dataset Description This dataset contains information about the current status and parkingstatus of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Automated valet parking, pickup DLR automated vehicle
<p><strong>Scenario description</strong>:</p> <p>The AD-vehicle receives parking command message (AutoPilot.VehicleCommand) containing the destination pickup spot and the free obstacle route and drives from the parking spot and parks to the destination pickup spot. During the collection process the vehicle send two type of messages (AutoPilot.PositionEstimate and AutoPilot.VehicleAVPStatus)</p> <p><strong>Session description</strong>:</p> <p>The pickup scenario with DLR vehicle. DLR vehicle parks autonomously from the parking spot to the destination pickup spot at the parking area on DLR test site in Brunswick.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DroneAvpCommand</strong>: Data sent from drone</p> <p>Dataset Description This dataset contains route information for a vehicle to a designated parking spot</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_ParkingSpotDetection</strong>: Data sent from drone to parkingService</p> <p>Dataset Description This dataset contains informaton about detected parking spots</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed, longitude, latitude, heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystemResampled</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS, resampled to 100 milliseconds</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpCommand</strong>: Data sent from ParkingService to vehicle</p> <p>Dataset Description This dataset contains route to parkingspot, and some other environmental information</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpStatus</strong>: Data sent from vehicle to ParkingService</p> <p>Dataset Description This dataset contains information about the current status and parkingstatus of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Brainport, Automated valet parking, dropoff automated DLR vehicle
<p><strong>Scenario description</strong>:</p> <p>The AD-vehicle receives parking command message (AutoPilot.VehicleCommand) containing the destination parking spot and the free obstacle route and drives from the drop-off position and parks to the destination parking spot. During the parking process the vehicle send two type of messages ( AutoPilot.PositionEstimate and AutoPilot.VehicleAVPStatus)</p> <p><strong>Session description</strong>:</p> <p>The dropoff scenario with DLR vehicle. DLR vehicle parks autonomously from the dropoff location to the selected parking spot at the parking area on DLR test area in Brunswick.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DriverVehicleInteraction</strong>: Data extracted from the CAN of the vehicle</p> <p>Dataset Description This dataset contains e.g. throttlestatus, clutchstatus, brakestatus, brakeforce, wipersstatus, steeringwheel for the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_DroneAvpCommand</strong>: Data sent from drone</p> <p>Dataset Description This dataset contains route information for a vehicle to a designated parking spot</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsAbsolute</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with absolute coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_EnvironmentSensorsRelative</strong>: Data extracted from the vehicle environment sensors</p> <p>Dataset Description This dataset contains information about detected object, with relative coordinates</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_IotVehicleMessage</strong>: Data sent between all devices, vehicles and services</p> <p>Dataset Description Each sensor data submission is a Message. A Message has an Envelope, a Path, and optionally (but likely) Path Events and optionally Path Media. The envelope bears fundamental information about the individual sender (the vehicle) but not to a level that owner of the vehicle can be identified or different messages can be identified that originate from a single vehicle.</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_ParkingSpotDetection</strong>: Data sent from drone to parkingService</p> <p>Dataset Description This dataset contains informaton about detected parking spots</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystem</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed, longitude, latitude, heading from the GPS</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_PositioningSystemResampled</strong>: Data from GPS on the vehicle</p> <p>Dataset Description This dataset contains speed,longitude,latitude,heading from the GPS, resampled to 100 milliseconds</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_Vehicle</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o temperature and battery state of the vehicles</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpCommand</strong>: Data sent from ParkingService to vehicle</p> <p>Dataset Description This dataset contains route to parkingspot, and some other environmental information</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleAvpStatus</strong>: Data sent from vehicle to ParkingService</p> <p>Dataset Description This dataset contains information about the current status and parkingstatus of the vehicle</p> <p><strong>AUTOPILOT_BrainPort_AutomatedValetParking_VehicleDynamics</strong>: Data from the CAN and sensors about the state of the vehicle</p> <p>Dataset Description This dataset contains a.o accelerations and speedlimit of the vehicle, as observed from the CAN and the external sensors</p>
Livorno, Urban driving, Automated vehicle detects fallen bicycle
<p><strong>Scenario description</strong>:</p> <p>Test session for AD+connected car and connected cars approaching a fallen bicycle.</p> <p><strong>Session description</strong>:</p> <p>The fallen bicycle use case aims to demonstrate the possibility for a vehicle to detect in advance, using V2X communication, the presence of a fallen bicycle on the road. In case of fall, the bicycle signals its presence to the other vehicles using DENM messages. The AD car publishes the detected event to the oneM2M and safely reduces its speed until to stop. Goal is to record data for the technical evaluation.</p> <p><strong>Datasets descriptions</strong>:</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_Vehicle_all</strong>: Data generated from the vehicle sensors</p> <p>This dataset refers to the vehicle datasets generated from the vehicle sensors during Urban Driving in Livorno. This includes the data coming from the CAN bus and GPS. It includes following kind of dataset: Vehicle: general data (speed, battery); PositioningSystem: data from GPS; VehicleDynamics: data about dynamic (acceleration...); LateralControl: steering and lane control data</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_V2X_all</strong>: V2V messages during platooning sessions</p> <p>This dataset refers to the V2V messages exchanged between ITS stations (vehicles and RSUs) during the Urban Drining in Livorno.</p> <p><strong>AUTOPILOT_Livorno_UrbanDriving_IoT_all</strong>: Data extracted from IoT oneM2M platform</p> <p>This dataset refers to messages exchanged by Urban Driving devices, applications and services across the oneM2M platform.</p>
Database and model code for "Material efficiency and climate change mitigation of passenger vehicles"
<p>This record provides all data points and model code necessary to compute the results presented in P. Wolfram, Q. Tu, N. Heeren, S. Pauliuk, E. Hertwich (2020) "Material efficiency and climate change mitigation of passenger vehicles", published in Journal of Industrial Ecology. All data is described in section 2 of the manuscript. The code can be run in MATLAB. </p>
Vehicle driving actions for loudness and annoyance perception
<p>This dataset contains 360º videos of 36 driving actions. The videos are organized by vehicles: a white car (Opel Corsa 2016), a dark red motorbike (Suzuki VX 800 800cc 1994), a dark blue van (Fort Transit FT100 1999) and a street sweeper (Kärcher MC 50).</p> <p>The recordings were done with a 360º camera (Xiami Mi Sphere Camera) and a tethraedral microphone (Core Sound TetraMic). The microphone recordings were synthesized to stereo recordings (as if the microphones were pointing at +-60º azimuth) with VVMic from VVAudio. The sound pressure level was measured with a level meter.</p> <p>The driving actions are the following. The sound pressure level was calculated as the fast maximum level (maximum dB SPL in windows of 125ms).</p> <ul> <li>Car <ol> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=0s">00:00</a> Scene 1 - Stand by (close) - 72.5 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=18s">00:18</a> Scene 2 - Accelerate (close) LR - 84.9 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=36s">00:36</a> Scene 3 - 30 km/h (far) RL - 70.4 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=54s">00:54</a> Scene 4 - 50 km/h (close) LR - 81.0 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=72s">01:12</a> Scene 5 - Break and stop (far) RL - 79.8 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=90s">01:30</a> Scene 6 - Stand by (far) - 67.8 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=108s">01:48</a> Scene 7 - Accelerate (far) RL - 79.3 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=126s">02:06</a> Scene 8 - 30 km/h (close) LR - 82.4 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=144s">02:24</a> Scene 9 - 50 km/h (far) RL - 75.7 dB SP</li> <li><a href="https://www.youtube.com/watch?v=zvmhiE3NXx8&t=162s">02:42</a> Scene 10 - Break and stop (close) LR - 75.9 dB SPL</li> </ol> </li> <li>Motorbike <ol> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=0s">00:00</a> Scene 1 - Stand by (close) - 83.7 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=18s">00:18</a> Scene 2 - Accelerate (close) LR - 92.5 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=36s">00:36</a> Scene 3 - 30 km/h (far) RL - 83.2 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=54s">00:54</a> Scene 4 - 50 km/h (close) LR - 90.2 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=72s">01:12</a> Scene 5 - Break and stop (far) RL - 81.8 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=90s">01:30</a> Scene 6 - Stand by (far) - 78.1 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=108s">01:48</a> Scene 7 - Accelerate (far) RL - 86.8 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=126s">02:06</a> Scene 8 - 30 km/h (close) LR - 91.2 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=144s">02:24</a> Scene 9 - 50 km/h (far) RL - 84.3 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=3wa6zeEbJ5w&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=2&t=162s">02:42</a> Scene 10 - Break and stop (close) LR - 83.4 dB SPL</li> </ol> </li> <li>Van <ol> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=0s">00:00</a> Scene 1 - Stand by (close) - 84.4 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=18s">00:18</a> Scene 2 - Accelerate (close) LR - 93.8 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=36s">00:36</a> Scene 3 - 30 km/h (far) RL - 81.4 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=54s">00:54</a> Scene 4 - 50 km/h (close) LR - 92.3 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=72s">01:12</a> Scene 5 - Break and stop (far) RL - 81.4 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=90s">01:30</a> Scene 6 - Stand by (far) - 79.8 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=108s">01:48</a> Scene 7 - Accelerate (far) RL - 85.0 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=126s">02:06</a> Scene 8 - 30 km/h (close) LR - 85.9 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=144s">02:24</a> Scene 9 - 50 km/h (far) RL - 85.6 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=DdaWvKfVILo&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=3&t=162s">02:42</a> Scene 10 - Break and stop (close) LR - 83.1 dB SPL</li> </ol> </li> <li>Street sweeper <ol> <li><a href="https://www.youtube.com/watch?v=4ssqZk78JYc&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=4&t=0s">00:00</a> Scene 1 - Stand by (close) - max 81.9 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=4ssqZk78JYc&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=4&t=18s">00:18</a> Scene 2 - Sweeper on (close) - max 93.7 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=4ssqZk78JYc&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=4&t=36s">00:36</a> Scene 3 - Move forward (close) LR - max 94.6 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=4ssqZk78JYc&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=4&t=54s">00:54</a> Scene 4 - Stand by (far) - max 79.6 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=4ssqZk78JYc&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=4&t=72s">01:12</a> Scene 5 - Sweeper on (far) - max 84.4 dB SPL</li> <li><a href="https://www.youtube.com/watch?v=4ssqZk78JYc&list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB&index=4&t=90s">01:30</a> Scene 6 - Move forward (far) RL - max 84.3dB SPL</li> </ol> </li> </ul> <p> </p> <p>You can also find the videos in <a href="https://www.youtube.com/playlist?list=PLgon04MLXpQpN53hYwTZRmDp0ZSsmnHXB">Youtube</a>.</p> <p>Reference:</p> <p>Llorach, Gerard, Matthias Vormann, Volker Hohmann, Dirk Oetting, Christina Fitschen, Markus Meis, Melanie Krüger, and Michael Schulte. "Vehicle noise: Loudness ratings, loudness models and future experiments with audiovisual immersive simulations." In <em>INTER-NOISE and NOISE-CON Congress and Conference Proceedings</em>, vol. 259, no. 3, pp. 6752-6759. Institute of Noise Control Engineering, 2019.</p>
ScienceDex guides
Understand access before you commit
These curated guides explain access requirements, typical timelines, costs, and reuse considerations for widely used research datasets.
Allen Brain Atlas
Allen Brain Atlas is an Allen Institute collection of brain map atlases, datasets, APIs, and analysis tools covering mouse, human, and non-human primate brain resources.
Annotated Behaviour and Observability Dataset (ABODe)
ABODe is a University of Edinburgh DataShare dataset for behavior classification in group-housed mice using home-cage video, identities, bounding boxes, ground-plate positions, and annotator labels.
DANDI Archive for NWB datasets
DANDI is a BRAIN Initiative archive for publishing and sharing neurophysiology data, including electrophysiology, optophysiology, and behavioral data packaged as NWB and related standards.
International Brain Laboratory public data
The International Brain Laboratory public data releases expose standardized mouse decision-making experiments, including Neuropixels recordings, widefield calcium imaging, behavior, and session metadata accessed through the ONE API.
OpenNeuro
OpenNeuro is a free, open platform for sharing neuroimaging datasets, with public search, dataset pages, and download paths for web, S3, DataLad, and the OpenNeuro CLI.