IWR6843AOP: ROS 2 Driver Support for Evaluation | Development

i also, would like to do the same.

i managed to run the ROS driver for ROS1 (on Noetic).

changes were needed to be made at the launchers.

a. change to ttyUSB0 and ttyUSB1 as the IWR6843AOPEVM hardware is using the CP210x drivers.

b. change the line of

    <param name="frame_id" value="/ti_mmwave_0"/>

to

<param name="frame_id" value="ti_mmwave_0"/>

then things stated to work.

as for now i am trying to convert the ROS driver to work with ROS2 (without the ROS1_bridge).

would like some help also.

Hello,

If you are to attempt to convert the ROS driver to work with ROS2 independently, you will need to make a lot of changes. First off we use nodelets which no longer exist in ROS2, thus it must be made as a component. Second due to the differences with how nodes work and interact with each other you will need to rewrite them, and create a few new publishers/subscribers for node-to-node communication. You will also need to implement multi-threading using rclcpp's executor.

Best Regards,

Pedrhom

what about your say that: The ROS2 driver will be properly released to the public no later than the end of the month.

are you planning to release a full functioning ROS2 driver. doing what you mentioned in your replay.

thanks in advance.

menachem fried

Hello Menachem,

That is the plan and how it is currently being implemented.

Best Regards,

Pedrhom

First I’d like to thank you for this ros2 update of the mmwave_ti_ros drivers.

I have managed to make it work, and I’d like to share with you the problems I have bumped with.

You may to fix the following:

1. In the \ros2_driver\src\ti_mmwave_rospkg\src\ and ros2_driver\src\ti_mmwave_rospkg\msg\ folders, exists the following folders:

build, install, log

these seem not to part of the source code but rather inserted by a colcon build command.

2. In the \ros2_driver\src\ti_mmwave_rospkg\launch\ folder all launchers use the line

path = "/home/vboxuser/mmwave_ti_ros2_ws/src/ti_mmwave_rospkg/cfg/

*******.cfg";

These lines need to be changed for the launchers to work.

3. While compiling the serial package within the ros2 driver workspace with colcon build, the following warning appeared:

CMake Warning (dev) at CMakeLists.txt:26 (target_sources):

  Policy CMP0076 is not set: target_sources() command converts relative paths

  to absolute.  Run "cmake --help-policy CMP0076" for policy details.  Use

  the cmake_policy command to set the policy and suppress this warning.

  An interface source of target "serial" has a relative path.

This warning is for project developers.  Use -Wno-dev to suppress it.

4. While compiling the ti_mmwave_rospkg serial package within the ros2 driver workspace with colcon build, the following warning appeared:

--- stderr: ti_mmwave_rospkg                                

** WARNING ** io features related to openni will be disabled

** WARNING ** io features related to openni2 will be disabled

** WARNING ** io features related to pcap will be disabled

** WARNING ** io features related to png will be disabled

** WARNING ** io features related to libusb-1.0 will be disabled

** WARNING ** visualization features related to openni will be disabled

** WARNING ** visualization features related to openni2 will be disabled

** WARNING ** apps features related to openni will be disabled

---

This has to do something with the PCL library.

We have our constraints that forces us to use the ROS2 Foxy distribution on top ubuntu 20.04.

The following changes were needed:

1. In the \ros2_driver\src\ti_mmwave_rospkg\src\ folders the lines

this->declare_parameter("*****", rclcpp::PARAMETER_STRING);

were needed to be changed to

this->declare_parameter("*****", “”);

because Foxy does not support this new ROS2 feature.

2. In the \ros2_driver\src\ti_mmwave_rospkg\src\ file the line

#include <tf2_geometry_msgs/tf2_geometry_msgs.hpp>

was changed to

#include <tf2_geometry_msgs/tf2_geometry_msgs.h>

It may be worth supporting with these changes ROS2 Foxy.

Still, I have questions I’d like to address.

First, I am looking as people before me, to recognize static obstacles like stairs. With better resolution of dynamic recognition. Therefore I have tried to learn about the 3D_People_Tracking example that is better for dynamic recognition. and the Area_Scanner example that is better for static recognition.

