Naive 3D Scanning Radar

[aaronchongth]

Changes:

• Replaces the mbzirc_naive_spinning_radar with mbzirc_naive_3d_scanning_radar, due to low RTF issues (40% RTF) when sampling at very high rates (250Hz) to match the specifications of the Wartsila RS24. RTF is now relatively high (90% on my machine, awaiting more testing)
• Using a static 3D GPU LiDAR to match the scanning resolution. This approach will leave a lot of gaps for detection, especially at long distances.
• Outputs in the format accepted by naive_radar_bridge

Possible further improvements:

• amplitude of scan. There was an original implementation by @arjo129, but I haven't tried adapting that into this method. Not too sure if it is even possible
• Since the job of the plugin is somewhat just filtering acceptable values, we can possibly even write everything into the bridge, where the bridge accepts ignition laser scans, and outputs ROS 2 radar messages.
• I have not been able to find any relevant information regarding the sensor noise of the Wartsila RS24. At the moment, it is using the same basic gaussian noise as in mbzirc_naive_radar
• Debugging output, I couldn't find any existing tool to visualize or ensure that the radar output is accurate

How to try it out:

ros2 launch mbzirc_ros competition_local.launch.py ign_args:="-v 4 -r coast.sdf"

ros2 launch mbzirc_ign spawn.launch.py name:=usv world:=coast model:=usv x:=-1462 y:=-16.5 z:=0.3 R:=0 P:=0 Y:=0 slot0:=mbzirc_naive_3d_scanning_radar

ros2 topic echo /usv/slot0/radar/scan

[iche033]

Did a first pass. Overall looks good. Let's put this in mbzirc_ign/models/sensors and make it a non-custom sensor model. I can help with this. I'll continue to do more testing.

This approach will leave a lot of gaps for detection, especially at long distances.

looking at the spec, it's 1.44 degrees bearing resolution. So I think that's expected? I see that the lidar horz sample count is 60 / 1.44 = 250, which should be correct.

I have not been able to find any relevant information regarding the sensor noise of the Wartsila RS24. At the moment, it is using the same basic gaussian noise as in mbzirc_naive_radar

This is a shorter range radar than the one in mbzirc_naive_radar so we may want to reduce the stddev a little bit. One option would be to set it to roughly the range resolution advertized.

Debugging output, I couldn't find any existing tool to visualize or ensure that the radar output is accurate

The lidar visualization look fine but agree we'll need to manually check the radar msg values.

[iche033]

Let's put this in mbzirc_ign/models/sensors and make it a non-custom sensor model. I can help with this.

I left this in mbzirc_custom since there are custom launch scripts used. Instead, I just restored the spinning radar model in #162

[iche033]

made a minor change in a65456c to unsubscribe to the ign topic if there are no connections from the ros bridge

I noticed that when I do ros2 topic echo /usv/slot0/radar/scan, I only see radar return values with elevation at -0.6981319785118103 but not other elevations. I did verify that we pack data with other elevations through but not sure why it's not being printed out by ros2 topic echo

[aaronchongth]

I noticed that when I do ros2 topic echo /usv/slot0/radar/scan, I only see radar return values with elevation at -0.6981319785118103 but not other elevations. I did verify that we pack data with other elevations through but not sure why it's not being printed out by ros2 topic echo

It looks like it might just be too much data for ros2 topic echo to handle. I found that we were publishing other elevations using a basic subscriber https://gist.github.com/aaronchongth/2e38cd2ab678a9536111b68186908c70

[iche033]

It looks like it might just be too much data for ros2 topic echo to handle. I found that we were publishing other elevations using a basic subscriber https://gist.github.com/aaronchongth/2e38cd2ab678a9536111b68186908c70

ok cool, thanks for verifying this. This PR looks good then.