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. This demo assists in the development of software applications to meet NCAP R79 safety requirements.

Requirements

Hardware and Requirements

Item Details
Device AWR2944 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.04.01.02 Building the application, flashing the image Link
Python 3.x Flashing Link
Python Libraries: pyserial, xmodem, tqdm Latest Flashing pyserial, xmodem, tqdm
Python Libraries: pyqt5, pyqtgraph, collections, gl_classes, pyqtgraph.opengl, pdb Latest Visualizer pyqt5,pyqtgraph,collections,gl_classes,pdb
Code Composer Studio 12.2.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/

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.

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.4.1.2. 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 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. Disabling range CFAR. The SDK’s DDMA chain uses CFAR along two dimensions: range and doppler. We have disabled the second range CFAR to obtain a richer pointcloud.
  5. Since targets from the group tracker have to be displayed, and the pointcloud points will be larger/smaller based on the RANSAC filter being exported, a GUI has been developed in Matlab to handle this. This GUI is packaged with the lab.

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. Using CCS project to rebuild High End Corner Radar application:
    • Check for CCS projects within the folder <LAB_DIR>/src/2944/ and Import the MSS .ccsprojectspec respectively into the CCS project explorer. This should also import the DSS projectspec automatically.
    • Rebuild MSS project (<LAB_DIR>/src/2944/awr2944_corner_radar_mss.projectspec). This should also be the dependent DSS project(<LAB_DIR>/src/2944/awr2944_corner_radar_dss.projectspec)
    • The appimage for the application can be found in the same folder as the MSS project location.
    • All dependencies (gtrack lib) can be built similar in the mmwave SDK (Follow SDK userguide).

Directory Structure

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

  1. Gtrack
  2. Demo (High End Corner Radar demo)

Configurations through CLI

Similar to the out of box demo, the High End Corner Radar lab is highly configurable via the use of CLI commands sent to the device over the user UART COM port. When the lab powers on, a default configuration (corresponding to the file <LAB_DIR>/chirp_configs/default.cfg) will be applied immediately, and the device will start transmitting data over UART.

The user can reconfigure the lab for a different .cfg file by sending an appropriate .cfg file through the GUI. This is an optional step.

As the lab is an extension of the out of box demo, most of the commands in the .cfg 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

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.

References

Download mmWave SDK
Ask question on TI’s E2E forum