bosch-engineering/off_highway_sensor_drivers

This project provides ROS drivers for Bosch Off-Highway sensor systems. (Radar Off-Highway Premium, Radar OHW, General Purpose Radar Off-Highway (GPR), Ultrasonic Sensor System OHW Entry & Premium)

off_highway_sensor_drivers's Issues

Let radar subscribe to odom

Thanks a lot for this repo!

One feature request though, the sender node of the ohw_radar currently subscribes to a geometry_msgs/msg/twist_stamped message to send ego velocity and yaw rate to the radar. Link here

Would it be possible to add an additional subscriber to odom (nav_msgs/msg/Odometry)?
A lot of ROS implementations have some kind of localization filter running and thereby have an odometry message which would be the perfect input.
Currently we have to write a small relay node that extracts the velocity part of our odom message and send this to your node as a twist_stamped message.

Binary releases to the ROS buildfarm

Thank you for creating these drivers!

Would it be possible to distribute them to the ROS buildfarm? Using bloom for the current active ROS2 distributions?

Issues with off_highway_sensor_drivers in ROS 2 Environment: Timeouts and Data Reception Problems

Hello Bosch Engineering Team,

I am currently integrating the off_highway_sensor_drivers package into our test vehicle, Route 2030 Project with Mercedes-Benz and encountering several issues related to data timeouts and message reception that I have been unable to resolve. Below is a detailed description of my setup, the issues I'm facing, and the steps I've taken to troubleshoot them.

Environment:
ROS 2 Version: Iron
Operating System: Ubuntu 22.04
Package Version: Humble - distro you provided

Even though I am not using ROS2 Humble, but Iron, I was able to compile all the packages from Bosch Radar Humble Repo successfully!

Setup:

I have configured the CAN interface with sudo ip link set can0 up type can bitrate 500000.

I am launching the socket_can_bridge using the provided launch file: ros2 launch ros2_socketcan socket_can_bridge.launch.xml.

I am also launching the off_highway_radar receiver node using: ros2 launch off_highway_radar receiver.launch.py.

Issues:

1. CAN Receive Timeout: The socket_can_receiver_node is consistently logging warnings about "CAN Receive Timeout" indicating it's not receiving CAN frames on the can0 interface within the expected timeframe.

[socket_can_receiver_node_exe-1] [WARN] [1708709876.343668176] [socket_can_receiver]: Error receiving CAN message: can0 - CAN Receive Timeout

2. Watchdog Timeout: The off_highway_radar_receiver node is logging warnings about watchdog timeouts, suggesting it's not receiving the expected data from the socket_can_receiver_node.

[receiver-1] [WARN] [1708709877.194928840] [off_highway_radar_receiver]: Timeout of watchdog for receiving node off_highway_radar_receiver

Troubleshooting Steps:

• I have verified that the CAN network is operational and other tools like candump are able to see the CAN frames on can0.

• I checked the QoS settings for all related topics and found them to be compatible (RELIABLE reliability and VOLATILE durability).

• I have reviewed the node and topic configurations to ensure there are no discrepancies in topic names or namespaces.

• I have increased the logging level of the nodes to debug but did not find any additional clues that point towards the root cause.

Additional Information:

The socket_can_sender and socket_can_receiver nodes are both reporting as active when checked with ros2 lifecycle get.

The issue seems to be isolated to the reception of messages by the socket_can_receiver_node and subsequently by the off_highway_radar_receiver node.

When I echo /objects_pcl I get everything there, except the PCD, which is what I need:

--
header:
  stamp:
    sec: 1708706432
    nanosec: 966239000
  frame_id: base_link
height: 1
width: 0
fields:
- name: x
  offset: 0
  datatype: 7
  count: 1
- name: y
  offset: 4
  datatype: 7
  count: 1
- name: z
  offset: 8
  datatype: 7
  count: 1
- name: v_x
  offset: 16
  datatype: 7
  count: 1
- name: v_y
  offset: 20
  datatype: 7
  count: 1
- name: time_since_meas
  offset: 24
  datatype: 7
  count: 1
- name: rcs
  offset: 28
  datatype: 7
  count: 1
- name: exist_probability
  offset: 32
  datatype: 7
  count: 1
- name: can_id_a
  offset: 36
  datatype: 6
  count: 1
- name: can_id_b
  offset: 40
  datatype: 6
  count: 1
- name: id_a
  offset: 44
  datatype: 2
  count: 1
- name: meas
  offset: 45
  datatype: 2
  count: 1
- name: valid
  offset: 46
  datatype: 2
  count: 1
- name: hist
  offset: 47
  datatype: 2
  count: 1
- name: id_b
  offset: 48
  datatype: 2
  count: 1
- name: zone
  offset: 49
  datatype: 2
  count: 1
- name: moving
  offset: 50
  datatype: 2
  count: 1
- name: near
  offset: 51
  datatype: 2
  count: 1
is_bigendian: false
point_step: 64
row_step: 0
data: []
is_dense: true
---

My rosgraph is below (Similar to documentation guide):

I checked that for ROS1-Noetic the socket_can_bridge package was implemented, but not for ROS2, then I used the Autoware.Auto socket_can pkg but not sure if it is compatible since I am experiencing these errors.

I would appreciate any guidance or suggestions you may have on resolving these issues. If there's any further information or logs I can provide, please let me know.

Thank you for your support.

Feature: composable nodes

It would be nice if multiple drivers can be launched in a composable node together with ros2_socketcan for example.

Only changes required are these: https://docs.ros.org/en/iron/Tutorials/Intermediate/Writing-a-Composable-Node.html

Would you be willing to implement this or accept a PR which does this?