• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 30 subscribers
  • Views 162 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.

IWRL6432BOOST: Surface Classification Demo: Frame Packet Length Warning

Nien-Ping Chen
Prodigy 30 points
Part Number: IWRL6432BOOST
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hello TI Team,

I am currently working with the IWRL6432BOOST surface classification demo, specifically testing both the GRASS-NOT and WET-DRY modes.

I used UniFlash to flash the image located at the following path:
C:\ti\radar_toolbox_3_00_00_05\source\ti\examples\Industrial_and_Personal_Electronics\Robotics\surface_classification_ML_flow_pytorch\prebuilt_binaries\surface_classification_demo_SDK5502-GRASS-NOT.Debug.appimage

Then I ran the demo using the Industrial Visualizer.
However, I encountered the following warning message:
"WARNING: Frame packet length read is not equal to totalPacketLen in frame header. Subsequent frames may be dropped."

How can I resolve this issue?

(The frame number in Statistics is counting.)

Additionally, I would like to ask:

How can I make the Industrial Visualizer display the WET-DRY label instead of GRASS?

Currently, it only shows the GRASS version. Is that the only available version?

Thank you very much for your support and assistance.

Best regards,

  • +1
    TI__Mastermind 23267 points

    Hello,

    We have found that the frame mismatch error that you see here is an artifact of the Python visualizer. It happens due to the attempted use of multithreading. Python has a Global Interpreter Lock (GIL) which is a mechanism that allows only one thread to hold control of the Python interpreter at any time. This means that the multithreading library is not true multithreading, but simply allows for easier code structure in order to divide actions. That said, we have found that if you remove all multithreading from the visualizer's code, frames will no longer be dropped. Note that the issue as is does not cause issues with subsequent frames, it just causes frames to be dropped occasionally.

    If you want to set it to WET/DRY label, you can change it in the source code. It is merely a label, and what is presented which is the classification (model inference) value is identical across the grass/not grass and wet/dry examples

    Best Regards,

    Pedrhom

  • 0 in reply to Pedrhom Nafisi
    Prodigy 30 points

    Got it! I had no idea the source code was available.
    Now I can give it a try fixing the multithreading bug myself.
    Thanks for the tip!

  • 0 in reply to Pedrhom Nafisi
    Prodigy 30 points


    Hello, I've tried my best to remove most of the multithreading-related code, but I still can't get any results or probabilities to show up.
    I have made modifications to gui_threads.py and gui_core.py.

    Any suggestions would be greatly appreciated.

    gui_threads.py

    commented the Class

    # class parseUartThread(QThread):
# class sendCommandThread(QThread):

    In gui_core.py

    I’ve commented out the original parseData function and replaced it with my own implementation.

    For the other parts of the code that were using QThread, I just commented them out directly.

    # def parseData(self):
#     self.uart_thread.start(priority=QThread.HighestPriority)

def parseData(self):
    if self.parser.parserType == "SingleCOMPort":
        outputDict = self.parser.readAndParseUartSingleCOMPort()
    else:
        outputDict = self.parser.readAndParseUartDoubleCOMPort()

    self.updateGraph(outputDict)

  • 0 in reply to Nien-Ping Chen
    TI__Mastermind 23267 points

    Hello,

    Below is a beta version of our "mmWave Data Recorder" tool. It does not use any threading. Then all you'd need to do is to feed outputDict to the appropriate demo.py and plot.py extensions. As long as the parsing and plotting are separate, it may be okay for the plotting files to continue to use QThread to simplify implementation. Hierarchy of this tool matters, so make sure it is located so the python file to run is at radar_toolbox/tools/mmwave_data_recorder/src/gui_lite.py



    mmwave_data_recorder.zip

    Best Regards,

    Pedrhom