• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 633 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.

IWR6843AOPEVM: Crashing with config from sensing estimator

Morten Nissov
Intellectual 380 points
Part Number: IWR6843AOPEVM
Other Parts Discussed in Thread: IWR6843AOP

I'm in the process of tuning parameters to improve radar performance, for our application we need low range, high resolution sensing. We're using the IWR6843AOPEVM rev F and the sensor is flashed with the OOB binary (out_of_box_6843_aop.bin) from industrial toolbox 4.12.1. Find the config file at the bottom of this post

The config file was generated using the ti sensing estimator, starting off with the "short range default" config and setting the following parameters

  • max range: 15m
  • range resolution: 4cm
  • max vel: 9 km/h
  • vel res: 0.6 km/h
  • rate: 10 Hz
  • typical detectable object: child (0.5)

This results in the sensor crashing very soon after loading when using the ti demo visualizer. And w/ the ros node it crashes returning:


Note, the reported values don't agree in frame time with the frameCfg, one says 30Hz and the other says 100Hz



My best guess is its requiring too much either in terms or cube size or processing power, but if that's the case the sensing estimator should warn for this and it doesn't for me.

low_range_starting_point.cfg

  • 0
    TI__Mastermind 23347 points

    Hello Morten,

    This actually is not an issue on the sensor side but on the ROS Driver side. If you were to use that same exact CFG with the Python visualizer provided in the Industrial Toolbox, it would start fine. The issue is the ROS Driver only looks for the word "Done", and if you notice after sensorStart, the newer binaries tend to output a Debug Init Calib line rather than "Done" so it force closes the driver. To remove the improper force close, go to mmWaveQuickConfig.cpp in the src folder of the ros_driver. Then remove the conditional check for "Done" and anywhere it tries to return 1, and ensure parser.ParamsParser(srv, nh); always occurs. Finally do a catkin_make in terminal on the ros_driver to build with your new changes.

    We are aware of this issue and has been fixed for next update of the ROS Driver.

    Best Regards,

    Pedrhom Nafisi

  • 0 in reply to Pedrhom Nafisi
    Intellectual 380 points

    This crashing occurs with the ti demo visualizer as well, which I mentioned in the original post.

    I don't have the python visualizer up and running, so can't comment on this.

    Edit: Just had a realization, I'm not sure that your reasoning makes sense. As I mentioned, the ros driver works fine with the 6843_3d.cfg file. So clearly the driver in and of itself it not the problem. Not to mention the fact that the demo visualizer doesn't work with this config either.

    This means the problem should be with the config-radar interaction, and by extension a failing of the sensing estimator, right?

    Edit 2: Just tried the python visualizer with the following config files

    • custom short range config from sensing estimator (attached in OP)
    • default short range for iwr6843AOP from sensing estimator
    • default short range for iwr6843AOP from demo visualizer

    None of the config files generated from the sensing estimator worked, only the one from demo visualizer worked. The sensing estimator configs resulted in the command prompt, repeatedly printing out:

    doesnt_work.cfgworks.cfg

  • +1 in reply to Morten Nissov
    TI__Mastermind 23347 points

    Hello Morten,

    My mistake for misreading and not realizing it was also crashing TI Demo Visualizer. So my initial response was based off of your second screenshot where it shows the error to be "mmWave Sensor did not respond with "Done"". There are many configurations known to work even when the final line says "Debug: Init Calibration Status", so it was possible the config you were giving it fell under this category. Now lets say that change was done, if the configuration requires too much out of the radar cube, it will crash later in the process and still won't run. 

    Back to the python visualizer, that error you got which I like to dub the "magic word" error is what happens when the sensor outputs nothing. The very first thing the sensor outputs when sending a packet is the magic word in order to synchronize the UART and have a consistent pattern of knowing what kind of data follows this magic word every time. When this fails that means the sensor did not even start which means one of two things: invalid configuration parameter or radar cube size is too large. You have been pretty much correct with your assumptions with what is going on, and I agree the mmWave Sensing Estimator can be improved to include warnings where a certain set of parameters could cause a sensor crash. The problem is that profileCfg through frameCfg lines is only some of what goes into the radar cube. There are different features and functions from binary to binary and things can differ from device to device. The same exact parameters could work with the Bartlett chain but not with the Capon chain. There are a massive amount of variables which makes it difficult to create a all in one estimator that warns the user on everything, but improvements to it are actively in development.

    For now the sensing estimator is a good way to determine what your actual performance is like numerically as in what is the max range, range resolution, max velocity, etc with some warnings of potential issues. This information can be seen on the Chirp Design and Tuning tab of the sensing estimator.

    Best Regards,

    Pedrhom Nafisi

  • 0 in reply to Pedrhom Nafisi
    Intellectual 380 points

    No worries, in hindsight it sounded accusatory. Sorry about that, just wanted to keep the debugging process very clear, and I must admit I was slightly frustrated in that moment :).



    In conclusion, this config is likely just too taxing for the setup currently running onboard the radar, even if the sensing estimator thinks it should be fine. I understand it must be difficult to account for everything.

    Note, the short range default from the sensing estimator crashes as well. Since it's a default config I assume it hasn't been min-maxed to bring the performance to the limit.

    Note, for what difference it makes the sensor is running the out of the box demo binary, I assume this is one of the more lightweight setups one could have?

  • +1 in reply to Morten Nissov
    TI__Mastermind 23347 points

    Hello Morten,

    This stuff is definitely not easy, so your frustration is very understandable. We are trying to make understanding and using Radar easier every day, and there is still much to do. Your logic is correct that the config in its current form is too taxing on the sensor in a certain way (and unfortunately not obvious in WHAT way it is too taxing) which prevents the sensor from starting. When looking at your works.cfg vs doesnt_work.cfg, from my experience I would guess your specific issue is revolving around the idleTime, adcStartTime, and rampEndTime. If you notice in your works.cfg you have a large idleTime of 359 while in doesnt_work.cfg it is 7. Below is the diagram of all the parts that go into a single chirp. This is all setup by profileCfg, the most influential parameter in Radar characteristics and detection behavior. If any of these individual parts do not have enough time to do their job then the sensor will not start if that makes sense. 

    It is almost always best to start from Out of Box Demo binary because it is as you guessed the "lightest" in radar cube space, and also start from a default configuration. Then from there change values one or two at a time in order to min/max the setup for your use case. It ends up being a bit of trial and error at a certain point when trying to min/max, but my suggestion for quickest trial and error runs being via TeraTerm and seeing if that Data port outputs anything at all after sending a cfg, or via the Python Visualizer and seeing if you get the magic word error or not.

    Best Regards,

    Pedrhom Nafisi