• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1322 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Linux/DCA1000EVM: AWR1843BOOST+DCA1000EVM Detection algorithm, Profiles, Calibration, and BPM Processing

Erlik Now
Prodigy 60 points
Part Number: DCA1000EVM
Other Parts Discussed in Thread: AWR1843BOOST, , AWR1843, MMWAVE-SDK

Tool/software: Linux

We use AWR1843BOOST and the DCA1000EVM to get the raw radar signal. We are aiming to use this setup to collect data for our autonomous driving usecase. We are using Ubuntu 18.04 + Python 3.6 for development.

Once we have collected the raw data we need to process it to generate various representations: create ADC from raw signal (processing UDP packets), create the representation after FFTs prior to feeding it to the Detection algorithm (Used to create Range-profile and Doppler-Range, Angle-Range), and generate the final point cloud.

1- Could you please provide us with your SDK that performs processing on Raw radar signal and produces all the various representations? We need to be able to play with parameters to produce adequate data for our use.

2- We have implemented our variation of the CFAR detection algorithm, could you provide us with the source SDK for CFAR that we can use as reference? (Python (preferred), or etc)

To make the AWR1843BOOST function properly we require a valid configuration profile. The default profile on mm_wave_studio crashes the radar at start up through ROS in Ubuntu. More specifically reducing the chirps from 128 to 64 makes the problem go away, but then we loose the absolute velocity ambiguity (drops from +-6m/s to +-3m/s).

3- Could you provide us with a solution to this problem?

4- What is the best configuration profile parameters to cover the long range (100~150 meters) with AWR1843BOOST?

To properly record the real world observations, we need to calibrate the radar sensor.

5- Is there a calibration matrix you can provide, or is there an sdk that could be used for this purpose?

Currently, the mm-wave-studio software is doing TDM-MIMO and the documentation is provided for TDM only. We need to record and process data for BPM-MIMO.

6- Could you please share documentation, code, and let us know how can we use AWR1843BOOST and DCA1000EVM in this mode to capture and properly process the resulting data?

Thank you

  • 0
    TI__Mastermind 24955 points

    Erlik,

    If you are planning on using the AWR1843BOOST + DCA1000EVM with mmWave Studio, then you will need a Windows PC in order to do that. mmWave Studio has only been released for Windows and there are no current plans for a Linux release.

    You can download the latest version of our mmWave SDK here: http://software-dl.ti.com/ra-processors/esd/MMWAVE-SDK/latest/index_FDS.html

    You can take a look at the MRR demo leverage the chirp provided in the lab to cover longer ranges as specified in your thread: http://dev.ti.com/tirex/explore/node?node=AObIl5yAPR-DjIwxgdgyuA__AocYeEd__LATEST

    Regards,
    Kyle

  • 0
    TI__Guru*** 148534 points

    Hi,

    mmWave Studio is not supported for Linux.

    It seems that you are using a customer setup. We are not able to provide support for ROS and other components not used in our demos.

    We can provide you support for the chirp configuration and other related information.

    Which SDK do you have in mind.

    The mmWave SDK supports the AWR1843 device. It does not include matlab code

    Thank you

    Cesar

  • 0 in reply to Kyle Cousino
    Prodigy 60 points

    Kyle,

    Thanks for the quick reply.

    Regarding Processing pipeline and CFAR, we will look into mmWave-SDK to see if it contains everything we need.

    We will try to use the suggested configuration in http://dev.ti.com/tirex/explore/node?node=AObIl5yAPR-DjIwxgdgyuA__AocYeEd__LATEST to see if it will function well. And we will write about our findings here. Do you think this configuration works with DCA1000?

    Lastly, do you have any suggestions regarding the Calibration and BPM-MIMO modes?

  • 0 in reply to Kyle Cousino
    Prodigy 60 points

    Hi,

    We have flashed "xwr18xx_demo.bin" from mmWave-SDK 3.02 to the sensor.

    We have used the MRR parameters from the following table as the SRR and USRR are not usefull for us.

    The detailed parameters are listed in this .cfg file:

    % ********** Main Parameters ****************
% User Description: ti MRR Range 125m doppler 63kmph
% Frequency (GHz): 77
% Maximum unambiguous Range (m): 138.87500000000003
% Range Resolution (m): 0.27775000000000005
% Maximum Radial Velocity (m/s): 17.63124676818665
% Maximum Radial Velocity (km/h): 63.47248836547194
% Radial velocity resolution (m/s): 0.1377441153764582
% Radial velocity resolution (km/h): 0.4958788153552495
% Frame Duration (msec): 100
% Number of Frames: 0
% Number of Transmitters: 2
% Number of Receivers: 4
% **********************************************

% ********** Secondary Parameters ****************
% Number of ADC Samples: 500
% Number of chirps per loop: 128
% ADC Start Time (usec): 6
% ADC Sample rate (ksps): 11110
% Chirp Slope (MHz/usec): 12.0
% Chirp Idle Time (usec): 10
% Chirp Ramp End Time (usec): 45
% Transmitters to enable (binary index): 101
% Receivers to enable (binary index): 1111
% **********************************************

