We propose a driver pattern dataset consists of 51 features extracted from CAN (Controller Area Network) of Hyundai YF Sonata while four drivers drove city roads of Seoul, Republic of Korea. Under the belief that different driving patterns implicitly exist at CAN data, we collected CAN diagnosis data from four drivers in pursuit of research on driver identification, driver profiling, and abnormal driving behavior detection. Four drivers are named A, B, C, and D.

Instructions: 

Description

The dataset contains 51 features extracted from CAN along with numerous trips performed by four drivers. The four drivers drove along city roads of Seoul, the Republic of Korea. The recorded 51 features can be employed for driver identification, driver profiling, abnormal driving pattern identification, and any related tasks. Please check the abstract for a more detailed description.

CSV Files

Directory A, B, C and D contains .csv files of CAN data. Each .csv file represents a trip.

Features

The names of 51 features are described in the features.pkl file. Please check the file for detailed information.

Citations

Park, Kyung Ho, and Huy Kang Kim. "This Car is Mine!: Automobile Theft Countermeasure Leveraging Driver Identification with Generative Adversarial Networks." arXiv preprint arXiv:1911.09870 (2019).

Park, Kyung Ho, and Huy Kang Kim. "This Car is Mine!: Automobile Theft Countermeasure Leveraging Driver Identification with Generative Adversarial Networks.", ESCAR Asia (2019)

 

Categories:
154 Views

An inductive power transfer (IPT) system is envisaged as the best solution to conveniently charge electric vehicles (EVs). While stationary IPT systems are becoming commercialized, significant research is being conducted to address the challenges related to dynamic IPT systems. Dynamic or in-motion IPT systems require a fully electrified roadway with embedded inductive couplers with accompanying circuitry. The large number of electronic components required, however, increases the system complexity, reducing the reliability and economic viability of dynamic IPT systems proposed to-date.

Categories:
68 Views

The trace location in Seoul, South Korea has an area spanning over 2.5 × 1.5 km where there are are more than 30 intersections. A number of simulated vehicles are moving in the road topology. Each vehicle shows following properties for every second: 

timestep(simulation) secondsThe time step described by the values within this timestep-element

ididThe id of the vehicle

typeidThe name of the vehicle type

speedm/sThe speed of the vehicle

Instructions: 

XML Format is: 

 

 

 

<fcd-export>

 

  <timestep time="<TIME_STEP>">

      <vehicle id="<VEHICLE_ID>" x="<VEHICLE_POS_X>" y="<VEHICLE_POS_Y>" angle="<VEHICLE_ANGLE>" type="<VEHICLE_TYPE>"

      speed="<VEHICLE_SPEED>"/>

 

      ... more vehicles ...

 

  </timestep>

 

  ... next timestep ...

 

</fcd-export>

 

 

The trace location in Seoul, South Korea has an area spanning over 2.5 × 1.5 km where there are are more than 30 intersections. A number of simulated vehicles are moving in the road topology. Each vehicle shows following properties for every second: 

 

timestep(simulation) secondsThe time step described by the values within this timestep-element

 

ididThe id of the vehicle

 

typeidThe name of the vehicle type

 

speedm/sThe speed of the vehicle

 

