Configure 4D Radar

[jruths]

Our new 4D radar has ROS "drivers" (nodes that communicate directly with the device and publish messages with data). We need to include this in the vehicle_interface dockerfile and test that it works.

[jruths]

Here is the model information:

Smart Micro (SMS-DRVEGRD-169) DRVEGRD 169 Automotive
4D/UHD RADAR - Point Cloud Output

Link to the product information

Which also has a link to the ROS2 driver github

[ljmullings]

16/09/2024 Update:

Status: Compiling all needed dependencies, installs, (code to add to Dockerfile)
Next Steps: Testing and adjusting any configuration, dependent inconsistencies, (Migrating driver from FOXY -> Humble)
Projected Completion: 21. September 2024 (~5 hours)
Update: I’ve learned the complexities of integrating a radar sensor like Smartmicro DRVEGRD with ROS2, specifically navigating potential conflicts between ROS2 Foxy and Humble. I’ve gained some experience modifying Dockerfiles to install necessary dependencies, clone and build drivers and handle the networking interface configurations for sensor communication. I've researched the nuances of managing potential build errors due to API changes between different ROS2 versions, especially when resolving package dependencies such as the point_cloud_msg_wrapper. I’ve become familiar with sensor interfacing via Ethernet and the code flow for processing and publishing sensor data as ROS messages, which involves both real-time data from the sensor and using pre-recorded PCAP files for testing.

[ljmullings]

23/09/2024 Update:

Status: Writing dockerfile, and compiling an entrypoint script for the 4D Radar (src/drivers/4d_radar) . Roadblocked by VPN malfunctions (temporary), planning to move into occupancy grid activities and msg testing in next week. Changes are uncommitted.
Next Steps: Testing new dockerfile
Projected Completion: 25. September (~5-10 hrs + msg testing needs some more thought)
Update:

• Created new repository and set up for radar
• Realized this is the wrong approach (my bad)
• Refactored and investigated Ouster Lidar
• Verified new approach
• Implementing new approach (VPN wouldn't allow for it )
• personally decided that Ethernet is a better choice for the radar for the following reasons:
  • Bandwidth: Higher throughput, (CAN is 1-5Mbps) (Ethernet 100 Mbps to 1 Gbps)
  • Lower latency and high reliability: system is critical and relies on timeliness of predictions to make decisions
  • More complex communication protocols and packet handling, beneficial for the detailed point cloud data we want (CAN is limited in size)
  • Larger data capacity ensures ML models can be deployed without losing critical detail
• Setup installs (hasn't been tested)

[ljmullings]

30/09/2024 Update:
Status: Finished writing dockerfile configuration, evaluating need for entrypoint shell script, preparing for pcl -> occupancy process
Next Steps: Testing pcl messages/making pull request + commit
Projected Completion: 30. September
Update:

• tried several different versions of a dockerfile structure
• researched how smart micro is integrated
• researched ethernet vs CAN (current setup is configured for both)
• researched dockerfiles a bit more ( I had the wrong idea)
• Wrote and tested a dockerfile, created subdir 4d_radar, currently has generic structure