This bm-tracker branch is used to develop GPS Tracker Simulators,
which can track things by sending their positions frequently.
These Devices are completly independant of any Tracking System and should adhere to standard protocols.
The bm-traccar branch serves as the development environment for integrating specifically with the Traccar GTS.
A traccar-realtime-client will be used to observe one or many devices on the Tracking System.
|
Note
|
Note that we are citing original texts from The RealObject Application Framework |
Physical laws of motion are generally described in isolated values, beginning at the (x, y, z)-coordinate (0, 0, 0) and moving along the x-axis. These laboratory coordinates neglect the relative where and when. In order to relate real-world activities, every event has to be translated into a global coordinate system and absolute time. Motion has to be transformed from spatial coordinates to metric units to reflect, for example, the speed of a car on a map. We will build a virtual GPS unit as the heart of the ROAF to synchronize object motion in space and time.
Part II - Global Positioning
space & time
The ROAF vision described in the book is based on simple and platonic rules.
In order to simulate things, events and interactions of the real world,
we will need a grid for space and time.
simulation environment
|
Important
|
Our Space is the surface of the big blue marble,
which is completly defined with only two spatial coordinates latitude and longitude
in only one projection, the World Geodetic System from 1984 - WGS84.
Sometimes we will use the altitude as a third dimension, but it is less reliable in a geodetic system
and usually provided by a barometer. |
And that is all we need!
physical metrics
It is vital (for simplicity, usability, rapid development and more) that physical events must be describable in a cartesian coordinate system. i.e. units in meters for x, y and z coordinates on orthogonal axes.
To integrate with this bm software you don’t need to worry about geodesy, spherical calculations etc.
The transformation to and from WGS84 is a complicated and expensive mathematical transformation
and should be centralized and standardized.
This also will allow to define a granularity of a scenario as an important scaling factor!
global metrics
We will use the GeoTools library for framwork geodetics.
As example, the built-in GeodeticCalculator
provides our standard distances between geographic coordinates.
It is also useful to know that every GPS Unit automatically provides UTC times,
since this is the prerequisite to calculate locations with fast orbiting satelites.
mission
From the abstracted project view, a GPS unit is an arbitrary technical system to enable electronic receivers to determine their current longitude, latitude, and elevation information. Part of our task is to create a GPS receiver for the software world, a GPS unit.
Part II - Chapter 4 Space & Time
So we need a device to send the minimum GPS information
being latitude, longitude and fixtime as UTC timestamp.
By combining consecutive GPS infos we can calculate telemetry data
like speed being the ratio of space & time.
With this simple tool (a tiny jar) we can switch from geodesy, cartography and navigation
to physical laws described in the language of mathematics. And vice versa.
gps tracking
There are countless ways to implement a - Simulation of a - GPS Tracker hardware.
In the end its just another IoT Device sending information
via some internet protocol, often proprietary.
And it turns out that a GPS server is only a specialized IoT server.
On the receiving side the GTS has a counter part for each Tracker model/type
to extract, transform and load it to the system.
This software is called the Device Communication Server, DCS.
In Traccar all DCS are implemented with Netty
Netty is an asynchronous non blocking event-driven network application framework
for rapid development of maintainable high performance protocol servers & clients.
The JeeTS Tracker
Traccar was thoroughly analyzed in the
JeeTS Book.
Let’s have a little excursion.
Section I, Data Formats and Relations describes the complete process
from Tracker to network to Traccar in detail.
You can read how to create Protocols
jeets-protocols-traccar
with Message Catalogs and how to create a .proto file for Google Protocol Buffers.
Protocol Buffers are language-neutral, platform-neutral
extensible mechanisms for serializing structured data.
It demonstrates how to transform your Data Model to a Persistance Unit
and to an Object Relation Model and back on the fly. Here
jeets-pu-traccar
is a brief overview of the Traccar ERM with a partial ORM.
The book is about connecting cars over the air with loads of information flowing continuously.
For this scenario working with ERM and ORM is the most tight system integration you can achieve.
The message actually carries the complete relational model
and with Protobuffers (or the like) you can compile, compress binaries
to the least possible size for OTA communication.
Protocol changes are made in a simple *.proto text file.
Here is an example of a
protobuffer file to reflect Traccar Entities.
At the end a DCS is developed to match the protocol.
By adding it to Traccar the protocol seamlessly works with the GTS.
On Board Diagnostic Data
To get an idea of regular telematic data amounts in your car have a look at the OBD Sticks implemented in Traccar. For less than a hundred dollars you can get a lot of information over the air. Diagnostic Trouble Codes (DTCs), Real-time Data, Emissions Testing - you name it.
The idea of the ROAF is to pick relevant variables and parameters for a specific scenario. Therefor a Scenario always represents a perspective of a part of reality. OBD data does not take a primary role, since it is more about the inside of a vehicle. For Connected Car Applications different parameters and especially variables are relevant.
Big Data
And to get an idea how much data a modern vehicle produces you can check out some Data Brick specifications, like for example the BRICK2,
The application areas for this platform are demanding measurement
and recording tasks for driver assistance systems (ADAS)
or automated and autonomous driving.
disclaimer
In the end each scenario requires different measurements, sensor data etc.
The JeeTS Tracker can open a lot of oportunities,
but the ROAF is not created for autonomous driving nor its data load.
Traccar Trackers
This project has a different, almost opposite paradigm.
The idea is not to create a proprietary Protocol and DCS.
Vice versa we want to be able to create scenarios with any or all
implemented devices and
protocols.
You can find all Traccar DCS implementations in the
org.traccar.protocol package
with tests.
Each DCS is designed with Netty Pipelines and has Decoder and Encoder classes.
For the ROAF development we want to start bottom up.
All Devices provide GPS coordinates (lat,lon,fix) and that’s all we want for a common basis.
(TODO roaf.gps package and GPSinfo interface)
In the long run the Trackers get more dedicated to a scenario,
cars sending CANBUS info to enrich road infos for a traffic scenario.
To get an overview of all Trackers features handled by Traccar
have a look at the
Position class.
The Position object is the result of every DCS / ETL for every Device.
At the top of the class you can get find an impressive list of KEY_ and ALARM_ events.
gps-osmand-tracker
We want to keep it simple and chose the OsmAnd Protocol via http
to implement a simple Tracker prototype:
(GPSinfo interface can be extracted later for a general Tracker concept in the 1 to n move ;)
xMOVEx mapping the world
A GPS Tracker is a fascinating little matchbox to scan the world.
We attach it to some thing, measure its motion to explore the globe or our neighborhood.
Birds and Wales show us their travel around the globe for best seasonal conditions.
The GPS Traces of racing cars are more than points on the racing track.
They imply physics like the grip of the tires, the airpressure on the vehicle
and much more. Just imagine some computer creating these tracks from
all vehicle parameters. How likely do the measured tracks match the simulated ones?
A GPS Tracker Software or Simulator opens even more perspectives for a tracking tool.
In theory you can transform any shape defined in cartesion systems to geographic coordinates.
It might make sense to define a house in geo coordinates as it doesn’t change its locations,
but measuring it with a GPS unit is practically impossible.
It is possible with much more effort, like differential GPS for centimeter precision and much more. Many of these efforts are made in the sciences of geodesy and cartography. Navigation Systems have become Driver Systems, which push the demand for high density maps. These include road furniture and other tiny details used for driving information.
By using Digital Maps exclusivly defined with only [lat,lon] points we get a reliable source for the actual positions of geostationary objects. Open Source Platforms like OpenStreetMap have one advantage over commercial maps: All contributers have to agree on the final coordinates of a road or building.
|
Important
|
Digital Maps provide the environment, i.e. play board ;) for real world scenarios. |
(Note: Mass and Dimension will be introduced with the RealObject and classical physics)