This document discusses using 3D visualization techniques for accident reconstruction. It begins with an introduction to accident reconstruction and the evolution of demands over time from simply knowing an accident occurred to reconstructing it in 3D. It describes using Google Street View and OpenStreetMaps data to display spatial information and road environments in 3D for reconstructing accident playbacks. It also covers using sensor data to model aspects of the accident like car rotation and deformation based on impact angles and magnitudes. The document provides examples of rendering this information in 3D, with the goal of helping analyze how accidents happened and providing more context than basic telemetry data alone.
2. Contents
• Preface
• Speaker
• Scope Technologies
• Accident Reconstruction
• Introduction
• Changes in Marked Demands
• Evolution of Accident Reconstruction
• Accident Playback in 3D
• Displaying Spatial Information in 3D
• Introduction
• Google StreetView
• OpenStreetMaps
• Putting it all Together
• Physics in Accident Reconstruction
• Car Rotation
• Deformation of impacted zone
2
4. Preface – Speaker
• Aleksis Liekna
• Over 10 years of experience in software development
• Education
• Mg.sc.ing. in Computer Science from Riga Technical University
• Unfinished PhD
• Currently working as:
• Software developer @ Scope Technologies .NET, SQL, JavaScript, etc.
• Lecturer @ Riga Technical University teaching microcontroller programming in robotics
• Professional interests:
• Exciting projects, including robotics, microcontrollers, practical application of mathematics
and 3D visualizations
• Hobbies
• Camping, geocaching, nature traveling
4
5. Preface – Scope Technologies
• Established in South Africa 1999
• Main offices in South Africa, and Latvia. Sales offices in Singapore, Ireland, and Argentina.
Sales and marketing via distribution and partner network
• The company is involved in 4 main verticals: Insurance Telematics, Fleet Management ,
and the After Market (service workshops), and consumer connected car services
• Entered the Telematics fleet management market in 2001 .Commenced activities in the
insurance Telematics sector in 2008
• The solutions marketed and distributed by Scope, are exclusively designed and produced
by the company. The products are backed by an extensive patent portfolio
• Global partner footprint
• Rated “Top Telematics Technology Providers” by Technology from Ptolemus Consulting
5
6. Preface – Scope Technologies
• Companies using Scope’s solutions include
6
11. Preface – Scope Technologies
• We are hiring!
• Overall requirements
• Passionate, responsible and trustworthy team-player
• Must want to make a difference, not just a regular worker
• Fluently in English, REST, JSON and Object-Oriented development
• Senior .NET developers
• C# - 5 years of experience
• Experience in HTML, JavaScript and ASP.NET
• Fluently in SQL
• Mobile developers
• iOS and / or Android – 2 years of experience
• Good UI design skills
• Software testers
• Experience in web, backend, web-service and mobile application testing
• Contact:
• charmaine@scopetechnology.com
11
15. Accident Reconstruction – Introduction
• Accident detection
• How to determine if a car has suffered an accident?
• What are the properties of the accident?
• How severe?
• Is human injury likely?
• How can we use this information to provide immediate assistance?
• Automated emergency call
• Post-factum analysis
• Accident verification
• Is this what really happened?
• Accident analysis
• How did this happen and why?
• Provide as much context as possible
15
16. Accident Reconstruction – Changes in Market
Demands
• First wave
• We want to know if accident happened and what are the impacted zones
• Second wave
• It would be nice to play back the accident
• Third wave
• What about accident reconstruction in 3D?
• Can we view this in Virtual Reality (VR) using Oculus Rift?
16
17. Evolution of Accident Reconstruction
• First wave
• We want to know if accident happened and what are the impacted zones
17
18. Evolution of Accident Reconstruction
• Second wave
• It would be nice to play back the accident
18
19. Evolution of Accident Reconstruction
• Third wave
• What about accident reconstruction in 3D?
19
22. Accident Playback in 3D
• How it all started?
• We had this
• What is the problem?
22
23. Accident Playback in 3D
• How it all started?
• We had this
• What is the problem?
• There is no context!
• Where was the car driving?
• What about surroundings?
23
24. Accident Playback in 3D
• How it all started?
• We had this
• What is the problem?
• There is no context!
• Where was the car driving?
• What about surroundings?
• What if we could make the
car drive on an actual road?
• What if we could include physics?
24
25. Accident Playback in 3D
• How it all started?
• We had this
• What is the problem?
• There is no context!
• Where was the car driving?
• What about surroundings?
• What if we could make the
car drive on an actual road?
• What if we could include physics?
• Conclusion – we need to place the car on the road and incorporate physics
into accident playback
25
28. Displaying Spatial Information in 3D
• Where to get spatial information?
• Most popular choice: Google Maps & API
• Map tiles
• StreetView
• Snap-to-Roads
• Speed limit
28
32. Displaying Spatial Information in 3D
• Google Maps & API
• Map tiles
• StreetView
• Snap-to-Roads
• Speed limit
• What of the above can be used to create 3D environments?
32
33. Displaying Spatial Information in 3D
• Google Maps & API
• Map tiles
• StreetView
• Snap-to-Roads
• Speed limit
• What of the above can be used to create 3D environments?
• Snap-to-Roads – we need adequate positions
• StreetView – can provide both 2D and 3D images
33
34. Displaying Spatial Information in 3D
• Google Maps & API
• Map tiles
• StreetView
• Snap-to-Roads
• Speed limit
• What of the above can be used to create 3D environments?
• Snap-to-Roads – we need adequate positions
• StreetView – can provide both 2D and 3D images
• Let us see how!
34
35. Google StreetView in 2D
• A single call to documented Google API
• Inputs:
• Latitude, Longitude, Heading, Pitch
• Output:
• An image
35
36. Google StreetView in 2D
• An example:
• Input:
• http://maps.googleapis.com/maps/api/streetview?size=640x480&location=4
3.0635309,141.3253261&fov=120&heading=235&pitch=10&sensor=false
• Output:
36
37. Google StreetView in 2D
• Pros:
• Easy to implement
• Provides visual context of the surrounding environment
• Cons:
• All you get is a 2D image – no 3D
• Not a real-time solution
37
38. Google StreetView in 3D
• You can get panorama images from Google undocumented API
• Call Google API to get panorama id by location
• Panorama consists of multiple images, depending on zoom level
• Get all panorama image parts, based on panorama id and zoom level
• Create a unified panorama image, based on parts obtained
• Apply the resulting image to a 3D sphere object
• Place camera (observer) in the middle of the sphere
• We have a 360 degree StreetView
• Why is it better than the “default”?
• We have full control over what we do
• We can include additional information (e.g. 3D model of the car)
• We can make it a real-time experience, if we switch spheres quickly enough
38
42. Google StreetView in 3D
• Image as texture on a 3D sphere
42
We have a 360 view, which is great
BUT
What about 3D?
43. Google StreetView in 3D
• It turns out, Google has an undocumented API that provides distance
from Google car to each point (resolution of 512x256) in the spherical
image based on panorama id
• We can use this information to transform the sphere geometry and
make it a “real 3D”
43
46. Google StreetView in 3D
• Look from inside the sphere
46
What is different?
• Closer elements are closer
and vice-versa
• You can actually move in 3D
• Real-time experience
• Best viewed in VR, e.g. using
Oculus Rift
47. Summary of Google Maps & API for 3D
• Pros:
• StreetView together with Snap-to-Roads can provide a pseudo-realistic environment
for accident playback
• Cons:
• StreetView is not available everywhere, images can be several years old and include
large “censored” sections
• Displaying StreetView in 3D is resource and bandwidth intensive, not applicable to
every use-case
• Quality of the resulting 3D image can vary, depending on location
• Spatial data is embedded in map tiles and StreetView images. No way to extract
roads, buildings, etc. as separate entities and display them in 3D
• Conclusion
• We need to include other sources of information to create appropriate 3D
representation of the world
47
48. Displaying Spatial Information in 3D
• Beyond Google maps
• If you need “true” spatial information (not images), like roads, buildings, rivers, trees,
etc., you have look somewhere else
• One option is OpenStreetMaps (OSM) – a database, consisting of:
• Lines – roads, waterways, borders, fences, etc.
• Polygons – buildings, parks, sports areas, industrial areas, etc.
• Points – POIs (points of interest) like hospitals, coffee shops, bus stops, etc.
• OSM data is available for everyone for free:
• Whole planet with minutely updates: http://planet.openstreetmap.org/
• Various extracts, based on country / region: http://download.geofabrik.de/
• A number of open-source tools (and toolchains) exist to import this data into various
formats (eg. PostGIS enabled Postgres database)
48
49. OpenStreetMaps (OSM)
• OSM – a database, consisting of:
• Lines – roads, waterways, borders, fences, etc.
• Polygons – buildings, parks, sports areas, industrial areas, etc.
• Points – POIs (points of interest) like hospitals, coffee shops, bus stops, etc.
• Standard usage of OSM data:
• Download the data
• Import into local database
• Use a tool to render 2D map tiles
• You have your own map-server
49
50. OpenStreetMaps (OSM)
• OSM – a database, consisting of:
• Lines – roads, waterways, borders, fences, etc.
• Polygons – buildings, parks, sports areas, industrial areas, etc.
• Points – POIs (points of interest) like hospitals, coffee shops, bus stops, etc.
• Standard usage of OSM data:
• Download the data
• Import into local database
• Use a tool to render 2D map tiles
• You have your own map-server
50
52. OpenStreetMaps (OSM)
• OSM – a database, consisting of:
• Lines – roads, waterways, borders, fences, etc.
• Polygons – buildings, parks, sports areas, industrial areas, etc.
• Points – POIs (points of interest) like hospitals, coffee shops, bus stops, etc.
• Our usage of OSM data:
• Download the data
• Import into local database
• Create a data access layer, that extracts data as geometries based on given
location
• Use a 3D engine to draw these geometries in 3D space as shapes (lines,
polygons, etc.)
52
58. Putting it all Together
• What do we have:
• Google StreetView in 2D and 3D
• Map in 3D
• OSM map tiles in 2D
• What does it give is:
• Car can be placed into a 3D environment, providing context of the
surroundings at certain location
• What is missing:
• Actual accident details – car rotation, deformation of impacted zones, etc.
(physics)
58
60. Physics in Accident Reconstruction
• Actual physics of a car is very complex, especially in non-deterministic
situations like accidents
• We would need to know the precise properties of every screw to
create an appropriate physics model.
• There are initial unknowns, e.g. impactor properties (imagine hitting a
wall vs hitting a rabbit) that cannot be determined by telemetry alone
• That does not mean we cannot approximate!
• What can we determine, based on accelerometer and other sensors:
• Car rotation
• Approximate deformation of impacted zones
60
62. Car Rotation
• Accelerometer data can be used to calculate roll and pitch
• We can determine yaw using gyroscope and / or magnetometer
62Roll Pitch Yaw
64. Deformation of Impacted Zones
• We rely on telemetry only
• It is impossible to determine some factors (e.g. impactor surface area)
without user feedback.
• We are doing our best to provide adequate approximation based on
telemetry data
• What information do we posses:
• Impact angle
• Impact magnitude
• How can we use that for deformation:
• Adjust geometry of car 3D model – move polygon vertices accordingly
• Use shaders to change color of the affected triangles
64
67. Preface – Scope Technologies
• We are hiring!
• Overall requirements
• Passionate, responsible and trustworthy team-player
• Must want to make a difference, not just a regular worker
• Fluently in English, REST, JSON and Object-Oriented development
• Senior .NET developers
• C# - 5 years of experience
• Experience in HTML, JavaScript and ASP.NET
• Fluently in SQL
• Mobile developers
• iOS and / or Android – 2 years of experience
• Good UI design skills
• Software testers
• Experience in web, backend, web-service and mobile application testing
• Contact:
• charmaine@scopetechnology.com
67
68. Thank You!
• The important thing is not to stop questioning (Einstein)
• Q & A ?
68