High End Corner Radar Users Guide

Table of Contents

Overview

This demo is a reference application to showcase the implementation of mmWave High-end Corner Radar using AWR2944/AWR2x44P. This demo assists in the development of software applications to meet NCAP R79 safety requirements.

Requirements

Hardware and Requirements

Item Details
Device AWR2944 EVM, AWR2x44P EVM
Computer PC with Windows 7 or 10. If a laptop is used, please use the ‘High Performance’ power plan in Windows.
Micro USB Cable 1x Micro USB cable for mmWave sensor.
Power Supply 12V, >2A with 2.1-mm barrel jack (center positive).

Software Requirements

Tool Version Required For Download Link
TI mmWave MCU+ SDK 04.07.00.01 Building the application, flashing the image Link
Python 3.x Flashing Link
Python Libraries: pyserial, xmodem, tqdm Latest Flashing pyserial, xmodem, tqdm
Code Composer Studio 12.8.0 Rebuilding the Lab Link

Quick Start

The quickstart guide will cover setting up the EVM for flashing (UART boot mode) and functioning (QSPI boot mode), flashing the firmware, and running the demo.

1. Setup the EVM for UART Boot Mode (flashing mode)

Connect the EVM to the PC via a micro USB cable. For this lab, only the XDS_USB connector needs to be connected.

Now, set the EVM to UART boot mode to enable flashing. This is done by changing the SOP jumpers/switches to the settings specified by the following table:

SOP0 Jumper/Switch SOP1 Jumper/Switch SOP2 Jumper/Switch Description
1 1 0 No-Boot Mode
ROM does not execute in this bootmode.
1 0 1 UART Boot Mode
ROM receives the secondary boot loader via UART interface MSS SCI A and loads it in SoC memory and switches to SBL execution.
SBL receives multicore application image via UART interface MSS SCI A and loads it in SoC memory and switches to application image execution.
1 0 0 QSPI Boot Mode
ROM loads the SBL from serial flash at flash offset of 0x0, and SBL loads the multicore appimage from serial flash at flash offset of 0xA0000.

After this, the EVM needs to be power cycled by pressing the NRESET button on the EVM for the SOP pins to latch.

2. Flash Lab Binaries

To experiment with High End Corner Radar lab, an EVM with the corresponding image flashed is needed.

The following binary needs to be flashed to the EVM to start experimenting with the High End Corner Radar lab. These binaries have been pre-built for ease of use.

Platform BIN Name Location
AWR2944 awr2944_corner_radar.appimage <LAB_LOC>/prebuilt_binaries/awr2944
AWR2x44P awr2e44p_corner_radar.appimage <LAB_LOC>/prebuilt_binaries/awr2x44p

Install Python 3.x and the libraries mentioned in the software requirements section of this document. For usage of the script, refer to the mmWave MCU+ SDK User Guide section: 4.2 “How to flash an image onto mmWave EVM”.

To identify the correct COM port number to be used, go to the Device Manager window on you PC. Under ports, the ports corresponding to AWR2944 EVM should appear as:

Once flashing completes, set EVM to QSPI Boot Mode as per Table 1. to execute application flashed.

To run AWR2x44P HECR, flash SBL located at <LAB_LOC>\prebuilt_binaries\awr2x44p\SBL_BSS_DSS_MAILBOX\sbl_qspi.release.tiimage. In AWR2x44P HECR, mmwavelink runs on DSS only. To enable mailbox communication between BSS and DSS, the following change has to be made in mcu_plus_sdk_awr2x44p_10_00_00_07\source\drivers\soc\awr2x44p\soc_rcm.c file.

In SOC_rcmPopulateBSSControl function, RSS_CR4_BOOT_INFO_REG3 should be set to 0x8000U instead of 0x80U. After this change drivers library has to be rebuilt and once drivers library is built, rebuild the SBL.

3. Setup the EVM for QSPI Mode