angledegreeThe angle of the vehicle in navigational standard (0-360 degrees, going clockwise with 0 at the 12'o clock position)

 

xm or longitudeThe absolute X coordinate of the vehicle (center of front bumper). The value depends on the given geographic projection

 

ym or latitudeThe absolute Y coordinate of the vehicle (center of front bumper). The value depends on the given geographic projection

 

zmThe z value of the vehicle (center of front bumper).

 

 

 

Note: This value is only present if the network contains elevation data

 

posmThe running position of the vehicle measured from the start of the current lane.

 

laneidThe id of the current lane.

 

slopedegreeThe slope of the vehicle in degrees (equals the slope of the road at the current position)

 

signalsbitsetThe signal state information (blinkers, etc). Only present when option --fcd-output.signals is set.

 

 

https://sumo.dlr.de/docs/Simulation/Output/FCDOutput.html

Categories:
34 Views

In this paper, a web-based application for DC Railways networks analysis is presented. The paper provides the guidelines to develop an integrated simulation framework containing different elements like server, databases, visual analytic tools using open-source software. In this case, the proposed application allows to design a DC railway feeding system and analyse the impact of the different agents like vehicles, substations, overhead feeding systems, on-board and wayside energy storage systems, etc.

Instructions: 

This dataset contains a demonstrations of creating and simulating a DC Railway network

Categories:
27 Views

This work contains data gathered by a series of sensors (PM 10, PM 2.5, temperature, relative humidity, and pressure) in the city of Turin in the north part of Italy (more precisely, at coordinates 45.041903N, 7.625850E). The data has been collected for a period of 5 months, from October 2018 to February 2019. The scope of the study was to address the calibration of low-cost particulate matter sensors and compare the readings against official measures provided by the Italian environmental agency (ARPA Piemonte).

Instructions: 

A Densely-Deployed, High Sampling Rate, Open-Source Air Pollution Monitoring WSN

Documentation for the air pollution monitoring station developed at Politecnico di Torino by:
Edoardo Giusto, Mohammad Ghazi Vakili under the supervision of Prof. Bartolomeo Montrucchio.

System Overview

This section includes a description of our architecture from several points of view, going from the hardware and software architecture, to the communication protocols.

Hardware Architecture

We target the following key characteristics of our system:

  1. The rapid and easy prototyping capabilities,
  2. Flexibility in connection scenarios, and
  3. Cheapness but also dependability of components.

As each board has to include a limited number of modules, to facilitate our prototype development, we select the Raspberry Pi single-board computer as a monitoring board.
Due to our constraints in terms of cost, size and power consumption we select its Zero Wireless version based on the ARM11 microprocessor.

The basic operating principle of the system is the following. The data gathered from the sensors are stored in the MicroSD card of the RPi. At certain time intervals the RPi tries to connect to a Wi-Fi network and, if such a connection is established, it uploads the newly acquired data to a remote server.
The creation of the Wi-Fi network is achieved using a mobile phone set to operate as personal hot-spot, while on the remote server resides the database storing all the performed measurements.

Software Architecture

Wi-Fi connectivity was one of the requirements for the system, but at the same time, the system itself should have not to produce unnecessary electromagnetic noise, possibly impacting the operating ability of the host's appliances.
To reduce the time in which the Wi-Fi connection was active, the Linux OS was set to activate the specific interface at predefined time instants in order to connect to the portable hot-spot.
Once connected to the network, the system performed the following tasks:

  1. synchronization of the system and RTC clock with a remote Network Time Protocol (NTP) server,
  2. synchronization of the local samples directory with the remote directory residing on the server.
    The latter task is performed using the UNIX rsync utility, which has to be installed on both the machines.

To gather data from the sensors, a Python program has been implemented, which runs continuously with a separate process reading from each physical sensor plugged to the board and writing on the MicroSD card.
It has to be noted that for what concerns the PM sensors, since the UART communication had to take place using GPIOs, a Pigpiod deamon has been leveraged, to create digital serial ports over the Pi's pins.

The directories on the remote server are a simple copy of the MicroSD cards mounted on the boards.
Data in these directories have been inserted in a MySQL database.

Mechanical Design and Hardware Components

In order to easily stack more than one device together, a 3D printed modular case has been designed.
Several enclosing frames can be tied together using nuts and bolts, with the use of a single cap on top.
Figure shows the 3D board design, together with the final sensor and board configurations.

Each platform is equipped with 4 PM sensors (a good trade-off between size and redundancy), 1 Temperature (T) and Relative Humidity (HT) sensor and 1 Pressure (P) sensor.
As our target was to capture significant data sampling for the particulate matter we adopt the following sensors:

  1. The Honeywell HPMA115S0-XXX as PM sensor.
    As one of our targets was to evaluate these sensors' suitability for air pollution monitoring applications, we insert 4 instances of this sensor in every single platform.
    This sort of redundancy allows us to detect strange phenomena and to avoid several kind of malfunctions, making more stable the overall system.

  2. The DHT22 as temperature and relative humidity sensor.
    This is very widespread in prototyping applications, with several open-source implementation of its library, publicly available on the internet.

  3. The Bosch BME280 as a pressure sensor.
    This is a cheap but precise barometric pressure and temperature sensor which comes pre-soldered on a small PCB for easy prototyping.

The system also includes a Real Time Clock (RTC) module for the operating system to retrieve the correct time after a sudden power loss. The chosen device is the DS3231.
The DS3231 communicates via I2C interface and has native support in the Linux kernel.

As a last comment, notice that a Printed Circuit Board (PCB) was designed to facilitate connections and soldering of the various sensors and other components.

Database

Create database

The database structure can be created using the scripts located in the mysql_insertion folder of the Dataset/SQL_Table repository.

mysql -u <user> [-h <host>] [-p] < create_db.sql

Load SQL data (SQL Format)

Data formated in SQL can be loaded using the mysql command mysql -u username -p WEATHER_STATION < db_whole_data.sql, and the db_whole_data.sql is available in the SQL_data/ folder of the Dataset directory.

Load RAW data (CSV)

Data can be loaded using the python script sql_ins.py available in the mysql_insertion folder of the Dataset/SQL_Table repository.

python sql_ins.py <data_folder>

The script assumes the following folder structure:

* data_folder
|-- 01-board_table
|-- 02-unit_of_measure_table
|-- 03-param_type_table
|-- 04-board_config_table
|-- 05-physical_sensor_table
|-- 06-logical_sensor_table
|-- 07-board_sensor_connection_table
|-- 08-measure_table
|-- arpa
|-- mobility
|-- stations

Each folder contains a set of csv files. The script automatically loads data into the appropriate table and using the correct fields, which are specified as a list of parameters in the script. It is possible to edit the script to load only a subset of the folders.

System Usage

To replicate the experiments, the user should clone the raspberry pi image into a MicroSD (16-32 GB).
To do this, s/he can issue the command dd if=/path/to/image of=/path/of/microsd bs=4m on Linux.
The sampling scripts are run by a systemd unit automatically at system startup. The same systemd unit handles also the automatic respawn of the processes if some problems occur. The data are stored in the /home/alarm/ws/data directory, with filenames corresponding to the date of acquisition.

In order to upload these data to a database, it is possible to use the guide contained in the "database" directory.

In order to perform calibration and tests, it is recommended to take a look at the guide contained in the "analysis" directory. A Python class has been implemented to perform calibration of sensors against the ARPA reference ones. The resulting calibration can then be applied to a time window of choice.

3D Model

A 3D model of the case has been developed using SketchUp online software.
The resulting model is split in 5 different parts, each large enough to fit in our 3D printer (Makerbot Replicator 2X).
The model is stackable, meaning that several cases can be put on top of each other, with a single roof piece.

Printed Circuit Board

A PCB has been developed using KiCad software, so to create a hat for the RPi0 connecting all the sensors.

WS Analysis library documentation (v0.2)

The aim of this package is to provide fast and easy access and analysis to the Weather Station database. This package is located in the analysis directory, and it is compatible only with Python 3. Please follow the readme file for more information.

Directory Structure

project
├── 3D_Box
│   ├── Cap_v0_1stpart.skp
│   ├── Cap_v0_2dpart.skp
│   ├── ws_rpzero_noGPS_v1.skp
│   ├── ws_sensors_2d_half_v2.skp
│   └── ws_sensors_half_v2.skp
├── analysis
│   ├── arpa_station.json
│   ├── board.json
│   ├── example.py
│   ├── extract.py
│   ├── out.pdf
│   ├── requirements.txt
│   ├── ws_analysis
│   │   ├── __pycache__
│   │   │   └── ws_analysis.cpython-37.pyc
│   │   ├── rpt.txt
│   │   └── script_offset.py
│   ├── ws_analysis.md
│   ├── ws_analysis.pdf
│   ├── ws_analysis.py
│   └── ws_analysis.pyc
├── Dataset
│   ├── db_setup.html
│   ├── db_setup.md
│   ├── db_setup.pdf
│   ├── er_diagram.pdf
│   ├── mysql_insertion
│   │   ├── extract_to_file.py
│   │   ├── remove_duplicate.py
│   │   └── sql_ins.py
│   ├── SQL_Table
│   │   ├── create_db.sql
│   │   ├── create_measure_table.sql
│   │   └── load_data.sql
│   └── SQL_data
│      └── db_whole_data.sql.gz
├── PCB
│   └── WS_v2_output.tar.xz
├── readme.html
├── readme.md
├── readme.pdf
└── scripts
├── python
│   ├── csv
│   │   ├── arpa_retrieve.py
│   │   ├── filemerge.py
│   │   ├── gpx2geohash.py
│   │   ├── parse_csv.py
│   │   └── validation.py
│   └── mpu9250
│   └── gyro.py
└── README.md

Categories:
105 Views

Parking Slot Detection dataset

angle, type, and location of each parking slot

Instructions: 

Parking Slot Detection dataset

angle, type, and location of each parking slot

Categories:
23 Views

Vehicular networks have various characteristics that can be helpful in their inter-relations identifications. Considering that two vehicles are moving at a certain speed and distance, it is important to know about their communication capability. The vehicles can communicate within their communication range. However, given previous data of a road segment, our dataset can identify the compatibility time between two selected vehicles. The compatibility time is defined as the time two vehicles will be within the communication range of each other.

Instructions: 

Each row contains characteristic information related to two vehicles at time t. Data set feature set (column headings) are as follows: 

 

- Euclidean Distance: The shortest distance between two vehicles in meters

- Relative Velocity: The velocity of 2nd vehicles as seen from 1st vehicle

- Direction Difference: Given the direction information of each vehicle, the direction difference feature identifies the angle both vehicles are moving towards. For instance, two vehicles going on the same road can have direction difference 0, whereas two vehicles moving in the opposite direction will have a difference of 180. we calculated direction difference using: |((Direction of i - Direction of j+ 180)%360 - 180)| .

- Direction Difference Label: To ease the process for the supervised learning model, we also included direction difference label information by identifying three possible directions ( 0 if difference < 60, 2 if difference >120 and 1 if none of above)

- Tendency: The Tendency is an interesting label that is required to differentiate between two vehicles which are moving in opposite directions, but either they are approaching each other or moving away from each other. 

 

Target Label (Compatibility time): Our goal is to identify how long two vehicles will be in the communication range of each other. The predicted compatibility time label tells us five possible values:

L0 means Compatibility Time is 0

L1 means Compatibility Time is more than 2 seconds but less than 5 seconds

L2 means Compatibility Time is more than 5 seconds but less than 10 seconds

L3 means Compatibility Time is more than 10 seconds but less than 15 seconds

 

L4 means Compatibility Time is more than 15 seconds 

Categories:
127 Views

A high-fidelity CarSim model is used to collect the data for almost 50 maneuvers for two different tractors with different trailer attached to them. For instance, 10 Single Lane Change (SLC) maneuvers are considered in CarSim including 5 tests with E-class SUV and 5 tests with a pick-up truck. Moreover, at each test, the trailer payload and geometry, CG location, and track width, have been changed to collect sufficient data.

Categories:
1432 Views

This dataset contains the signal recording acquired on vehicle (car) drivers (ten experienced drivers and ten learner drivers) on the same 28.7 km route in the Silesian Voivodeship (in Polish województwo śląskie) in southern Poland. Experienced drivers performed the tasks in their own cars whereas the learner drivers performed the tasks under a supervison of a driving instructor in a specially marked cars (with L sign).

Categories:
115 Views

Pages