sensorStop
flushCfg

dfeDataOutputMode 1
channelCfg 15 5 0
adcCfg 2 2
adcbufCfg -1 0 1 1 1
profileCfg 0 77 10 6 45 0 0 12.0 1 500 11110 0 0 30
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 4
frameCfg 0 1 128 0 100 1 0
lowPower 0 0
lvdsStreamCfg -1 0 1 0

% Post-Processing Parameters
guiMonitor -1 1 1 0 0 0 1
cfarCfg -1 0 2 8 4 3 0 15 1
cfarCfg -1 1 0 8 4 4 1 15 1
multiObjBeamForming -1 1 0.5
clutterRemoval -1 0
calibDcRangeSig -1 0 -5 8 256
extendedMaxVelocity -1 0
compRangeBiasAndRxChanPhase 0.0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0
measureRangeBiasAndRxChanPhase 0 1.5 0.2
CQRxSatMonitor 0 3 4 35 0
CQSigImgMonitor 0 31 4
analogMonitor 0 0
aoaFovCfg -1 -90 90 -90 90
cfarFovCfg -1 0 0 138
cfarFovCfg -1 1 -17 17

    In these settings, sensor works only if we reduce number of samples per chirp to 256 (original 500) and reduce number of chirps to 64 (original 128).

    Could you please take a look at the parameters being used and suggest a solution for this issue.

    Thanks

  • 0 in reply to Erlik Now
    TI__Guru*** 148534 points

    Hi,

    For MRR you will need to use the configurations provided with the demo.

    The numbers provide in the tables are based on a processing chain without clustering and tracking.

    Thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 60 points

    As far as we know, the "xwr18xx_demo.bin" we used does not include clustering and tracking in its processing chain.

    We got the chirp configurations from this pdf http://www.ti.com/lit/an/swra553/swra553.pdf . We are not currently using the MRR demo, as it seems to require a Windows machine. Would the MRR demo work with the DCA1000EVM capture board? If so how? We only need to output the raw data over the LVDS channel, and we can handle the rest.

    Thank you

  • 0 in reply to Erlik Now
    TI__Guru*** 148534 points

    Hi,

    There is some confusion. The process to capture raw data does not require to flash a binary on the target. You should not flash "xwr18xx_demo.bin"

     

    Please follow directions in this video training

     

    training.ti.com/dca1000-training-video

     

    Thank you

    Cesar

     

     

  • 0 in reply to Cesar
    Prodigy 60 points

    Hi,

    Since we are using Ubuntu as our OS, we do not have access to mmWaveStudio for our main capture pipeline, though we can use Windows to test the board and its configurations. However, we have already managed to use the demo binary in combination with our own Python script to get raw data from the AWR1843+DCA1000EVM on Ubuntu.

    The demo binary seems to have some limitations, as settings that work properly when using mmWaveStudio do not allow the AWR1843 to start capture properly when using the demo binary. Using the config file attached before, we do not get a "Done" response from the AWR1843, and it does not start frame capture.

    Since we can take care of programming the DCA1000EVM board ourselves, we only need a binary image for the AWR1843 that will function with the appropriate radar parameters while sending data out over the LVDS lane. Could you provide this to us?

    Alternatively, we would need to figure out which issue is preventing our current configuration from functioning with the latest demo binary. Could you suggest a fix for this issue?

    Thank you,
    Erlik

  • 0 in reply to Erlik Now
    TI__Guru*** 148534 points

    Thank you

    I think I understand now what you are trying to do.

    Your question is basically why the mmwave SDK 3.2 demo does not work with the MRR configuration mentioned above.

    The reason for that is that the mmwave SDK demo was designed to showcase as many features as possible of the mmwave sensor. For that reason it includes a lot of buffers that can be exported to the host to display in the GUI or save to a file

    Because of this, some of the memory is dedicated to these buffers.

    There is not enough memory to support the MRR use case mentioned above.

    You would need to use the MRR demo I mentioned before for this type of use case.

    thank you

    Cesar

  • 0 in reply to Cesar
    Prodigy 60 points

    Hi,

    As far as we can tell from looking at the MRR demo from the Automotive Toolbox Labs, turning on the LVDS setting in the included binary file would send partially processed data to the DCA1000EVM. Could you confirm this?

    If this is correct, could you recommend a way of modifying the DSS/MSS source files to stream raw ADC data over the LVDS lanes?

    Thank you,

    Erlik

  • 0 in reply to Erlik Now
    TI__Mastermind 24955 points

    Erlik,

    Yes, for the MRR TI Design, the LVDS lanes are being used to just transfer Object Detection data to the PC.

    For questions relating to implementing ADC data streaming over LVDS, please refer to the documentation included in the Doxygen for SDK 3.2 on the Out-of-Box Demo. There is a section titled "Streaming data over LVDS" that includes steps for implementation.

    Regards,
    Kyle