Using the Data

UDP track data format

When OpenPTrack is detecting and tracking people it produces JSON tracks and distributes them via UDP to the port and IP address listed in the configuration file opt_utils/conf/json_udp.yaml. This can be either broadcast or Multicast. (https://github.com/OpenPTrack/open_ptrack/blob/master/opt_utils/conf/json_udp.yaml).

A single track will appear as:

"{"header":{"seq":71251,"stamp":{"sec":1415305737,"nsec":110138944},"frame_id":"\/world"},"tracks": [{"id":387,"x":-0.89131,"y":2.41851,"height":1.55837}]}"

To view JSON tracking data on the host running the tracking process, which is generally the master:

roslaunch opt_utils udp_listener.launch

Below, we have included some code samples that demonstrate how to use this in various environments. If you want more detail about track lifetime, see track format detail below.

Receiving UDP data in Python

Please see docs/assets/udp_example.py for a basic example of using Python to receive and parse OpenPTrack JSON data.

Receiving UDP data in Node.js

Please see docs/assets/node-ptrack.js for a basic example of using Node.js. All parsing is done in the client.

Receiving UDP data in TouchDesigner

One can use a Script DAT to receive data and populate a DAT, or similarly for CHOP.

For an example of this in a drag-and-drop solution, use the touch component in docs/assets/openPTrack.tox.

It will publish an X, Y that is the average of all tracks. This can be modify as desired.

Receiving UDP data in Processing

Please see docs/assets/p5_opt_udp.pde for a basic example of using Processing to receive, parse, and plot OpenPTrack JSON track data.

Publishing and Receiving Data over Named Data Networking (NDN)

Please see Ros 2 NDN publisher for a ROS plugin to publish tracking data over NDN. (More Information about NDN.)

Track Format Detail (incomplete)

ID is the person ID. It does not wrap, and it has a 32 bit INT, so its maximum value is 2147483647.

Where does the ID come from?

There is a different behavior when a track has just been created (NEW). At first, a track is defined as NEW for sec_remain_new seconds: sec_remain_new

During this period, a NEW track can be validated (and become NORMAL) if it gets at least detections_to_validate detections in sec_before_fake seconds: detections_to_validate and sec_before_fake

If a track does not become NORMAL within sec_remain_new seconds, it is deleted. Once a track is NORMAL, it can be removed only if no detections are associated with it for sec_before_old" seconds.

Where does the ID go when a person exits the system?

In general, an ID (track) is removed, and then no detections are associated with it for sec_before_old seconds. The sec_before_old parameter can be changed here: https://github.com/OpenPTrack/open_ptrack/blob/master/tracking/conf/tracker_multicamera.yaml#L53

What about tracking filter topic ?

UDP data are also subject to the tracking filter node, which adds a further parameter on top, that is track_lifetime_with_no_detections: track_lifetime_with_no_detections

With this parameter, you can choose how long you want to see not visible tracks in the UDP data (not visible means with no detection associated at the current frame). If a track is not visible, what is published is its predicted position.

This parameter does not influence tracking, but only UDP data. Tracking can still continue to estimate where a person should be for sec_before_old seconds (hoping to find it again), but you may want to remove tracks that are not visible for more than track_lifetime_with_no_detections from visualization and the UDP data.