This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[FAQ] Linux/AWR1642BOOST: ROS Development and Customization

Part Number: AWR1642BOOST
Other Parts Discussed in Thread: AWR1642

Tool/software: Linux

Hello,

I have completed the ROS demo using the 2.0.0.4 SDK on the AWR1642BOOST. The unit is flashed with the Demo binary file from the SDK.

I was working with the Automotive Toolbox v2.2.0 Short Range Radar Lab and was looking to collect the point cloud/velocity data from this lab. It uses a different binary, features different chirp configurations and outputs more data.

My question is how do I modify the existing ROS implementation to collect and publish the additional data over serial. What cpp files should I be looking at? Are there any resources I can look at for this? The Short Range Radar Lab binary file causes an error when reading it with ROS. Ideally, I'd like to recreate the MATLAB GUI from the lab with ROS.

Cheers,

Lindsay

  • Hello Lindsay,

    The ROS Point Cloud Visualizer lab (dev.ti.com/.../ ) contains the mmWave ROS driver code that parses the UART data stream coming from the mmWave sensor inside the file ti_mmwave_rospkg/src/DataHandlerClass.cpp.

    The DataUARTHandler::sortIncomingData() function in that file performs the parsing and just converts the X, Y, Z, and Intensity of each detected point from the mmWave SDK demo format to the ROS PointCloud2 format which is then published as a topic in ROS. This function would need to be modified to parse the additional data coming from the other demo and publish it to the desired ROS topic.

    There is also more information about the PointCloud2 format in the following thread.
    e2e.ti.com/.../2495769

    Please mark the thread as answered if your question is resolved or reply if you have more questions.

    Regards,
    John
  • Okay, after having looked at the "sortIncomingData() function in DataHandlerClass.cpp I noticed a few fields I need to change. I decided to try and modify this script to accept data from the AWR1642 Obstacle Detection Lab in the automotive toolbox since it had the best documentation. I changed the header size to 40 bytes as in the lab user manual and noticed that all the header categories were the same ones used in the .cpp script.

    I also noticed that the TLV values in the image below were all set up in switch cases in the cpp script.

    The Data I'm looking for from the ODS lab are the "range doppler" and "azimuth static heat map".

    In the cpp file, Azimith static heat map looks like this:

           case READ_AZIMUTH:
                {
            
                  i = 0;
                
                  while (i++ < tlvLen - 1)
                  {
                         //ROS_INFO("DataUARTHandler Sort Thread : Parsing Azimuth Profile i=%d and tlvLen = %u", i, tlvLen);
                  }
                
                  currentDatap += tlvLen;
                
                  sorterState = CHECK_TLV_TYPE;
                }
                
                break;

    What would I have to do here to publish the azimuth values as a rostopic? Am I on the right track? Any Resources I should look into?(unfortunately, the last link you sent appears as a broken url)

  • Hi Lindsay,

    The link I provided earlier should be working now. The mmWave Sensors forum was merged into the overall Sensors forum and old links were temporarily unavailable.

    Yes, I think you are on the right track. That READ_AZIMUTH code snippet was put there as a placeholder in case more functionality needed to be added in the future. You can look at the READ_OBJ_STRUCT code as an example of actually processing data instead of just discarding it like the current READ_AZIMUTH code does currently.

    I believe the ODS lab seems to use the same Frame header format as the standard mmWave SDK mmw (out-of-box) demo which the ROS visualizer normally works with so that should make everything much easier. Please note that most other labs may have a different Frame Header format which would require changing the ROS READ_HEADER code.

    Please note that you would also need to replace the ti_mmwave_rospkg/cfg/1642_2d.cfg file with the desired sensor config file from the ODS lab (which would need to enable the Azimuth Heat map if you want that data).

    There are no other TI resources for publishing ROS topics but ros.org has good information. Please see the following links.
    wiki.ros.org/.../Tutorials
    wiki.ros.org/.../WritingPublisherSubscriber(c++)

    Please reply if you have more questions or mark the thread as answered.

    Regards,
    John
  • I got the ROS code working with the ODS binary by sourcing the ODS config file and modifying the mmWaveQuickConfig.cpp file to no longer require a 'Done' signal from the radar.

    The point cloud from the sensor is coming in over RViz but the switch cases in DataHandlerClass.cpp are never triggered for the case where MMWDEMO_OUTPUT_MSG_AZIMUT_STATIC_HEAT_MAP or MMWDEMO_OUTPUT_MSG_RANGE_DOPPLER_HEAT_MAP are the required field.

    I enables a ROS_INFO line to show what tlvType is being seen on each iteration (ROS_INFO("DataUARTHandler Sort Thread : tlvType = %d, tlvLen = %d", (int) tlvType, tlvLen); ) and I only see types 1,2,3,6. Upon inspecting mmWave.h, tlvTypes 4 and 5 are the missing AZIMUTH_STATIC_HEAT_MAP and RANGE_DOPPLER_HEAT_MAP.

    Any idea why I'm not seeing these 2 signals from the sensor? The ODS lab documentation says these signals should be included in the output.

  • Hi Lindsay,

    If you are using the config file that comes with the Obstacle Detection lab then it looks like it does not enable the Range-Azimuth Heatmap or the Range-Doppler Heatmap by default. Those plot enable options are parameters of the guiMonitor CLI command in the config file. You can look at the mmWave SDK user guide for a description of the parameters for the CLI commands (section "3. 4. Configuration (.cfg) File Format"). Also, when you enable either of those plots the device has to send much more data across the UART port to the PC. If the frame periodicity configured in the config file is too small (meaning that the frame rate is too fast) then the demo may crash since it cannot send the data fast enough across the UART port due to the speed limitations of that interface. In that case you can increase the frame periodicity in the config file to avoid the issue. The frame periodicity is a parameter of the frameCfg CLI command. You can also find information about it in the mmWave SDK user guide.

    Regards,
    John