Set the SOP jumpers/switches to configuration corresponding to QSPI boot mode as per the table in section 1. After this, power cycle the device by pressing the NRESET button on the EVM.

4. Running the Lab

GUI Display screens

Plot 1 (XY Scatter Plot):

Plot 2 (YZ and Range-Doppler Scatter plots):

Plot 3 (3D surround scatter plot):

For more details on the functionality offered by the GUI, refer to the developer guide.

Developer’s Guide

Overview

The High End Corner Radar lab has been made as an extension of the Out of Box Demo in the mmWave MCU+ SDK 4.7.0.1. In particular, the lab uses the OOB demo based on the SDK DDMA (Doppler Division Multiple Access) data processing chain as the base. The DDMA chain is used to meet the requirements for the high end corner radar, particularly the maximum velocity and range.

The <LAB_DIR>/src/2944/demo folder corresponds to the OOB demo of AWR2944 from the SDK. Modifications have been made to this demo. Briefly, they involve:

  1. Adding group tracker (gtrack) to the processing chain. Gtrack runs on the MSS.
  2. Adding RANSAC (see TI Design document for details) to the processing chain. RANSAC runs on the MSS. RANSAC is responsible for filtering out stationary objects in the pointcloud before sending this data to the group tracker. Since the sensor itself is in motion, this is not a trivial task, hence the need for RANSAC. The RANSAC filter is also exported to over UART to the GUI. The GUI will draw each point as smaller/larger depending on the RANSAC filter.
  3. Parallelizing the MSS and DSS operation. When DSS has processed frame i upto the pointcloud, the MSS will start processing frame i. During this, if the next frame, frame i+1 starts being acquired, the DSS is capable of processing it in parallel. This is necessary to meet the timing requirements.
  4. Suggestion: Disable range CFAR. The SDK’s DDMA chain uses CFAR along two dimensions: range and doppler. We suggest to disable the range CFAR to obtain a richer pointcloud. By default, it’s enabled <LAB_DIR>\src\demo\awr2944\common\chirp_design_HECR.h.
  5. DPM layer is an additional layer used for communication between MSS and DSS. This consumes additional memory, so in this demo we have removed DPM layer and replaced with simple IPC communication.
  6. CLI library is not used anymore. Instead, the configuration is stored in the header file - <LAB_DIR>\src\demo\awr2944\common\chirp_design_HECR.h.
  7. mmwave layer is also removed in this version of HECR. mmWave layer API calls is replaced with simple mmwavelink API calls. Currently, Legacy frame implementation is tested. Support for Advance frame and Advance Chirp is not fully implemented. To use advance frame or advance chirp, refer to the SDK demo.
  8. Integrated streaming of Object data over CAN.
  9. Provided the configurability to run mmwavelink either on MSS or DSS.
  10. Support is added to enable LVDS streaming

In case of AWR2x44P HECR, mmwavelink runs only on DSS in the current version. For an application having mmwavelink on MSS, refer to SDK demo.

Apart from this, the datapath was modified subtly from the SDK datapath. If the lab uses a modified SDK component, it has been packaged with the lab in the /src/ folder (both source and compiled library). This is done so that the SDK installation doesn’t need to be modified to rebuild the lab. As the lab will use any modified dependencies from its own src/ folder, it is self-contained in this regard.

Rebuild Application & Tool

  1. Rebuild application using makefile build system:
    • Navigate to mmwave_mcuplus_sdk_04_07_00_01\mmwave_mcuplus_sdk_04_07_00_01\scripts\windows and set the appropriate environment variables by running setenv.bat. Check the device name while setting the environment variables.
    • Now use the same command prompt and navigate to the HECR demo folder - <LAB_DIR>\src\demo\awr2944 or <LAB_DIR>\src\demo\awr2x44p
    • Run gmake help to see the list of demos that can be built
    • Example: gmake hecrMSSLink will build AWR2944 HECR demo with mmwavelink on MSS.

