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”
DE, Vehicles Platooning, eRSU-assisted platooning
<p>Use Case Category: <strong>Vehicles Platooning</strong><br> User Story: <strong>eRSU-assisted platooning</strong><br> Location: German (DE) trial site</p> <p>According to 3GPP TS 22.186 R16, Vehicles Platooning “enables the vehicles to dynamically form a group travelling together. All the vehicles in the platoon receive periodic data from the leading vehicle, in order to carry on platoon operations. This information allows the distance between vehicles to become extremely small, i.e., the gap distance translated to time can be very low (sub second). Platooning applications may allow the vehicles following to be autonomously driven”.</p> <p>User Story: eRSU-assisted platooning</p> <p>In this use case, a platoon of 3 AVs is operating along a road. The platoon approaches a truck. At 500m to a junction, the truck signals its intention to take the right turn and slows down.</p> <p>A local EDM instance deployed on an eRSU located at the junction, detects the truck’s changing velocity and trajectory through learned pattern recognition from local sensor data. It updates the global map and notifies the centralized traffic management & planning applications through eRSU’s upstream interfaces.</p> <p>The platoon leader detects a potential collision as it approaches the truck and request the EDM from the eRSU. The route planning service in the eRSU detects a possible overtaking manoeuvre due to low traffic ahead and possibly adapted green light phase for extended free flow based on information from traffic management system.</p> <p>Based on the information provided by the eRSU and its services, the platoon leader initiates an overtaking manoeuvre by communicating context data (location, speed, LDM) to the eRSU. Using the EDM, the route planning service in the eRSU formulates the overtaking manoeuvre and communicates the overtaking plan to the platoon leader.</p> <p>During the overtaking manoeuvre, the platoon enters the coverage of an eRSU of another provider. This results in eRSU handover with upstream gateway relocation from current MNO’s eNB/gNB to new MNO’s. In effect, the ITS instances and context on source eRSU must be handed over to the new eRSU. At mobile network level, this handover is carried out with handover protocol between the MNOs’ core networks. At application level, resource and service allocation are orchestrated by the centralized ITS service entities, which are made aware of mobile network and MEC provisioning.</p>
GR-TR, Vehicles Platooning, See What I See
<p>Use Case Category: <strong>Vehicles Platooning</strong><br> User Story: <strong>See What I See</strong><br> Location: Greece - Turkey (GR-TR) cross-border corridor</p> <p>According to 3GPP TS 22.186 R16, Vehicles Platooning “enables the vehicles to dynamically form a group travelling together. All the vehicles in the platoon receive periodic data from the leading vehicle, in order to carry on platoon operations. This information allows the distance between vehicles to become extremely small, i.e., the gap distance translated to time can be very low (sub second). Platooning applications may allow the vehicles following to be autonomously driven”.</p> <p>User Story: <strong>Platooning with “see what I see” functionality in cross-border settings</strong></p> <p>Observing that there is at least another vehicle on a road, which does not involve intersections and merging with other lanes for a certain time, the two or more vehicles on the move will decide to form a platoon. In the platoon, while one of the vehicles take on the role of the leader, which may or may not have an active driver depending on the SAE level of the vehicle itself, the rest of the vehicles may be controlled automatically by the movements of the leading vehicle.</p> <p>Once the platoon is formed and the “see-what-I-see” application is informed about the presence of the platoon as well as its members with distinct roles to identify the leader and the follower vehicles, a specific ID is assigned to the platoon by the application. Then, the platoon leader will start transmitting a compressed (with H.265/HEVC codec standard) 4K video stream captured by a camera viewing the road in the front of the vehicle, along with the platoon ID, first to the base station, then to the vEPC, which is to transfer the streaming data to the “see-what-I-see” application server. Matching the video with the recipient vehicles that are the follower trucks in the platoon by using the platoon ID, the application server begins sending the video stream to these through the vEPCs and base stations serving them.</p> <p>All platoon members will be equipped with on board units (OBU) that have the C-V2X communication capability and a connection to the in-cabin displays of the vehicle (such as a dedicated tablet). Additionally, the platoon leader will share road information collected from its sensors such as short and mid-range radars and cameras as well as internal data about its manoeuvres (i.e. emergency brake, speed up-down etc.) over the PC5 interface with the follower vehicles.</p> <p>When the platoon arrives to the customs site between Turkey and Greece borders, the platoon is dissolved for further controls at the borders. At this stage, the objective is to allow the truck drivers handle required documentation while the trucks move autonomously at the customs site to visit each of the checkpoints as dictated by the customs agency. For the autonomous crossing of the trucks between the borders, the customs site will be equipped with several sensors and road side units (RSUs) in addition to the 5G network infrastructure. All sensory information from the vehicles and the surrounding will be gathered at the network edge to be processed by an application, which will determine the safest paths for each of the vehicles at the customs site, dynamically shaping their whole trajectory.</p> <p>After the “truck routing in customs site” is over with no obstacles detected for passage through the border and the drivers have completed their paperwork, they will return to their vehicles. Upon exiting the customs site, the platooning operation and thus the “see-what-I-see” functionality will be initiated again. The final destination of the platoon will be Greece.</p> <p>While the platoon goes from Turkey to Greece, it is anticipated that at some point, which depends specifically on the radio signal propagation characteristics of the 5G networks, the vehicles in the platoon will roam from the Turkish (Turkcell) operator to the Greek (Cosmote) operator, where an uninterrupted video stream will flow from the leader truck to the follower trucks throughout the roaming procedure.</p>
Synthetic vehicle trajectory dataset for the metropolitan city of Los Angeles using DDTG
<p>The analysis of trajectory datasets has numerous applications ranging from urban planning to human mobility understanding, but to protect the privacy of individuals trajectory datasets are rarely released to researchers. And even when they are, they are limited in size and spatio-temporal coverage. To address these issues a number of methods for generating synthetic yet realistic trajectory datasets have been proposed. These existing methods either require a lot of complex parameters to be calibrated (simulators) or rely on existing trajectory datasets (generative models). We use our proposed, and recently published at IEEE BigData 2022 conference, Data-Driven Trajectory Generator, dubbed DDTG, to generate a synthetic vehicle trajectory dataset in the metropolitan city of Los Angeles. The dataset consists of 1.5 million trajectories spanning the first two weeks of December 2019.</p>
UAV Images of Road Vehicles
<p>This annotated dataset contains five different types of vehicles: cars, taxis, trucks, buses, and motorcycles taken from Unmanned Aerial Vehicles (UAVs), which we commonly know as drones. Mavic Air 2 Drone was used to take all the pictures in the Iraqi cities of Sulaimaniyah and Erbil.</p> <p>Version 1 with Data Augmentation techniques applied (Brightness, Hue, and Noise)</p> <p>Version 2 without any Data Augmentation techniques applied.</p> <p> </p> <p> </p>
Vehicle-to-Infrastructure IEEE 802.11ad Wi-Fi dataset
<p><strong>1. Introduction</strong></p> <p>This dataset contains space and time-indexed data collected in a Vehicle-To-Infrastructure (V2I) communication scenario, where a moving vehicle downloaded data from a stationary Access Point (AP) using IEEE 802.11ad Wi-Fi.</p> <p>The dataset is comprised of both throughput data and detailed frame information captured with <code>tcpdump</code>. It can be used to study 802.11ad's behavior in vehicular environments, in particular in what pertains to antenna sector selection.</p> <p>This dataset is associated with the following article, which we recommend consulting for more information: <a href="https://www.cs.vassar.edu/~rpachecomeireles/research/papers/comcom-2022-preprint.pdf"><em>Geolocation-based Sector Selection for Vehicle-to-Infrastructure 802.11ad Communication</em></a>, Mateus Mattos, António Rodrigues, Rui Meireles, Ana Aguiar, in the Elsevier Journal of Computer Communications, Volume 193, ISSN 0140-3664, 2022, <a href="https://doi.org/10.1016/j.comcom.2022.07.005">doi:10.1016/j.comcom.2022.07.005</a>.</p> <p><strong>2. Experimental setup</strong></p> <p>The AP was placed at the corner of a residential-area intersection while a mobile client vehicle drove around it, downloading data from the AP.</p> <p>Commercial Off-The-Shelf (COTS) TP-Link Talon AD7200 were used for both the stationary AP and mobile client. A third AD7200 configured in promiscuous mode was placed next to the mobile client, in order to capture the control frames being exchanged.</p> <p><strong>2.1 Experimental nodes</strong></p> <table> <tbody><tr> <th>MAC address</th> <th>Role</th> <th>Position</th> <th>Orientation</th> </tr> </tbody><tbody> <tr> <td><code>70:4f:57:72:b2:52</code></td> <td>AP</td> <td>Static, latitude: 41.111879, longitude: -8.631146, mounted of top of a parked vehicle</td> <td>Perpendicular to road</td> </tr> <tr> <td><code>50:c7:bf:97:8a:ac</code></td> <td>Client</td> <td>Mobile, mounted on roof of client vehicle</td> <td>Towards front of vehicle</td> </tr> <tr> <td><code>50:c7:bf:3c:53:1c</code></td> <td>Monitor</td> <td>Mobile, mounted on roof of client vehicle</td> <td>Towards front of vehicle</td> </tr> </tbody> </table> <p><strong>3. Trace description</strong></p> <p>The data is divided into traces. Each trace represents an uninterrupted period of data collection. The experiments were ran twice, once in 2020, and again in 2021. Environmental conditions, such as weather and topography, were consistent between the two experiment sets.</p> <p><strong>3.1 2020 traces</strong></p> <table> <tbody><tr> <th>Trace #</th> <th>Start timestamp</th> <th>End timestamp</th> <th>Mobility pattern</th> </tr> </tbody><tbody> <tr> <td>235</td> <td>1593946456</td> <td>1593946593</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed</td> </tr> <tr> <td>237</td> <td>1593946793</td> <td>1593946908</td> <td>Vehicle moving westwards from AP and back, straight line, low speed</td> </tr> <tr> <td>238</td> <td>1593946938</td> <td>1593947076</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed</td> </tr> <tr> <td>240</td> <td>1593947181</td> <td>1593947332</td> <td>Vehicle moving westwards from AP and back, straight line, low speed</td> </tr> <tr> <td>241</td> <td>1593947360</td> <td>1593947499</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed</td> </tr> <tr> <td>242</td> <td>1593947566</td> <td>1593947700</td> <td>Vehicle moving westwards from AP and back, straight line, low speed</td> </tr> <tr> <td>243</td> <td>1593947759</td> <td>1593947915</td> <td>Vehicle moving southwards from AP and back, straight line, low speed</td> </tr> <tr> <td>244</td> <td>1593947971</td> <td>1593948111</td> <td>Vehicle moving southwards from AP and back, straight line, low speed</td> </tr> <tr> <td>245</td> <td>1593948210</td> <td>1593948348</td> <td>Vehicle moving southwards from AP and back, straight line, low speed</td> </tr> <tr> <td>246</td> <td>1593948433</td> <td>1593948569</td> <td>Vehicle moving northwards from AP and back, straight line, low speed</td> </tr> <tr> <td>247</td> <td>1593948631</td> <td>1593948795</td> <td>Vehicle moving northwards from AP and back, straight line, low speed</td> </tr> <tr> <td>248</td> <td>1593948904</td> <td>1593949053</td> <td>Vehicle moving northwards from AP and back, straight line, low speed</td> </tr> <tr> <td>249</td> <td>1593949307</td> <td>1593950016</td> <td>Vehicle driving circuit around the intersection, medium speed (see file <code>driving-circuit.gif</code>)</td> </tr> <tr> <td>250</td> <td>1593950073</td> <td>1593950643</td> <td>Vehicle driving circuit around the intersection, medium speed (see file <code>driving-circuit.gif</code>)</td> </tr> <tr> <td>251</td> <td>1593950682</td> <td>1593951240</td> <td>Vehicle driving circuit around the intersection, medium speed (see file <code>driving-circuit.gif</code>)</td> </tr> </tbody> </table> <p><strong>3.2 2021 traces</strong></p> <table> <tbody><tr> <th>Trace #</th> <th>Start timestamp</th> <th>End timestamp</th> <th>Mobility pattern</th> </tr> </tbody><tbody> <tr> <td>201</td> <td>1632244398</td> <td>1632244548</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>202</td> <td>1632244563</td> <td>1632244663</td> <td>Vehicle moving westwards from AP and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>203</td> <td>1632244674</td> <td>1632244799</td> <td>Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>204</td> <td>1632244812</td> <td>1632244915</td> <td>Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>206</td> <td>1632245138</td> <td>1632245346</td> <td>Vehicle moving eastwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>207</td> <td>1632245355</td> <td>1632245463</td> <td>Vehicle moving southwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>208</td> <td>1632245472</td> <td>1632245581</td> <td>Vehicle moving northwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>209</td> <td>1632245592</td> <td>1632245790</td> <td>Vehicle moving southwards from AP and back, northwards from AP and back, then westwards and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>210</td> <td>1632245798</td> <td>1632245987</td> <td>Vehicle moving eastwards from AP and back, straight line, low speed (see file <code>driving-patterns-by-trace-2021.pdf</code>)</td> </tr> <tr> <td>302</td> <td>1632335672</td> <td>1632336273</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>303</td> <td>1632336286</td> <td>1632336870</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>401</td> <td>1634983869</td> <td>1634984363</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>402</td> <td>1634984410</td> <td>1634984881</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>403</td> <td>1634984908</td> <td>1634985562</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>404</td> <td>1634985666</td> <td>1634986835</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>405</td> <td>1634986980</td> <td>1634988303</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>406</td> <td>1634988352</td> <td>1634989470</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> <tr> <td>407</td> <td>1634989490</td> <td>1634990434</td> <td>Vehicle driving circuit around the intersection (see file <code>driving-circuit.gif</code>), medium speed</td> </tr> </tbody> </table> <p><strong>4. Data description</strong></p> <p><strong>4.1 File structure</strong></p> <p>The data from the 2020 and 2021 sets of experiments can be found in subfolders <code>2020</code> and <code>2021</code>, respectively.</p> <p>Each subfolder constains the following:</p> <ul> <li><code>gps.csv</code>: client vehicle mobility trace (individual NMEA sentences);</li> <li><code>gps-merged.csv</code>: client vehicle mobility trace (summarized);</li> <li><code>thrghpt.csv</code>: application throughput data;</li> <li><code>wifi.csv</code>: summarized 802.11ad frame data;</li> <li><code>pcap/</code>: contains raw <code>.pcap</code> files used to generate <code>wifi.csv</code>, separated by trace number;</li> <li><code>configs/</code>: includes JSON file with fields and filters used by <code>tshark</code> for the generation of <code>wifi.csv</code>.</li> </ul> <p><strong>4.2 GPS data: <code>gps.csv</code></strong> and <code>gps-merged.csv</code></p> <p>GPS data was captured by a high-accuracy GPS device: Trimble Pro Series 6H <a href="http://www.windenvironmental.com/Data-Sheets/Trimble-Pro%20Series-DS.pdf">[link]</a>, and consists of a combination of fields provided by multiple NMEA <code>GP*</code> sentence codes, namely: <code>GPRMC</code>, <code>GPGGA</code>, <code>GPGLL</code>, and <code>GNGSA</code> <a href="http://aprs.gids.nl/nmea/">[link]</a>.</p> <p>Column description</p> <p><code>gps.csv</code> is a table with the following columns:</p> <table> <tbody><tr> <th>Column</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td><code>timestamp</code></td> <td>UNIX system timestamp at which GPS sentence was recorded, in seconds</td> </tr> <tr> <td><code>lat</code></td> <td>Latitude, in decimal degrees</td> </tr> <tr> <td><code>lon</code></td> <td>Longitude, in decimal degrees</td> </tr> <tr> <td><code>alt</code></td> <td>Altitude, in meters</td> </tr> <tr> <td><code>speed</code></td> <td>Ground speed, in knots</td> </tr> <tr> <td><code>HDOP</code></td> <td>Horizontal dilution of precision</td> </tr> <tr> <td><code>PDOP</code></td> <td>Position dilution of precision</td> </tr> <tr> <td><code>VDOP</code></td> <td>Vertical dilution of precision</td> </tr> <tr> <td><code>heading</code></td> <td>Direction of movement as provided by GPS device, in clockwise degrees from north</td> </tr> <tr> <td><code>identifier</code></td> <td>NMEA sentence code, e.g., <code>GPRMC</code></td> </tr> <tr> <td><code>gpstime</code></td> <td>Timestamp as provided by GPS device, in seconds</td> </tr> </tbody> </table> <p><strong>Note:</strong> Because each GPS sentence only contains a subset of the listed columns, any missing values are set to -1.0.</p> <p><code>gps-merged.csv</code> is a table containing all mobility information aggregated by GPS timestamp, for ease of use. It contains the following columns:</p> <table> <tbody><tr> <th>Column</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td><code>gpstime</code></td> <td>Timestamp as provided by GPS device, in seconds</td> </tr> <tr> <td><code>timestamp</code></td> <td>Average UNIX system timestamp at which the GPS sentences from which this row was created were recorded, in seconds</td> </tr> <tr> <td><code>lat</code></td> <td>Latitude, in decimal degrees</td> </tr> <tr> <td><code>lon</code></td> <td>Longitude, in decimal degrees</td> </tr> <tr> <td><code>alt</code></td> <td>Altitude, in meters</td> </tr> <tr> <td><code>speed</code></td> <td>Ground speed, in knots</td> </tr> <tr> <td><code>HDOP</code></td> <td>Horizontal dilution of precision</td> </tr> <tr> <td><code>PDOP</code></td> <td>Position dilution of precision</td> </tr> <tr> <td><code>VDOP</code></td> <td>Vertical dilution of precision</td> </tr> <tr> <td><code>heading</code></td> <td>Direction of movement as provided by GPS device, in clockwise degrees from north</td> </tr> </tbody> </table> <p><strong>4.3 Application layer throughput : <code>thrghpt.csv</code></strong></p> <p>Data was sent from a custom sender application running on the AP, at the maximum possible rate. A custom receiver application on the client vehicle consumes the data. A time-indexed log of the amount of data sent and received was recorded.</p> <p>Column description</p> <p><code>thrghpt.csv</code> is a table with the following columns:</p> <table> <tbody><tr> <th>column</th> <th>description</th> </tr> </tbody><tbody> <tr> <td><code>timestamp</code></td> <td>UNIX system timestamp the throughput record pertains to</td> </tr> <tr> <td><code>pckt_cntr</code></td> <td>Number of packets received within the current record</td> </tr> <tr> <td><code>byte_cntr</code></td> <td>Number of bytes received within the current record</td> </tr> <tr> <td><code>elapsed_time</code></td> <td>Time elapsed since previous throughput record</td> </tr> <tr> <td><code>thrghpt</code></td> <td>Throughput for the current record, in in Megabit per second (Mbps)</td> </tr> <tr> <td><code>inter_arrival_avg </code></td> <td>Average inter-packet arrival time during the recording period, in seconds</td> </tr> <tr> <td><code>diff_local_avg </code></td> <td>Average delta between the timestamp recorded in the packet's payload (set by the sender) and the local timestamp in the receiver, in microseconds</td> </tr> <tr> <td><code>trace_nr</code></td> <td>Trace number the throughput data is associated with</td> </tr> </tbody> </table> <p><strong>4.4 802.11ad frame data: <code>wifi.csv</code></strong></p> <p>The <code>wifi.csv</code> file contains 802.11ad frame data, captured with <code>tcpdump</code>, on a Talon AD7200 router configured in promiscuous mode and colocated with the mobile client device.</p> <p>Data collection and processing</p> <p>The following <code>tcpdump</code> command was used to collect raw data frames:</p> <pre><code>tcpdump -B 100000 -s96 -i <ad-monitor-interface> -y IEEE802_11_RADIO -w <pcap-file> & </code></pre> <p>In order to create <code>wifi.csv</code>, the raw data frames were processed using <code>tshark</code> in order to filter out unnecessary information. More specifically, we ran the following command:</p> <pre><code>tshark -r <input-pcap> -2 -T fields <fields> -Y "<filter>" -E header=y -E separator=, -E quote=d -E occurrence=f </code></pre> <p>The raw input <code>.pcap</code> files for each trace are provided in the <code>pcap/</code> folder. The parameters <code><filter></code> and <code><fields></code> represent the filtering conditions and what fields we want to extract from each frame, respectively. The actual values used are provided in the <code>configs/tshark.json</code> file.</p> <p>Frames were filtered based on a single field: the WLAN frame type and subtype, or <code>wlan.fc.type_subtype</code>. Only the following types of frames were kept:</p> <table> <tbody><tr> <th>Frame type/subtype value</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td>0x0000</td> <td>Association request</td> </tr> <tr> <td>0x0001</td> <td>Association response</td> </tr> <tr> <td>0x0002</td> <td>Re-association request</td> </tr> <tr> <td>0x0003</td> <td>Re-association response</td> </tr> <tr> <td>0x000a</td> <td>Disassociation</td> </tr> <tr> <td>0x000b</td> <td>Authentication</td> </tr> <tr> <td>0x000c</td> <td>De-authentication</td> </tr> <tr> <td>0x0019</td> <td>Block ACKs</td> </tr> <tr> <td>0x001d</td> <td>Clear-to-send</td> </tr> <tr> <td>0x0028</td> <td>QoS data</td> </tr> <tr> <td>0x0030</td> <td>DMG beacon</td> </tr> <tr> <td>0x0164</td> <td>Grant</td> </tr> <tr> <td>0x0167</td> <td>Grant ACK</td> </tr> <tr> <td>0x0168</td> <td>SLS</td> </tr> <tr> <td>0x0169</td> <td>SLS feedback</td> </tr> <tr> <td>0x016a</td> <td>SLS feedback ACK</td> </tr> </tbody> </table> <p>Column description</p> <p><code>wifi.csv</code> is a table with the following columns:</p> <table> <tbody><tr> <th>Column</th> <th>Description</th> </tr> </tbody><tbody> <tr> <td><code>frame.time_epoch</code></td> <td>UNIX timestamp of frame capture, in seconds (with microsecond resolution)</td> </tr> <tr> <td><code>frame.number</code></td> <td>Ordinal number attributed to captured frame</td> </tr> <tr> <td><code>frame.len</code></td> <td>Frame length, in bytes</td> </tr> <tr> <td><code>ip.src</code></td> <td>Source IP address</td> </tr> <tr> <td><code>ip.dst</code></td> <td>Destination IP address</td> </tr> <tr> <td><code>ip.flags</code></td> <td>IP flags</td> </tr> <tr> <td><code>ip.frag_offset</code></td> <td>IP fragmentation offset</td> </tr> <tr> <td><code>ip.hdr_len</code></td> <td>IP header length</td> </tr> <tr> <td><code>ip.id</code></td> <td>IP identification field</td> </tr> <tr> <td><code>ip.proto</code></td> <td>IP protocol field</td> </tr> <tr> <td><code>ip.reassembled_in</code></td> <td>Frame number in which IP packet is reassembled</td> </tr> <tr> <td><code>radiotap.channel.flags.2ghz</code></td> <td>1 if channel frequency is in 2.4 GHz range, 0 otherwise</td> </tr> <tr> <td><code>radiotap.channel.flags.5ghz</code></td> <td>1 if channel frequency is in 5 GHz range, 0 otherwise</td> </tr> <tr> <td><code>radiotap.channel.freq</code></td> <td>Channel frequency (60480 Hz in this case)</td> </tr> <tr> <td><code>radiotap.length</code></td> <td>IEEE 802.11 radiotap capture header length</td> </tr> <tr> <td><code>radiotap.mcs.index</code></td> <td>Modulation Coding Scheme index</td> </tr> <tr> <td><code>udp.srcport</code></td> <td>UDP source port</td> </tr> <tr> <td><code>udp.dstport</code></td> <td>UDP destination port</td> </tr> <tr> <td><code>wlan.ba.bm</code></td> <td>Block ACK bitmap</td> </tr> <tr> <td><code>wlan.bf</code></td> <td>Full beamforming field of WLAN frame</td> </tr> <tr> <td><code>wlan.bf.isInit</code></td> <td>Whether or not frame is SLS initiator</td> </tr> <tr> <td><code>wlan.bf.isResp</code></td> <td>Whether or not frame is SLS responder</td> </tr> <tr> <td><code>wlan.bf.num_dmg_ants</code></td> <td>Number of DMG antennas</td> </tr> <tr> <td><code>wlan.bf.num_sectors</code></td> <td>Number of SLS sectors</td> </tr> <tr> <td><code>wlan.bf.train</code></td> <td>Whether or not frame is part of SLS training</td> </tr> <tr> <td><code>wlan.fc.retry</code></td> <td>Whether WLAN frame is re-transmitted</td> </tr> <tr> <td><code>wlan.fc.type_subtype</code></td> <td>WLAN frame type and subtype</td> </tr> <tr> <td><code>wlan.fixed.ssc.sequence</code></td> <td>WLAN starting sequence number</td> </tr> <tr> <td><code>wlan.fixed.timestamp</code></td> <td>WLAN timestamp</td> </tr> <tr> <td><code>wlan.frag</code></td> <td>WLAN fragment number</td> </tr> <tr> <td><code>wlan.ta</code></td> <td>WLAN transmitter MAC address</td> </tr> <tr> <td><code>wlan.ra</code></td> <td>WLAN receiver MAC address</td> </tr> <tr> <td><code>wlan.seq</code></td> <td>WLAN frame sequence number</td> </tr> <tr> <td><code>wlan.ssw</code></td> <td>Full Sector-level Sweep (SLS) field of WLAN frame</td> </tr> <tr> <td><code>wlan.ssw.cdown</code></td> <td>SLS countdown (CDOWN) number</td> </tr> <tr> <td><code>wlan.ssw.direction</code></td> <td>SLS direction (0: frame sent by SLS initiator, 1: by SLS responder)</td> </tr> <tr> <td><code>wlan.ssw.sector_id</code></td> <td>ID of sector used for SLS frame</td> </tr> <tr> <td><code>wlan.sswf</code></td> <td>Full SLS feedback field of WLAN frame</td> </tr> <tr> <td><code>wlan.sswf.sector_select</code></td> <td>SLS Feedback Sector Select</td> </tr> <tr> <td><code>wlan.sswf.snr_report</code></td> <td>SLS Feedback SNR Report</td> </tr> <tr> <td><code>wlan_radio.11n.mcs_index</code></td> <td>WLAN MCS index</td> </tr> <tr> <td><code>wlan_radio.channel</code></td> <td>WLAN channel</td> </tr> <tr> <td><code>wlan_radio.data_rate</code></td> <td>WLAN data rate</td> </tr> <tr> <td><code>wlan_radio.duration</code></td> <td>WLAN frame duration</td> </tr> <tr> <td><code>wlan_radio.frequency</code></td> <td>WLAN channel frequency</td> </tr> <tr> <td><code>wlan_radio.noise_dbm</code></td> <td>WLAN noise level, in dBm</td> </tr> <tr> <td><code>wlan_radio.phy</code></td> <td>WLAN PHY type</td> </tr> <tr> <td><code>wlan_radio.preamble</code></td> <td>WLAN preamble</td> </tr> <tr> <td><code>wlan_radio.signal_dbm</code></td> <td>WLAN signal strength, in dBm</td> </tr> <tr> <td><code>wlan_radio.timestamp</code></td> <td>WLAN TSF timestamp</td> </tr> <tr> <td><code>data.text</code></td> <td>Data enclosed in WLAN data frame</td> </tr> <tr> <td><code>trace_nr</code></td> <td>Number of the trace the frame is associated with</td> </tr> </tbody> </table>
Scaling Behavior for Electric Vehicle Chargers and Roadmap to Addressing the Infrastructure Gap
<p>Source code and datasets for "Scaling Behavior for Electric Vehicle Chargers and Roadmap to Addressing the Infrastructure Gap"</p>
Private vehicles greenhouse gas emissions at street level for Berlin based on open data
<p>We estimated the annual average daily GHG emissions from individual motor traffic for the OSM road network in Berlin by combining the estimated Annual Average Daily Traffic Volume (AADTV) with respective emission factors. The AADTV was calculated by simulating car trips with the open routing engine Openrouteservice, weighted by activity functions based on statistics of the German Mobility Panel.</p>
Google Street View vehicle-based mobile air quality observations in Salt Lake City (May 2019-March 2020)
<p>Google Street View (GSV) mobile air quality data collected in Salt Lake City as part of an Environmental Defense Fund-supported project that took place between May 2019 and March 2020. <br> The data collection, resolved at 1-second frequency, was carried out with two GSV vehicles.</p> <p>The data is in a single CSV (comma-separated value) text file. </p>
Vehicle trajectory and pavement behavior data
<p>The dataset includes three documents.</p> <p><strong>HDV_data_NGSIM_I_80.xlsx</strong></p> <p>The vehicle trajectory data from Next Generation SIMulation (NGSIM) dataset was collected on eastbound I-80 in the San Francisco Bay area, in Emeryville, CA, on April 13, 2005, from 4:03:56 pm to 4:08:56 pm. Including vehicle id, frame id, the total count of frames of each vehicle, global time, local position, global position, vehicle length, vehicle width, vehicle class, speed, acceleration, lane id, preceding vehicle id, following vehicle id, space headway, time headway, and time.</p> <p><strong>CAV_data_CARLA_SUMO.xml</strong></p> <p>The simulated CAV trajectory data with CARLA and SUMO, including vehicle id, position, angle, type, speed, lane id, and slope of each frame.</p> <p><strong>LTPP_data.csv</strong></p> <p>The table including 21 columns is calculated from the Long-Term Pavement Performance (LTPP) database.</p> <ul> <li>IRI The IRI value measured when age was 0. (m/km)</li> <li>Cr_Gator Area of alligator cracking in square meters. (m^2)</li> <li>Cr_Lwp Length of longitudinal cracks within the defined wheel paths in meters. (m)</li> <li>Cr_Lnwp Length of longitudinal cracks not in the defined wheel paths in meters. (m)</li> <li>Pt_A Area of patches in square meters. (m^2)</li> <li>Pt_N Number of patches in square meters. (m^2)</li> <li>Cr_Wp Length of wheelpath cracks in meters. (m)</li> <li>Cr_Gt183 Total length of transverse cracks greater than 1.83. (m)</li> <li>Rt The depth of rutting in millimeters. (mm)</li> <li>Fr Friction number between the vehicle wheel tire and the pavement</li> <li>IRI_0 The IRI value measured when age was 0. (m/km)</li> <li>Tk_Sb Layer thickness measurement for surface coarse and binder course. (in)</li> <li>Md_s Average backcalculated elastic modulus of the surface layer.(psi)</li> <li>Hydr Average measured hydraulic conductivity of the specimen. (cm/sec)</li> <li>Prcp Average monthly precipitation in millimeters. (mm)</li> <li>Fz Average freeze index. (℃/day)</li> <li>Esal Annual average ESAL (kESAL)</li> <li>Esal_q quadratic form of Kesal (kESAL^2)</li> <li>Age Time duration between new construction to roughness survey date. (year)</li> <li>Gr Mean specific gravity of asphalt cement</li> <li>Pt_Ca Coarse aggregate amount percent by total weight of aggregate in percentage. (%) </li> </ul>
Intersection Monitoring: A dataset for vehicle detection using an infrastructure camera including ground truth vehicle localization
<p><strong>Intersection Monitoring: A dataset for vehicle detection using an infrastructure camera including ground truth vehicle localization.</strong></p> <p>This dataset contains images from a infrastructure camera monitoring an intersection and the ground-truth information for a vehicle crossing it from different directions. The data is aimed to develop and improve image-based vehicle detection algorithms.</p> <p>The dataset includes two different recordings with the same structure. For each of them, the sequence of images is provided in PNG format, along with the ground truth of the vehicle. The ground truth data was captured using a high-precision GNSS receiver installed on the test vehicle, fused with in-vehicle sensors using an Extended Kalman Filter (EKF) .</p> <p><strong>Time considerations</strong></p> <p>The camera and GNSS receiver clocks were synchronized before each test to have the same time base.</p> <p>Each test last about 140 seconds.</p> <p><strong>Image files</strong></p> <p>Image files can be found on the <strong>img/</strong> folder within for each test. The camera was configured to record images at 25 fps:</p> <ul> <li>Test 1: 3704 files</li> <li>Test 2: 3426 files</li> </ul> <p><strong>Vehicle localization ground truth</strong></p> <p>The test vehicle is a prototype of Autonomous Vehicle developed by the <a href="https://autopia.car.upm-csic.es">AUTOPIA</a> research group at the <a href="https://car.upm-csic.es">Centre for Automation and Robotics</a> in Spain.</p> <p>Vehicle location mainly depends on a Trimble BX982 GNSS receiver using RTK inputs from a local station. However, the location algorithm applies an EKF for combining GNSS measurements with different onboard sensors providing yaw rate, longitudinal acceleration and speed, steering wheel position and speed, etc.</p> <p>For each test, the <strong>vehicle.csv</strong> file contains the vehicle information recorded at 20Hz. This file includes:</p> <ul> <li>UTM Time: Time using the format HHMMSSss: <ul> <li>HH: Hours</li> <li>MM: Minutes</li> <li>SS: Seconds</li> <li>ss: Fraction of seconds</li> </ul> </li> <li>UTM East: East coordinate of the GNSS antenna in the UTM frame, in meters.</li> <li>UTMNorth: North coordinate of the GNSS antenna in the UTM frame, in meters.</li> <li>Orientation: Yaw angle of the vehicle, measured from the East axis (x-axis).</li> <li>Speed: Vehicle speed in m/s</li> <li>Acceleration: Vehicle acceleration in m/s^2</li> </ul> <p><strong>Camera info</strong></p> <p>The file <strong>camera_parameters.json</strong> includes all the information about the intrinsic and extrinsic parameters for the camera. The configuration stored on this file appplies to all tests.</p> <p>The camera used is an AXIS M1125 with variable focal length. It was installed in a communication tower near the intersection.</p> <p><strong>Vehicle info</strong></p> <p>The file <strong>vehicle_parameters.json</strong> includes information about vehicle dimensions and antenna location. The GNSS antenna is installed near the rear axle of the vehicle, in the middle part of the vehicle. The configuration stored on this file appplies to all tests.</p> <p><strong>Tools</strong></p> <p>Some MATLAB tools can be found in <a href="https://github.com/autopia-car/datasets-tools-intersection-monitoring">https://github.com/autopia-car/datasets-tools-intersection-monitoring</a></p> <p><strong>Disclaimer</strong></p> <p>That the dataset comes "AS IS", without express or implied warranty and/or any liability exceeding mandatory statutory obligations. This especially applies to any obligations of care or indemnification in connection with the dataset. The dataset was created for our research purposes only and no quality assessment was done for the usage in products of any kind. We can therefore not guarantee for the correctness, completeness or reliability of the provided data set.</p>
Driving environmental images from on-board camera and RTK-based localization for autonomous vehicles
<p>This dataset contains images from an on-board frontal camera as well as information of the vehicle state, including: accurate global localization, heading, speed, acceleration and steering angle position. The data was captured from one of the vehicle instrumenhted vehicles of the <a href="https://autopia.car.upm-csic.es/">AUTOPIA group</a> at the surrounding of the <a href="https://www.car.upm-csic.es/">Centre for Automation and Robotics</a>, in Arganda del Rey (Madrid, Spain).</p> <p>The dataset is aimed to help users in developing and improving image-based road detection algorithms, as well as machine learning end-to-end approaches using driving information provided (steering angle, vehicle speed, etc.).</p> <p>The dataset has also been used to develop algorithms for online map adaptation based on computer vision. Please, refer to:</p> <p>"Artuñedo, A. (2020). Decision-making Strategies for Automated Driving in Urban Environments. In Springer Theses. Springer International Publishing. <a href="https://doi.org/10.1007/978-3-030-45905-5">https://doi.org/10.1007/978-3-030-45905-5</a>"</p> <p><strong>Image information</strong></p> <p>The sequence of images is provided in PNG format, and is named following the pattern: 'l_sA_nsB.png', where A and B are the second and nanosecond when the image was captured, so that A+B*1e-9 is the capture time. The images were captuted with the camera Bumblebee 2 0,8 MP Color FireWire 1394a 3,8mm (Sony ICX204) with the following technical features:</p> <ul> <li>Sensor type: CCD</li> <li>Sensor format: 1/3"</li> <li>Pixel size 4.65 µm</li> <li>Focal length: 3.8mm</li> <li>Fames per second: 20 fps</li> <li>Resolution: 1024 x 768</li> </ul> <p><strong>Camera position</strong></p> <p>The camera is placed at a height 1290 mm measured from the ground plane. With respect to the vehicle frame, it has a yaw of -2º and a pitch 5.5º, in order to focus the field of view in the road.</p> <p> </p> <p><strong>Vehicle localization</strong></p> <p>The test vehicle is a prototype of Autonomous Vehicle developed by the <a href="https://autopia.car.upm-csic.es/">AUTOPIA reseach group</a> at the Centre for Automation and Robotics in Spain. Vehicle location mainly depends on a Trimble BX982 GNSS receiver using RTK. The GNSS antenna is installed near the rear axle of the vehicle, in the middle part of the vehicle. However, the location algorithm applies an EKF for combining GNSS measurements with different onboard sensors providing yaw rate, longitudinal acceleration and speed, steering wheel position and speed, etc.</p> <p>The vehicle localization file ('vehicle_data.csv') includes the following data at a sample rate of 20 Hz:</p> <ul> <li>Time (s)</li> <li>UTM East (m)</li> <li>UTM North (m)</li> <li>Orientation (º)</li> <li>Speed (m/s)</li> <li>Acceleration(m/s^2)</li> <li>Steering wheel angle (º)</li> </ul> <p>Disclaimer That the dataset comes "AS IS", without express or implied warranty and/or any liability exceeding mandatory statutory obligations. This especially applies to any obligations of care or indemnification in connection with the dataset. The dataset was created for our research purposes only and no quality assessment was done for the usage in products of any kind. We can therefore not guarantee for the correctness, completeness or reliability of the provided data set.</p>
Multi-Altitude Aerial Vehicles Dataset
<p><strong>Custom Multi-Altitude Aerial Vehicles Dataset:</strong></p> <p>Created for publishing results for ICUAS 2023 paper "<em>How High can you Detect? Improved accuracy and efficiency at varying altitudes for Aerial Vehicle Detection</em>", following the abstract of the paper.</p> <p><strong>Abstract</strong>—Object detection in aerial images is a challenging task mainly because of two factors, the objects of interest being really small, e.g. people or vehicles, making them indistinguishable from the background; and the features of objects being quite different at various altitudes. Especially, when utilizing Unmanned Aerial Vehicles (UAVs) to capture footage, the need for increased altitude to capture a larger field of view is quite high. In this paper, we investigate how to find the best solution for detecting vehicles in various altitudes, while utilizing a single CNN model. The conditions for choosing the best solution are the following; higher accuracy for most of the altitudes and real-time processing ( > 20 Frames per second (FPS) ) on an Nvidia Jetson Xavier NX embedded device. We collected footage of moving vehicles from altitudes of 50-500 meters with a 50-meter interval, including a roundabout and rooftop objects as noise for high altitude challenges. Then, a YoloV7 model was trained on each dataset of each altitude along with a dataset including all the images from all the altitudes. Finally, by conducting several training and evaluation experiments and image resizes we have chosen the best method of training objects on multiple altitudes to be the mixup dataset with all the altitudes, trained on a higher image size resolution, and then performing the detection using a smaller image resize to reduce the inference performance. The main results</p> <p>The creation of a custom dataset was necessary for altitude evaluation as no other datasets were available. To fulfill the requirements, the footage was captured using a small UAV hovering above a roundabout near the University of Cyprus campus, where several structures and buildings with solar panels and water tanks were visible at varying altitudes. The data were captured during a sunny day, ensuring bright and shadowless images. Images were extracted from the footage, and all data were annotated with a single class labeled as 'Car'. The dataset covered altitudes ranging from 50 to 500 meters with a 50-meter step, and all images were kept at their original high resolution of 3840x2160, presenting challenges for object detection. The data were split into 3 sets for training, validation, and testing, with the number of vehicles increasing as altitude increased, which was expected due to the larger field of view of the camera. Each folder consists of an aerial vehicle dataset captured at the corresponding altitude. For each altitude, the dataset annotations are generated in YOLO, COCO, and VOC formats. The dataset consists of the following images and detection objects:</p> <table> <tbody> <tr> <td><strong>Data</strong></td> <td><strong>Subset</strong></td> <td><strong>Images</strong></td> <td><strong>Cars</strong></td> </tr> <tr> <td>50m</td> <td>Train</td> <td>130</td> <td>269</td> </tr> <tr> <td>50m</td> <td>Test</td> <td>32</td> <td>66</td> </tr> <tr> <td>50m</td> <td>Valid</td> <td>33</td> <td>73</td> </tr> <tr> <td>100m</td> <td>Train</td> <td>246</td> <td>937</td> </tr> <tr> <td>100m</td> <td>Test</td> <td>61</td> <td>226</td> </tr> <tr> <td>100m</td> <td>Valid</td> <td>62</td> <td>250</td> </tr> <tr> <td>150m</td> <td>Train</td> <td>244</td> <td>1691</td> </tr> <tr> <td>150m</td> <td>Test</td> <td>61</td> <td>453</td> </tr> <tr> <td>150m</td> <td>Valid</td> <td>61</td> <td>426</td> </tr> <tr> <td>200m</td> <td>Train</td> <td>246</td> <td>1753</td> </tr> <tr> <td>200m</td> <td>Test</td> <td>61</td> <td>445</td> </tr> <tr> <td>200m</td> <td>Valid</td> <td>62</td> <td>424</td> </tr> <tr> <td>250m</td> <td>Train</td> <td>245</td> <td>3326</td> </tr> <tr> <td>250m</td> <td>Test</td> <td>61</td> <td>821</td> </tr> <tr> <td>250m</td> <td>Valid</td> <td>61</td> <td>823</td> </tr> <tr> <td>300m</td> <td>Train</td> <td>246</td> <td>6250</td> </tr> <tr> <td>300m</td> <td>Test</td> <td>61</td> <td>1553</td> </tr> <tr> <td>300m</td> <td>Valid</td> <td>62</td> <td>1585</td> </tr> <tr> <td>350m</td> <td>Train</td> <td>246</td> <td>10741</td> </tr> <tr> <td>350m</td> <td>Test</td> <td>61</td> <td>2591</td> </tr> <tr> <td>350m</td> <td>Valid</td> <td>62</td> <td>2687</td> </tr> <tr> <td>400m</td> <td>Train</td> <td>245</td> <td>20072</td> </tr> <tr> <td>400m</td> <td>Test</td> <td>61</td> <td>4974</td> </tr> <tr> <td>400m</td> <td>Valid</td> <td>61</td> <td>4924</td> </tr> <tr> <td>450m</td> <td>Train</td> <td>246</td> <td>31794</td> </tr> <tr> <td>450m</td> <td>Test</td> <td>61</td> <td>7887</td> </tr> <tr> <td>450m</td> <td>Valid</td> <td>61</td> <td>7880</td> </tr> <tr> <td>500m</td> <td>Train</td> <td>270</td> <td>49782</td> </tr> <tr> <td>500m</td> <td>Test</td> <td>67</td> <td>12426</td> </tr> <tr> <td>500m</td> <td>Valid</td> <td>68</td> <td>12541</td> </tr> <tr> <td>mix_alt</td> <td>Train</td> <td>2364</td> <td>126615</td> </tr> <tr> <td>mix_alt</td> <td>Test</td> <td>587</td> <td>31442</td> </tr> <tr> <td>mix_alt</td> <td>Valid</td> <td>593</td> <td>31613</td> </tr> </tbody> </table> <p>It is advised to further enhance the dataset so that random augmentations are probabilistically applied to each image prior to adding it to the batch for training. Specifically, there are a number of possible transformations such as geometric (rotations, translations, horizontal axis mirroring, cropping, and zooming), as well as image manipulations (illumination changes, color shifting, blurring, sharpening, and shadowing).</p>
Examining drivers' behaviors to connected and automated vehicles
<p>It is envisioned that Connected and Automated Vehicles (CAVs) are the future of transportation as they can assist in minimizing some inefficiencies with the current transport systems. However, it is not clear how drivers of conventional vehicles would interact with CAVs in a mixed traffic environment containing both CAVs and human driven vehicles (HDVs). Thus, this study aims to investigate drivers’ behaviors towards CAVs through driving simulation experiment and national survey study. Two on-ramp and two off-ramp driving simulation scenarios were designed where drivers were asked to merge with two-lane highway in presence of HDVs and CAVs truck platoon in the on-ramp scenarios. In the two off-ramp scenarios, they were asked to take exit in presence of HDVs and CAVs truck platoon in the lane to their right. A before-after survey was conducted among the participant of the driving simulation experiment and an online survey was conducted to investigate their opinion in different traffic, road and environmental condition in presence of CAVs. Furthermore, two driving simulation scenarios were designed to test drivers’ behaviors during automated driving mode and their reaction when the control was shifted to the manual driving mode. Results from the on-ramp scenarios and off-ramp scenarios indicate that more than half of the drivers preferred to merge in front of CAV truck platoon and around two-third of the drivers chose to diverge behind the platoon. The online survey revealed that around two-third of the respondents would not overtake CAV platoon in two-lane two-way road, whereas around 60% would do so in case of three lane highway. During automation failure, drivers demonstrated lower take-over reaction time (TORt), lower deceleration and higher TTC in scenarios with non-driving related tasks (NDRT) compared to the scenarios with no NDRT (manual mode). The before-after survey results suggest that most of the drivers found the navigation with CAV easier after participating in the experiment.</p>
Particle filter meets hybrid octrees: an octree-based ground vehicle localization approach without learning
<p>This paper proposes an accurate lidar-based outdoor localization method that requires few computational resources, is robust in challenging environments (urban, off-road, seasonal variations) and whose performances are equivalent for two different sensor technologies: scanning LiDAR and flash LiDAR. The method is based on the matching between a pre-built 3D map and the LiDAR measurements. Our contribution lies in the combined use of a particle filter with a hybrid octree to reduce the memory footprint of the map and significantly decrease the computational load for online localization. The design of the algorithm allows it to run on both CPU and GPU with equivalent performance. We have evaluated our approach on the KITTI dataset and obtained good results compared to the state of the art. This paper introduces the baseline performance on a multi-seasonal dataset we are publicly releasing to the community. We have shown that the same localization algorithms and parameters can perform well in urban environments and can be extended to off-road environments. We have also evaluated the robustness of our method when masking angular sectors of the LiDAR field of view to reproduce edgecases scenarios in urban environments where the LiDAR field is partially occulted by another vehicle (bus, truck). Finally, experiments have been carried out with two distinctive scanning and flash LiDAR technologies. The performance achieved with the flash LiDAR is close to the scanning LiDAR despite different resolutions and sensing modalities. The positioning performance is significant with 10cm and 0.12° angular RMSE for both technologies. We validated our approach in an off-road environment from a front view field of view with only 768 LiDAR points.</p>
High resolution LiDAR dataset acquired using UAV (unmanned aerial vehicle) over two vineyards and two years located in 'Tomiño', Pontevedra, Spain.
<p>This dataset features an extensive collection of LiDAR data from vineyards in northern Spain, targeting vineyards to address the growing demand for public UAV LiDAR datasets in Agricultural Sciences. The data was gathered using a DJI M300 multi-rotor platform equipped with a DJI Zenmuse L1 LiDAR sensor, conducting UAV flights at 20, 30, and 50 meters Above Ground Level (AGL) across two vineyards during 2021 and 2022. The dataset comprises ten high-density 3D LiDAR point clouds stored in .laz format with embedded RGB information in each point. This information is essential for studying vineyard morphology and development and plays a key role in refining vineyard management tactics. In addition, the dataset is valuable for agricultural robotics, providing detailed terrain and canopy data crucial for designing efficient flight paths and navigation algorithms. Finally, it serves as a true "ground truth" dataset to verify satellite-derived models, enabling the generation of high-precision digital elevation models (DEMs) and other derivatives.</p>
Testing autonomous vehicle lane keeping assist system in BeamNG simulator
<p>In this video, you can see some of the failures revealed while testing the driving agent on various road topologies in BeamNG simulator. Road topologies were generated by our tool RIGAA (available at: <a href="https://zenodo.org/record/8242223">Reinforcement learning informed evolutionary search for autonomous systems testing | Zenodo</a>)</p>
Electric vehicle occupancy of charging points in the city of Paris
<p>Dataset collected by EDF R&D using the <em>Paris Data</em> open data platform, providing real-time occupancy of public charging points for electric vehicles in the city of Paris. This <strong>data.zip</strong> archive should be used at the root of the following gitlab repository (it replaces the empty data folder): <a href="https://gitlab.com/smarter-mobility-data-challenge/additional_materials">smarter-mobility-data-challenge/additional_materials</a>. V1 corresponds to the data provided for the Smarter Mobility Challenge, augmented with exogenous features such as weather and traffic. V2 corresponds to additional raw observations of occupancy data collected and accompanied by initial data processing.</p>
A Dataset Containing Tiny Vehicle Images Collected in Low Quality Imaging Conditions
<p>This dataset contains 4800 tiny and low resolution vehicle images collected in low lighting and different weather conditions. The vehicles in the images are grouped in six classes: Bike, Car, Juggernaut, Minibus, Pickup, and Truck. For each class, there are 800 vehicle images with 100 × 100 pixels and 96 dpi resolution.</p> <p>The peer-reviewed data descriptor for this dataset has been published in MDPI Sustainability - an open access journal, and can be accessed here: <a href="https://doi.org/10.3390/su152316292">https://doi.org/10.3390/su152316292</a>. Please cite this when using the dataset.</p>
The application of unmanned aerial vehicle (UAV) surveys and GIS to the analysis and monitoring of recreational trail conditions - dataset
<p>This dataset contains data used to test the protocol for high-resolution mapping and monitoring of recreational impacts in protected natural areas (PNAs) using unmanned aerial vehicle (UAV) surveys, Structure-from-Motion (SfM) data processing and geographic information systems (GIS) analysis to derive spatially coherent information about trail conditions (Tomczyk et al., 2023). Dataset includes the following folders:</p> <ol> <li>Cocora_raster_data (~3GB) and Vinicunca_raster_data (~32GB) - a very high-resolution (cm-scale) dataset derived from UAV-generated images. Data covers selected recreational trails in Colombia (Valle de Cocora) and Peru (Vinicunca). UAV-captured images were processed using the structure-from-motion approach in Agisoft Metashape software. Data are available as GeoTIFF files in the UTM projected coordinate system (UTM 18N for Colombia, UTM 19S for Peru). Individual files are named as follows [location]_[year]_[product]_[raster cell size].tif, where: <ul> <li>[location] is the place of data collection (e.g., Cocora, Vinicucna)</li> <li>[year] is the year of data collection (e.g., 2023)</li> <li>[product] is the tape of files: DEM = digital elevation model; ortho = orthomosaic; hs = hillshade</li> <li>[raster cell size] is the dimension of individual raster cell in mm (e.g., 15mm)</li> </ul> </li> <li> <p>Cocora_vector_data. and Vinicunca_vector_data – mapping of trail tread and conditions in GIS environment (ArcPro). Data are available as shp files. Data are in the UTM projected coordinate system (UTM 18N for Colombia, UTM 19S for Peru).</p> </li> </ol> <p>Structure-from-motio<span> </span>n processing was performed in Agisoft Metashape (<a href="https://www.agisoft.com/">https://www.agisoft.com/</a>, Agisoft, 2023). Mapping was performed in ArcGIS Pro (<a href="https://www.esri.com/en-us/arcgis/about-arcgis/overview">https://www.esri.com/en-us/arcgis/about-arcgis/overview</a>, Esri, 2022). Data can be used in any GIS software, including commercial (e.g. ArcGIS) or open source (e.g. QGIS).</p> <p>Tomczyk, A. M., Ewertowski, M. W., Creany, N., Monz, C. A., & Ancin-Murguzur, F. J. (2023). The application of unmanned aerial vehicle (UAV) surveys and GIS to the analysis and monitoring of recreational trail conditions. <em>International Journal of Applied Earth Observations and Geoinformation</em>, 103474. doi:<a href="https://doi.org/10.1016/j.jag.2023.103474"> https://doi.org/10.1016/j.jag.2023.103474</a></p>
Doppler-only Single-scan 3D Vehicle Odometry
<p>Dataset provided with the article of the same name. Created to test the performance of 3D Doppler-capable radar odometry in outdoor scenarios. Sensors mounted on the vehicle include a 3D Doppler-capable radar, 3D lidar, and an IMU. </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.