Unstable IDs and multiple IDs for the same person.

[igierard]

Hello I'm working with @apavani on our open ptrack setup. We recently switched from four a setup with four kinect 1 to two kinect 2. The kinect 2 reduced a lot of the noise and false positives that we had been seeing with the kinect 1 setup, particularly when denoising and background subtraction are enabled. However we are still experiencing some problems. There seem to be two separate issues.

1. Fast changes in momentum seems to have the system lose track and spawn a new ID. From what we can tell there is a internal model of a person and that acceleration and velocity are part of that model is there some setting that will help tune prediction with regard to fast moving objects? Is there some other setting that can help with this? Is this just a limitation of the system?
2. We will sometimes get two ids tracking the same person. The ids will generally be offset by about 10cm. Sometimes the new id will disappear and some times the old one will. This is usually after some time or if the person moves into an area primarily covered by a different camera. The new ids seem to spawn when a person is at a boundary about equidistant b/t the two camera areas. Additionally new ids seem to spawn more readily when the person is moving faster, not so fast as the previous issue but there does seem to be some correlation b/t speed and new ids spawning. Our guess is that this might have something to do with calibration or alignment. The detections in the visualizer seem fairly aligned. They are generally on the same horizontal plane but can be as far as about 10cm apart on that plane although they are often less than that. We rant the calibration refinement process however the detections alignment presented at the end seemed to be less aligned than when it started. Particularly the vertical offset was more than a meter different b/t the two detection patterns. We experienced similar results with the kinect 1 calibration refinement, the refined alignment seemed much less aligned than the original.

I've attached some photos of the space being tracked and a video of what we are seeing.

https://vimeo.com/168097442/e638540aa1

[lthursdayl]

Hi,

Regarding the splitting UID(s) and/or the UID switching with a change in the direction or velocity, have you verified that your computers are time synced properly via NTP? Both of these issues sound like a problem with your time sync. Have you followed the time sync guide here: https://github.com/OpenPTrack/open_ptrack/wiki/Time%20Synchronization ?

Could you post a screen shot from each of your computers, in your OPT network, the NTP time sync? You can print this by running 'ntpq -p'. The print out on each machine will look similar to this: https://github.com/OpenPTrack/open_ptrack/wiki/Time%20Synchronization#configuration-1-verification

Generally, before I start calibration I ensure that my offset is less than 10 on each machine, and before I start tracking the offset is less than 15. With that said, my offset is usually less than 5. High offset in the time sync across the network will lead to issues with calibration and tracking with the symptom being UID splitting or stability.

[igierard]

We did do a time sync, but I was never quire sure what the output was supposed to be like.

What were all the column supposed to say exactly? It isn't very clear in the docs.

So the important part is that the offset values b/t nodes are low?

We'll check that then.

[jburkeucla]

Yes, in practice offsets should be below 15 ms each.