Directory Structure

This lab contains multiple components. The src folder contains the following four components:

  1. Gtrack
  2. Datapath
  3. Demo (High End Corner Radar demo) - AWR2944 and AWR2x44P
  4. Utils

Configurations update

CLI based configuration is removed. Header file is used instead of CLI commands to provide the configuration to the demo - chirp_design_HECR.h.

As the lab is an extension of the out of box demo, most of the commands in the header file correspond to the commands used in the out of box demo. For details on the individual commands and usages, please refer to the SDK user guide.

The High End Corner Radar lab implements a few new commands in the configuration file. The following table gives details on these commands:

Command Usage Description
gtrack gtrack <enable> <maxNumPoints> <maxNumTracks> <initialRadialVelocity> <maxRadialVelocity> <radialVelocityResolution> <maxAcceleration0> <maxAcceleration1> <maxAcceleration2> <deltaT> <boresightFilteringEnable> This command enables/disables the group tracker, and configures it with the appropriate configuration if enabled. Before calling this command, the following commands must be called: appSceneryParams, appGatingParams, appStateParams, appAllocParams. After the enable argument, the rest of the arguments are used to populate the structure “GTRACK_moduleConfig”.
appSceneryParams appSceneryParams <sensorPosX> <sensorPosY> <sensorPosZ> <orientationAzim> <orientationElev> <bBoxX1> <bBoxX2> <bBoxY1> <bBoxY2> <bBoxZ1> <bBoxZ2> This command populates the GTRACK_sceneryParams structure. This is one of the advanced parameter structures passed to the gtrack module.
appGatingParams appGatingParams <gain> <limitsArr0> <limitsArr1> <limitsArr2> <limitsArr3> This command populates the GTRACK_gatingParams structure. This is one of the advanced parameter structures passed to the gtrack module.
appStateParams appStateParams <det2actThre> <det2freeThre> <active2freeThre> <static2freeThre> <exit2freeThre> <sleep2freeThre> This command populates the GTRACK_stateParams structure. This is one of the advanced parameter structures passed to the gtrack module.
appAllocParams appAllocParams <snrThre> <snrThreObscured> <velocityThre> <pointsThre> <maxDistanceThre> <maxVelThre> This command populates the GTRACK_allocationParams structure. This is one of the advanced parameter structures passed to the gtrack module.
ransac ransac <enable> <iterations> <thresh> This command is used to configure the RANSAC algorithm. The algorithm is used to split the pointcloud into a set of points moving/stationary. For details on this, refer to the TI Design document for High End Corner Radar.
rangeCfar rangeCfar <enable> This command enables/disables the CFAR along range direction. This is disabled by default in the lab.

UART data TLV Formats

The High End Corner Radar Lab outputs data over UART in TLV format (Type, Length, Value) packets. For exhaustive details of this process, refer to the source code, particularly the MmwDemo_transmitProcessedOutput function in LAB_DIR/src/demo/mss/mss_main.c.

The rest of this section gives brief details of this format.

Data stream hierarchy:

  1. Data stream is made up of multiple messages. The data stream has one message per frame processed on the device.
  2. Message contains a fixed length message header and a variable length message body. The message header always starts with a 4 byte magic word (0x0102030405060708). The magic word acts as the delimiter for each message in the UART data stream.
  3. The rest of the message header contains a few details for the message (see structure MmwDemo_output_message_header in <LAB_DIR>/src/2944/demo/include/mmw_output.h). The pertinent header field for decoding the output stream is a field called “numTLVs”.
  4. After the message header, a variable length message body follows. This body is made up of multiple TLVs (number specified in header). Each TLV gives one type of data (pointcloud data, tracker data, pointcloud SNR data).
  5. A TLV contains a fixed length header and a variable length body. The TLV header contains the TLV type, and the length of the TLV body in bytes.
  6. The TLV body contains data corresponding to the TLV type. This is an array of a C type (usually a structure). The length mentioned in the TLV header is hence a multiple of the C type for any given TLV.

