Compiler/IWR1642: for people counting when tracking an objective,why we need to unroll RadialVelocity?

Hi Justiin,

Thank you for your reply.

I am working on the people counting demo.And I found that the MmwDemo_CLITrackingCfg function  in task_app.c(pplcount_16xx_mss) we assign values to variables according to cfg.

The '200'(blue) represents the maximun unambiguous radial velocity.Then still in the MmwDemo_CLITrackingCfg function,we execute the gtrack_moduleCreate(&config) which assigns maxRadialVelocity to a GtrackModuleInstance (we define GtrackModuleInstance *inst) according to GTRACK Algorithm's code.That is mean when we execute the unroll RadialVelocity we may +/- 20(200*0.1)m/s.Is it right?

Another question is, when we execute the gtrack_unitUpdate function where we also consider to unroll RadialVelocity, In the 'VELOCITY_RATE_FILTER' state we are using filtered Rate Range to unroll radial velocity stabilizing Range rate.On,what is range rate?Why should we do taht?I got confused.Could you please give me more help or helpful information?

Thanks,

Hanna

Hi Justin,

In this case the variable 'inst->maxRadialVelocity' is 20(200*0.1)m/s.The following code is from gtrack_unitScore function.

If 'Radial velocity estimation is known', inst->H_s[2](Radial velocity estimation or a track's expected measurment velocity) is larger than point[n].doppler(a point's velocity).Then the gtrack_unrollRadialVelocity function adds inst->maxRadialVelocity(20m/s) to inst->H_s[2].What I am worried about is that in that way the gap between inst->H_s[2] and point[n].doppler is wider and wider.By the way, I don't think it is a proper velocity for people. Please just tell me if I make some mistakes on understanding the score algorithm.

Thanks,

Hanna

Hi Justin,

Thank you for your reply.However what you said is what I have known.My question is following three:

1.As the picture I post before, is 20m/s assigned to inst->maxRadialVelocity?Or is  maxRadialVelocity's value equal to maxURadialVelocity's?

2.If they are equal,inst->maxRadialVelocity(20m/s) is apply to work with rvExp and finally returns rvOut.In the case of considering objective like human's velocity,the value(20m/s) is obviouslly wrong.Doesn't right?

3.I appreciate your answer. I want to know more about  the principle of gtrack_unrollRadialVeloctiy function, rather than it is effect.Why the gtrack_unrollRadialVeloctiy function can correct those errors?

Thanks,

Hanna

Hi Justin,

Could you please provide some references related to the unrolling-velocity algorithm? Or something that goes into more detail about how it works.

Thanks,

Hanna

Hi Hanna,

Please see the Traffic Monitoring TI Design for more on velocity unrolling.

Regards,

Justin

Hi Justin,

I have read all the information you provided.I need to explain what I have done.I have used lab0011-pplcount and modified the MATLAB code to collect data of point cloud in successive frames.Then I selected one frame of data.The target is displayed on the MATLAB graph associated with the data.With the data of that frame, I simulated the process of allocation.For a bunch of points,we use the leading point’s radial velocity Vr, i=0 to unroll the velocity of the other points in the allocation set.

In the relevant configuration file, mmw_pplcount_demo_default.cfg,we define allocation parameters 450 0.01 25 1 2.That means maxVelThre—Maximum velocity difference between candidate and centroid to be part of the allocation ser—is 2m/s.As you said in your previous post, we can turn down max velocity to the range of 5- 10 (50 - 100) which will be assigned to inst->maxRadialVelocity.In my case, 5m/s is assigned to inst->maxRadialVelocity.

Now, in the function of gtrack_moduleAllocate, we have a leading point and use gtrack_unrollRadialVelocity function to unroll the velocity of the other points.For instance,No.6 point is the leading point.Then we look at the No.7 point.Both of them meet the requirements of  becoming a new track theoretically.In the detail of execution of gtrack_unrollRadialVelocity function,the leading point's velocity is larger than No.7 point's. Then un(2)—is the No.6 point's velocity in this step—will plus inst->params.maxRadialVelocity(5m/s).In the next step , fabs(uk[2] - un[2]) < inst->params.allocationParams.maxVelThre(2m/s).

At that time uk(2) and un(2) are in fact the velocity of No.6 point's velocity and the unrolling of No.6 point's velocity.

uk(2)=un(2)+inst->params.maxRadialVelocity=No.6 point's velocity+5m/s.

fabs(uk[2] - un[2])=No.6 point's velocity+5m/s-No.6 point's velocity=5m/s> inst->params.allocationParams.maxVelThre(2m/s).Therefore,we can not include the No.7 point into allocation.Worsely,the other points will meet the same situation.In the end ,my simulation didn't form any track.Is there anything wrong?

Thanks,

Hanna

Hi Justin

In order to continue my work,I turn down max velocity to 5m/s in my last post. inst->maxRadialVelocity=5(m/s)

However,that must result in failure.I turn down max velocity to 0.5m/s.Then it work.Is measurement unit wrong?

Thanks,

Hanna 

Hanna,
Few comments on this thread:
1. From GTRACK Algorithm perspective, Maximum Radial velocity is NOT a tunable parameter. It shall match the detection layer configuration. The detection layer provides aliased Doppler measurements in the range of +/- maximum Radial Velocity, [-Vmax … +Vmax]. This parameter shall be provided to tracking algorithm, which will unroll the radial velocity.
2. The unrolling function returns the value that is the closest to the expected velocity (Vexp) in the range [Vexp-Vmax Vexp+Vmax]. In the case of established track, we use the target estimated velocity to compute Vexp. During allocation, we use the leading point radial velocity instead, so Vexp=leading point Doppler.

So, let's consider an example: target is approaching at (-10m/s). Say, maximum Radial velocity (Vmax) is 8m/s. Let's assume the detection layer provides two points: p1, and p2. Assume real Doppler values of reflection points are: p1 (-9m/s), and p2 (-10m/s). Detection layer delivers aliased values of with radial velocity of +7m/s and +6m/s. Allocation algorithm takes p1 (+7m/s) as a leading point; this would be the value of un[2] in a C code you refer. The algorithm will unroll value of p2 (+6m/s) to the closest value of p1 and return the same value back, i.e. the value of uk[2] shall be (+7ms). Those two values shall be “close enough” to each other (i.e. fabs(uk[2]-un[2]) shall be smaller than velocity separation threshold), and the second point p2 shall join the allocation set.
Michael

Hi Michael,

Thank you for your help.I have resolved myh problem.

what you explain about the detection layer's work is described in velocity disambiguation?

Thanks,

Hanna