IWR6843AOPEVM: "undefined reference to 'gtrack_create'" by the implementation of the GTRACK algorithm

Hello Anne-Mira,

The gtrack.h is a C based library meant to run on the IWR6843 embedded processor, it is not set up to be compiled in CPP and run outside of the device. It will be difficult to extract the tracking functionality from the gtrack.c alone since there are many other dependencies inside the embedded processing chain.

What part of the tracker are you trying to pull out the the CPP level? Did I understand the question correctly?

Thanks,

Jackson

Hello Jackson,

you got the question right. I try to run it outside of an embedded processor in a cpp/ROS environment. Thanks for your answer!

I have a robot, running in a cpp/ROS environment and I want to tracking moving targets around it. First I had the gtrack lib on the IWR6843 and modified successfully the ROS driver to get pointcloud and targetlist in ROS. That works so far.

But as the robot moves itself, I need to filter the pointcloud for the gtrack algorithm depending on the actual position of the robot. That means, if have to send position data of the robot via the same serial connection to the radar and that resulted in some data rate related troubles. A standard UART interface is not really the fastest connection ;-)
Changing the communication to another interface is at the moment not possible, but we plan that for the future.

Basically, I need a TargetList from a part of the pointcloud depending on the actual robot position and state and the pointcloud itself.

The question is now, if it's easier to extract gtrack in a cpp level outside the embedded processor or find a solution for the data bottleneck in the UART interface.

I also run into another - probably data rate related - problem. Debug mode in CSS works fine, until I open the serial connection via the TI ROS driver, than it crashes. This problem occurs independently of the flashed software. I tried OOB-Demo and PeopleCounting-Demo. But I'm not really sure, whats the problem here, I just stopped doing it.

Long story short, I would be glad, if you have some thoughts to the above explanations.

Regards,
Anne-Mira

Hi Anne-Mira,

Unfortunately, GTRACK was designed for fixed, stationary sensors. Not moving robots. I'd encourage you to try it on your moving robot for understanding the performance. 

I'm trying to understand your datarate problem. If you are trying to send the robot position to the DATA serial line, this will not work as this line is transmit only. Could this explain your data rate problem?

You describe the need to filter your point cloud, this is a ROS package that may be able to help: http://wiki.ros.org/pcl_ros  

My final thought is this. If you require object tracking from the radar, you can use GTRACK but keep it on the radar side. If you do this, you will need to modify the TI ROS driver to parse and publish the tracking information. 

As far as your debugging problem, I'm not so sure. You may need to create a new thread for such. 

Hi Sabeeh,

thank your for answer and thoughts!

I know, that it's not designed for that use-case, it's just an experiment.
I'll try to make the problem clearer. Sorry for that mess above. Too many thoughts in my head.

That's what I need:       dynamic parameters from robot (need to be updated frequently)
                                                                         |
                                                                        V
        point cloud from radar -> filter point cloud -> run gtrack on filtered point cloud

If I run gtrack on the radar, I can't filter the point cloud with parameters from the robot and according to Jackson, I can't run gtrack in cpp environment, where I can filter the point cloud with parameters from the robot.That's how I see it at the moment and I'm looking for an solution for that.

The question is not how to filter the point cloud, the question is how to get the point cloud and the dynamic parameters in one environment to setup the filter, before running gtrack.

If already implemented your suggestion under final thoughts, so I can run gtrack on the radar and visualize the targets and point cloud in ROS/RVIZ. I also know the pcl_ros package, but it doesn't help me, because I would filter a point cloud, which is already processed by gtrack, so it won't affect anything.

To the data rate point:
I never actually tried to send the robot position data via serial connection to the radar, because I think that UART can't handle the high data rate. As I'm able to send the configuration for the radar from ROS, it should be possible to send more information than that, shouldn't it?

Regards,
Anne-Mira

If I'm understanding you correctly, you could use the 'aoaFovCfg' command from the Table 2 in the mmWave SDK. You could use this command to filter point cloud data. The command is also useful in that you can use this command while the sensor is running. 

Regarding the dynamic parameters, I'm not sure what you mean. What kind of parameters are you looking for? Since you describe these as parameters from the robot, I don't think I may be able to help here. 

To the data rate point: 

Yes you could send some more information, but you would have to edit the out of box demo firmware to do so. 

Hi Sabeeh,

thanks for your kind answers.

I guess it's not useful to continue the discussion on the dynamic parameters. I have to figure that out myself.

I want to get back to the start and Jackson's answer. What kind of dependencies make extracting gtrack in a ros/CPP environment so difficult? What do I have to mind, when I want to integrate the Library into a CPP environment?

Regards,
Anne-Mira

Hi Sabeeh,

one last thought. Would it be possible to run the gtrack library on a Jetson?

Regards,
Anne-Mira

I assume the aforementioned challenges would be the same.