The following TLV formats are used in the High End Corner Radar Lab:

TLV Type C Structure Description
1
(MMWDEMO_OUTPUT_MSG_DETECTED_POINTS)		 DPIF_PointCloud Cartesian Contains the pointcloud detected for a particular frame.
7 (MMWDEMO_OUTPUT_MSG_DETECTED_POINTS_SIDE_INFO) DPIF_PointCloudSideInfo Contains the sideInfo for the corresponding pointcloud detected for a particular frame. i’th entry in this array (TLV body) correspoinds to the i’th entry in the type 1 TLV array.
10
(MMWDEMO_OUTPUT_MSG_TRACKER)		 MmwDemo_tracker_out Contains the acquired tracks for this frame. Each track corresponds to a target being tracked by the group tracker. This TLV contains information about the position, velocity and acceleration of the target in 3 dimensions.
11
(MMWDEMO_OUTPUT_MSG_RANSAC_FILTER_MASK)		 uint8_t Contains the TLV mask for the corresponding pointcloud detected in this frame. i’th entry here corresponds to the i’th entry in type 1 TLV. If i’th field in this mask is 0, it means the i’th point in pointcloud point is stationary (will be plotted as a smaller point in the GUI). If it is 1, the point is in motion and will be displayed in the GUI as a larger point.

Chirp Configuration

The lab uses the following chirp configuration:

PARAMETER CONFIGURATION
Idle Time (us) 3.5
ADC start time (us) 3.5
Ramp end time (us) 17.33
Number of ADC samples 384
Frequency slope (MHz/us) 8.883
MIMO (1 → yes) 1
Number of chirps per profile 768
Frame length (ms) 50

Factory Calibration

This demo supports the save and restore functionality for factory calibration data.

Save Data to Flash:

  1. Set FACTORY_CALIB_SAVE_ENABLE to 1 in chirp_design_HECR.h
  2. Run the demo once, this run will save factory calibration data to flash. Ideally this will only need to be done once.

Restore Data from Flash:

  1. Set FACTORY_CALIB_SAVE_ENABLE to 0 & FACTORY_CALIB_RESTORE_ENABLE to 1 in chirp_design_HECR.h
  2. From now on the demo will use this data to calibrate on boot up

Monitoring

Monitoring takes place by default. In order to see the values one must access the “gMonDataAeStrct” struct in the CCS Expressions when running.

Antenna Calibration

To calibrate antenna and then use said values for calibration use the following steps

  1. Set ANTENNA_CALIB_ENABLE to 1 in chirp_design_HECR.h, then run the demo.
  2. The calibration data will be outputted to the console.
  3. Take this data and place it in “antennaCalibParams” in MmwDemo_loadDatapathConfig() in mmw_load_params.c
  4. Follow the commented instructions

mmWave Automotive Visualizer

This visualizer plots the X-Y plot, Y-Z plot and Range-Doppler plot with tracker in X-Y and Range-Doppler plot. The GUI in this visualizer can be used to select the Application Port and the Data Port and send configuration file to the AWR2944 device connected. This GUI is based on python and uses a multi threaded environment for efficient and smooth data visualization. Playback of captured data is currently not supported but is expected to come out in a later version of the same.

The dots on the visualizer represent the points from the scene captured by the radar and the tracker (if enabled) appears across the scene in form of X shape if it is tracked as an object by the radar. The small green points represent the stationary objects in the scene whereas the red dots represent moving objects in the same scene. By default, the GUI plots X-Y plot along with tracker.

To run AWR2944 HECR with Object Data over CAN, first set the demo, interface and click connect. After connecting, the application can be loaded on CCS and then run the application. If the application is run first, MSS will be in assert as CAN transmission fails.

References

Download mmWave SDK
Ask question on TI’s E2E forum