From: Isaac Gierard notifications@github.com Reply-To: OpenPTrack/open_ptrack reply@reply.github.com Date: Thursday, May 26, 2016 at 2:15 AM To: OpenPTrack/open_ptrack open_ptrack@noreply.github.com Subject: Re: [OpenPTrack/open_ptrack] Unstable IDs and multiple IDs for the same person. (#96)

We did do a time sync, but I was never quire sure what the output was supposed to be like.

What were all the column supposed to say exactly? It isn't very clear in the docs.

So the important part is that the offset values b/t nodes are low?

We'll check that then.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHubhttps://github.com/OpenPTrack/open_ptrack/issues/96#issuecomment-221701911

[mmunaro]

If calibration refinement produces results worse than without refinement, it could be due to more than one person (or spurious detections) present when doing the refinement. Be sure to use background subtraction enabled when doing refinement, so that no detections are generated from background objects. With the code in the development branch, an error is raised on the terminal if more than one person is detected when doing refinement.

[igierard]

So we redid the time synchronization and we stopped getting double IDs. (which was mentioned in the time sync docs as a possible issue, DOUH, and in troubleshooting, DOUBLE DOUH). It seems our first time sync wasn't done correctly.

We also did a calibration refinement after time sync and that produced much better results. Now we have a very nicely tracking system.

We still have issues with fast moving persons but things are way better.

[jburkeucla]

That’s great. We wish the time sync stuff was a little easier to catch / deal with, but once the machines are sync’d, it should be good.

From: Isaac Gierard notifications@github.com Reply-To: OpenPTrack/open_ptrack reply@reply.github.com Date: Thursday, May 26, 2016 at 3:29 AM To: OpenPTrack/open_ptrack open_ptrack@noreply.github.com Cc: Jeff Burke jburke@remap.ucla.edu, Comment comment@noreply.github.com Subject: Re: [OpenPTrack/open_ptrack] Unstable IDs and multiple IDs for the same person. (#96)

So we redid the time synchronization and we stopped getting double IDs. (which was mentioned in the time sync docs as a possible issue, DOUH, and in troubleshooting, DOUBLE DOUH). It seems our first time sync wasn't done correctly.

We also did a calibration refinement after time sync and that produced much better results. Now we have a very nicely tracking system.

— You are receiving this because you commented. Reply to this email directly or view it on GitHubhttps://github.com/OpenPTrack/open_ptrack/issues/96#issuecomment-221720785

[lthursdayl]

Great, glad you got the splitting issue fixed!

Could you post your Kinect settings from open_ptrack/detection/conf/ground_based_people_detector_kinect2.yaml(each machines that is running a Kinect will have this file, please boat both)? UIDs changing with fast moving people is unusual behavior that could be related to a Kinect's settings.

[igierard]

So changing ID might not be the best description. It's more that the person is lost from tracking and then reappears and then has a different ID. It's not as if the marker has one ID one frame and another the next it seems to lose the user for a moment.

Here is our config (it's the same on both)

#######################
## Ground estimation ##
#######################
# Ground estimation mode - 0:manual, 1:semi-auto, 2:auto with user validation, 3:fully automatic (default 0) 
ground_estimation_mode: 3
# Flag stating if the ground should be read from file, if present:
read_ground_from_file: true
# Flag that locks the ground plane update:
lock_ground: true
# Threshold on the ratio of valid points needed for ground estimation:
valid_points_threshold: 0.3

############################
## Background subtraction ##
############################
# Flag enabling/disabling background subtraction:
background_subtraction: true
# Resolution of the octree representing the background:
background_resolution: 0.3
# Seconds to use to learn the background:
background_seconds: 3.0

##############################################
## Ground based people detection parameters ##
##############################################
# Minimum detection confidence:
ground_based_people_detection_min_confidence: -1.75
# Minimum person height:
minimum_person_height: 1.0
# Maximum person height:
maximum_person_height: 2.3
# Max depth range:
max_distance: 10.0 
# Point cloud downsampling factor:
sampling_factor: 4
# Flag stating if classifiers based on RGB image should be used or not:
use_rgb: true
# Threshold on image luminance. If luminance is over this threhsold, classifiers on RGB image are also used:
minimum_luminance: 0
# If true, sensor tilt angle wrt ground plane is compensated to improve people detection:
sensor_tilt_compensation: true  
# Minimum distance between two persons:
heads_minimum_distance: 0.3
# Voxel size used to downsample the point cloud (lower: detection slower but more precise; higher: detection faster but less precise):
voxel_size: 0.06
# Denoising flag. If true, a statistical filter is applied to the point cloud to remove noise:
apply_denoising: true
# MeanK for denoising (the higher it is, the stronger is the filtering):
mean_k_denoising: 5
# Standard deviation for denoising (the lower it is, the stronger is the filtering):
std_dev_denoising: 0.3

[mmunaro]

The right parameters to tune for better tracking are in this file: https://github.com/OpenPTrack/open_ptrack/blob/master/tracking/conf/tracker_multicamera.yaml Have a look at the description of each parameter and in particular I think that your problem could be mitigated by increasing the values of "Motion parameters".

[lthursdayl]

Yes, to jump off what mmunaro said for the setting:

ground_based_people_detection_min_confidence: -1.75

I usually start with;

ground_based_people_detection_min_confidence: -7.0

Then look for spurious detections/tracks. If I see any false tracks I increase the value until the spurious detections stop. Thus, making each Kinect sensitive as possible.

[jburkeucla]

Appears that the questions are answered, closing.