• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 215 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: ROS driver causes lockup with working config file

Morten Nissov
Intellectual 380 points
Part Number: IWR6843AOPEVM

I've noticed a strange bug, where the ROS driver causes the sensor to lock up for a given config if the frame periodicity is too high (but still less than 1000ms). This problem does not occur with the demo visualizer.

For example, taking the default config from the demo visualizer (SDK 3.5 and out of box demo), if I set the output rate to 1Hz it works fine when launched from the demo visualizer. But when launched from the ROS driver it locks up the sensor and doesn't output any measurements.

Note, if I change the line frameCfg 0 2 16 0 1000 1 0 to frameCfg 0 2 16 0 100 1 0 then it works again.

I've noticed this behavior for a variety of config files, but the config file in question is:

% ***************************************************************
% Created for SDK ver:03.05
% Created using Visualizer ver:3.6.0.0
% Frequency:60
% Platform:xWR68xx_AOP
% Scene Classifier:best_range_res
% Azimuth Resolution(deg):30 + 30
% Range Resolution(m):0.044
% Maximum unambiguous Range(m):9.02
% Maximum Radial Velocity(m/s):1
% Radial velocity resolution(m/s):0.13
% Frame Duration(msec):1000
% RF calibration data:None
% Range Detection Threshold (dB):15
% Doppler Detection Threshold (dB):15
% Range Peak Grouping:enabled
% Doppler Peak Grouping:enabled
% Static clutter removal:disabled
% Angle of Arrival FoV: Full FoV
% Range FoV: Full FoV
% Doppler FoV: Full FoV
% ***************************************************************
sensorStop
flushCfg
dfeDataOutputMode 1
channelCfg 15 7 0
adcCfg 2 1
adcbufCfg -1 0 1 1 1
profileCfg 0 60 359 7 57.14 0 0 70 1 256 5209 0 0 158
chirpCfg 0 0 0 0 0 0 0 1
chirpCfg 1 1 0 0 0 0 0 2
chirpCfg 2 2 0 0 0 0 0 4
frameCfg 0 2 16 0 1000 1 0
lowPower 0 0
guiMonitor -1 1 1 0 0 0 1
cfarCfg -1 0 2 8 4 3 0 15 1
cfarCfg -1 1 0 4 2 3 1 15 1
multiObjBeamForming -1 1 0.5
clutterRemoval -1 0
calibDcRangeSig -1 0 -5 8 256
extendedMaxVelocity -1 0
lvdsStreamCfg -1 0 0 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 5 121 0
CQSigImgMonitor 0 127 4
analogMonitor 0 0
aoaFovCfg -1 -90 90 -90 90
cfarFovCfg -1 0 0 8.92
cfarFovCfg -1 1 -1 1.00
calibData 0 0 0
sensorStart

  • 0
    TI__Mastermind 22567 points

    Hello Morten,

    I remember you discussing this with us before. With more experience under my belt, I now believe this has to do with an issue with the serial package used by the ROS driver. The absolute maximum supported by the SDK is a frame periodicity of 1333ms and we heavily recommend using a value <1000ms. What is the lowest value you have seen that causes this locking behavior? Also what is the application where you want a configuration with a slow frame periodicity?

    Best Regards,

    Pedrhom Nafisi

  • 0 in reply to Pedrhom Nafisi
    Intellectual 380 points

    Hi,

    Yes, I remember asking this as well. But I didn't see a post in my questions with this information, nor could I find an answer so I figured I would ask "again". Would you happen to remember where the original post is?

    I'm aware of the upper limit of 1333, I have made sure to stay below this, e.g. the 1000ms in the original post. Regarding limits, I can't tell you the minimum periodicity which caused this right now, but I know periodicities >200ms were a problem.

    The application for me is really just testing our hardware synchronization setup, I figured it's easier to see if the sensor/triggering signal are 1-to-1 at lower frequencies. Harder to see a skipped trigger if the sensor is 10Hz.

  • 0 in reply to Morten Nissov
    TI__Mastermind 22567 points

    Hello,

    I believe this was the original post: https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1131957/iwr6843isk-problems-when-frame-time-is-100ms

    The reason I think it is the serial driver, or at least this specific one for ROS1, is due to that being the only delta between how TLVs are read on Windows with a flashed binary versus Linux/Ubuntu. If 1Hz is working with other visualizers or non-ROS setups, then thats what is pushing me in this direction. We have some configs, especially low power ones, that run at 250ms frame periodicity. Not so much low power + ROS but if 250ms is not working either then this is a bigger problem than first scoped. By the next time you post I will test various frame periodicities on my end.

    Best Regards,

    Pedrhom