I am using the IWR6843AOP device. And i was hoping that the Small_Obstacle_Detection example would give the benefits of the two.

But as for the last version of the mmwave industrial toolbox (4.12.1), it supports only the IWR6843Risk device. (which has more antennas than the IWR6843AOP).

And in the updated mmwave radar toolbox (1.20.0.11) the Small_Obstacle_Detection example supports the IWR6843AOP device by enabling virtual antenna array. (with the antGeometry0/1 cli commands) but it is based on the 3D_People_Tracking that uses the capon algorithm.

(I have seen that you recommended someone to use the AOP_3d_Tracking_Small_Obstacle _Indoor.cfg file for this purpese)

I think to know that for examples based on out of the box example. Static recognition can be enabled by sending the clutterRemoval cli command. And for examples based on the 3D_People_Tracking static clutter Removal is forced by the software. But saved and can be shown by the staticRangeAngleCfg cli command.

Is all this correct?

Does the ros driver supports the new radar toolbox version. Is seemed to start showing and then crash.

And is the mmwave industrial toolbox going to continue the line they started that the Small_Obstacle_Detection example is based on the out of the box demo.

Or may the new out of the box demo (that gives better support on this issue as shown in the Presence and Motion Detection example) for the new xWRLx432 Device may also be applicable for the old devices?

I was asked to give better resolution for static recognition and with better angle resolution that is actually is a better movement resolution.

And I don’t know how to make the best of what you give by now.

Second I’d like to ask about using the tracking data and applying it to show boundary boxes. Within the ROS2 driver. And showing it within the rviz2 simulator.

If are there plans to do so. And if I wish to do so, what advice would you give me.

Thanks again for your help.

It seems you did most of the work of transforming the ROS driver to ROS2.

Hello,

1. In the \ros2_driver\src\ti_mmwave_rospkg\src\ and ros2_driver\src\ti_mmwave_rospkg\msg\ folders, exists the following folders:

build, install, log

these seem not to part of the source code but rather inserted by a colcon build command.

This should have been deleted and was missed by me. This was when I was debugging the package directly. 

2. In the \ros2_driver\src\ti_mmwave_rospkg\launch\ folder all launchers use the line

path = "/home/vboxuser/mmwave_ti_ros2_ws/src/ti_mmwave_rospkg/cfg/

*******.cfg";

These lines need to be changed for the launchers to work.

This is correct and the ROS User guide will be updated to point this out better.

3. While compiling the serial package within the ros2 driver workspace with colcon build, the following warning appeared: 

4. While compiling the ti_mmwave_rospkg serial package within the ros2 driver workspace with colcon build, the following warning appeared:

I also get these warnings but have not had issues running the core of it. Over time these will be fixed out.

I sincerely appreciate your feedback here.

1. In the Out of Box demo/Bartlett algorithm chain, points deemed to have 0 doppler are removed from the point cloud if clutterRemoval is turned on. In the people tracking/Capon algorithm chain, the same effect is done by having static turned off with the 0 in this line: staticRangeAngleCfg -1 0 8 8. So yes your interpretation is entirely correct.

2. Small_Obstacle_Detection example is no longer based on Out of Box demo, as we moved to the Capon algorithm due to its better processing potential with better detection at the cost of requiring more performance out of the SoC. Earlier versions of the Industrial Toolbox did indeed have that OOB based SOD.

For 6843AOP I ultimately recommend the 3D People Tracking or Out of Box demo binary examples. For the launch file 6843AOP_Standard.py use the binary xwr64xxAOP_mmw_demo.bin which does not have tracking. For tracking, use 6843AOP_Tracking.py with 3D_people_count_68xx_demo.bin flashed.

Tracking data is currently not being visualized, but is being sent via the radar_track_array which can be seen via doing a rostopic echo on this publisher. For this release we wanted core functionality out the door, and visualization of the tracker is something we will be adding later down the line.

For visualization of the tracker, I would recommend using Marker in visualization_msgs. Create a transparent cube using the posx posy and posz outputted by radar_track_array's radar_track_contents. There will be a radar_track_contents per track. Then publish this Marker and have the rviz config file subscribe and visualize it.

Best Regards,

Pedrhom