Problem: none message is published

[likun1993630]

Hi,I would like to use this ROS package to communicate the IBEO Fusion-ECU. But I encounter some problems.

Briefly, Node does not output anything.

The ECU is connected with four IBEO lux 4l sensors. The ECU's IP is default, 192.168.1.100, and the port number is 12002.

A Ubuntu-PC was connected to Fusion ECU directly.

Thanks very much ！

Here are my steps for installation and startup:

install driver package

# Create a new workspace
mkdir -p ~/ifF/src
cd ~/ifF
catkin_make
echo "source ~/ifF/devel/setup.zsh" >> ~/.zshrc

#install the ibeo lux package and dependencies
cd ~/ifF/src
git clone https://github.com/astuff/network_interface
git clone https://github.com/astuff/ibeo_core
git clone https://github.com/astuff/ibeo_lux
rosdep install --from-paths src --ignore-src --rosdistro=kinetic -y

# Build 
cd ~/ifF
catkin_make
# Build was successful

modify the ibeo_lux.launch file

<?xml version="1.0"?>
<launch>
  <arg name="lux_frame_id" default="ibeo_lux"/>
  <arg name="is_fusion" default="true"/>  
    <!--use data from FusionECU -->
  <arg name="name" default="ibeo_lux"/>
  <arg name="ip_address" default="192.168.0.100"/> 
    <!-- default IP address of FusionECU -->
  <arg name="port" default="12002"/>
    <!-- default port of FusionECU -->

  <node pkg="ibeo_lux" type="ibeo_lux" name="$(arg name)" output="screen">
      <!-- start ibeo_lux node with output in shell  -->
    <param name="ip_address" value="$(arg ip_address)"/>
    <param name="port" type="int" value="$(arg port)"/>
    <param name="sensor_frame_id" value="$(arg lux_frame_id)"/>           
    <param name="is_fusion" type="bool" value="$(arg is_fusion)"/>           
  </node>
</launch>

Setting of Ubuntu PC

IP: 192.168.0.10

mask: 255.255.255.0

Gateway: 0.0.0.0 (or nothing)

Then the Ubuntu PC was connected to FusionECU with Ethernet cable.

View network status with ifconfig

 ➜  ~ ifconfig
enp2s0    Link encap:Ethernet  HWaddr dc:0e:a1:f1:7d:04  
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::2f91:8a4b:4091:624b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:103 errors:0 dropped:4 overruns:0 frame:0
          TX packets:93 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12498 (12.4 KB)  TX bytes:11182 (11.1 KB)
          Interrupt:16 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:529 errors:0 dropped:0 overruns:0 frame:0
          TX packets:529 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:36189 (36.1 KB)  TX bytes:36189 (36.1 KB)

wlp3s0    Link encap:Ethernet  HWaddr 9c:4e:36:14:6a:b4  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:89 errors:0 dropped:0 overruns:0 frame:0
          TX packets:60 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:10004 (10.0 KB)  TX bytes:8995 (8.9 KB)

Test connection with ping

$ ping 192.168.0.100

PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_seq=1 ttl=128 time=0.396 ms
64 bytes from 192.168.0.100: icmp_seq=2 ttl=128 time=0.311 ms
64 bytes from 192.168.0.100: icmp_seq=3 ttl=128 time=0.326 ms
......

Start ibeo_lux Node

roslaunch ibeo_lux ibeo_lux.launch 

# Output from shell

... logging to /home/likun/.ros/log/9697c4ee-c3e2-11e9-8db0-9c4e36146ab4/roslaunch-lkubuntu-4219.log
Checking log directory for disk usage. This may take awhile.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://lkubuntu:32825/

SUMMARY
========

PARAMETERS
 * /ibeo_lux/ip_address: 192.168.0.100
 * /ibeo_lux/is_fusion: True
 * /ibeo_lux/port: 12002
 * /ibeo_lux/sensor_frame_id: ibeo_lux
 * /rosdistro: kinetic
 * /rosversion: 1.12.14

NODES
  /
    ibeo_lux (ibeo_lux/ibeo_lux)

auto-starting new master
process[master]: started with pid [4229]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 9697c4ee-c3e2-11e9-8db0-9c4e36146ab4
process[rosout-1]: started with pid [4242]
started core service [/rosout]
process[ibeo_lux-2]: started with pid [4251]

[ INFO] [1566300666.732111201]: Ibeo LUX - Got ip_address: 192.168.0.100
[ INFO] [1566300666.732706757]: Ibeo LUX - Got port: 12002
[ INFO] [1566300666.733249529]: Ibeo LUX - Is Fusion ECU: true
[ INFO] [1566300666.733821287]: Ibeo LUX - Got sensor frame ID: ibeo_lux
[ INFO] [1566300667.743934460]: Ibeo LUX - Sending Fusion filter command to begin transmission

##  Ibeo_LUX node was not running any further.
##  This may explain the problem.
##  I think the Ubuntu PC has not received any feedback from Fusion ECU.

➜  ~ rostopic list -v 

Published topics:
 * /parsed_tx/object_data_2225 [ibeo_msgs/ObjectData2225] 1 publisher
 * /parsed_tx/camera_image [ibeo_msgs/CameraImage] 1 publisher
 * /parsed_tx/object_data_2280 [ibeo_msgs/ObjectData2280] 1 publisher
 * /as_tx/point_cloud [sensor_msgs/PointCloud2] 1 publisher
 * /as_tx/object_contour_points [visualization_msgs/Marker] 1 publisher
 * /rosout [rosgraph_msgs/Log] 1 publisher
 * /rosout_agg [rosgraph_msgs/Log] 1 publisher
 * /parsed_tx/host_vehicle_state_2806 [ibeo_msgs/HostVehicleState2806] 1 publisher
 * /parsed_tx/host_vehicle_state_2807 [ibeo_msgs/HostVehicleState2807] 1 publisher
 * /as_tx/objects [visualization_msgs/MarkerArray] 1 publisher
 * /parsed_tx/scan_data_2204 [ibeo_msgs/ScanData2204] 1 publisher
 * /parsed_tx/scan_data_2205 [ibeo_msgs/ScanData2205] 1 publisher
 * /tcp_tx [network_interface/TCPFrame] 1 publisher

Subscribed topics:
 * /rosout [rosgraph_msgs/Log] 1 subscriber

There were also no messages sent from Node, eg:

[JWhitleyWork]

@likun1993630 - Please echo the topic /tcp_tx and see if there are any data. If there are no data on /tcp_tx, then the network interface is not working correctly. If there are data on /tcp_tx, then continue.

Next, echo the topic /parsed_tx/scan_data_2204 and /parsed_tx/scan_data_2205. One of these topics should be producing data, depending on the version of the software on your Fusion ECU. If neither of these are producing data, then there is something wrong with the driver parsing the raw TCP data from the Fusion ECU. If one of these has data, then there is something wrong with the driver producing the point cloud.

Thank you for the detailed bug report!

[likun1993630]

@JWhitleyAStuff - Thank you very much for your quick reply, I will try out your suggestions.

[likun1993630]

@JWhitleyAStuff Hi, I have tested this package again, and the final conclusion is that network_interface is not working.

The first is that the /tcp_tx topic has not been published.

Then I did some other tests on the code and found that the msg_buf container is empty. I guess the possible reason is that the fusion ECU did not receive the correct command to send the sensor data, or sent the command correctly, but the ECU did not make response.

So I used software(Wireshark) to detect the entire process of TCP communication and found the problem:

The read() function can not read data from socket buffer in kernel space to msg_buf, so msg_buf is empty. https://github.com/astuff/ibeo_lux/blob/966ecbf2d41db37c39604fcfa1a4d8b1e3631ec1/src/ros_ibeo_lux.cpp#L189 https://github.com/astuff/network_interface/blob/48d0111c3024ce9206846e361773c65db4a38f1b/src/tcp_interface.cpp#L70-L87

Here are some information from wireshark:

The endpoint of ubuntu-PC is: IP 192.168.0.10 , port 46638

The above lines 1-3 indicate that the connection between ubuntuPC and ECU has been correctly established;

The fourth line is the command that ubuntu-PC sends to the ECU:

{0xaf, 0xfe, 0xc0, 0xc2,
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x08,
0x00, 0x00, 0x20, 0x10,
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0x00, 0x05, 0x00, 0x02,
0x00, 0x00, 0xff, 0xff}

Starting from the tenth line, the ECU began sending a large amount of data to the ubuntu-PC.

It can be seen from the above that since the contents of the socket buffer cannot be read by C++ code, they are gradually filled up until the error messages of Window Full and ZeroWindow appear.

I guess the cause of this problem is the msg_buf initialization problem.

I suspected that this might be caused by the initialization of buf_msg, so I tried to initialize buf_msg as a large enough container before writing the contents of the socket buffer to buf_msg, instead of just requesting to reserve some continuous memory space.

https://github.com/astuff/ibeo_lux/blob/966ecbf2d41db37c39604fcfa1a4d8b1e3631ec1/src/ros_ibeo_lux.cpp#L186 Change the above code to:

std::vector<uint8_t> msg_buf(10000000,0); //10Mb buffer

After the change, the /tcp tx topic can already publish the message. In addition, only the following two topics have appeared:

/as_tx/objects 
/as_tx/object_contour_points

There was no data on all other topics.

Other topics have not been published, I guess it is caused by the ecu firmware update.

I am looking forward to knowing if you have any thoughts on this issue or have any suggestions for dealing with this issue.

In addition, our ECU has been upgraded to 2019-R1_v8.0.0. In this new firmware, new data such as 2209 is sent. I wonder if you intend to adapt this package to the latest firmware.

Thanks very much!

[bensort]

I have also encounter this problem , There were also no messages sent from Node.

[likun1993630]

@JWhitleyAStuff @bensort I have solved the problem I have encountered. In other words, this package can already publish the required topics.

Background:

The firmware version of my fusion ECU is 2019-R1_v8.0.0. In this version, if a command to request all sensor data is sent to the Fusion ECU, the raw tcp messages that the Ubuntu PC can receive are(checked with wireshark): 0x9001 0x6701 0x2807 0x2209 0x2280

After I modified the source code, the following topics were published:

As_tx/object_contour_points
As_tx/objects
As_tx/point_cloud
Parsed_tx/host_vehicle_state_2807
Parsed_tx/object_data_2280
Parsed_tx/scan_data_2209
Tcp_tx

I have made the following changes:

Firstly:

https://github.com/astuff/network_interface/blob/48d0111c3024ce9206846e361773c65db4a38f1b/src/tcp_interface.cpp#L77 Change the above line to:

msg->resize(socket_.available(),0);

/* I have read the doc of the boost.asio library. 
I personally think that the vector container needs to be properly initialized first, that is, allocate memory.
Then it can be passed to the buffer function.*/
/* Since the raw tcp data needs to be combined,so I use the function that returns the size of the available data in socket buffer.
(The scan data is very large. The read() function may take several times to read data from the socket buffer to form a complete scan data.Only the complete scan data can be parsed correctly).*/

If your firmware version is the same as mine (latest version). After this change, there will be the following topics that can be published: Tcp_tx As_tx/object_contour_points As_tx/objects

Secondly:

Change the keyword 2205 of the source code in all following packages to 2209, including the msg file content, msg file name and CmakeLists:

astuff_sensor_msgs/ibeo_msgs/
ibeo_core/
ibeo_lux/

Change the parse function of class ScanData2209:

https://github.com/astuff/ibeo_core/blob/94ce302437435b3175eb09a958ab2172cb875bf7/src/ibeo_core.cpp#L800-L833

scan_points = read_be<uint32_t>(in, hdr + 18);
number_of_scanner_infos = read_be<uint8_t>(in, hdr + 22);
new_scanner_info.parse(in, hdr + 26 + (i * 148));
new_scan_point.parse(in, hdr + 26 + (number_of_scanner_infos * 148) + (i * 28));

After this change, As_tx/point_cloud will be published.

Thirdly

https://github.com/astuff/ibeo_lux/blob/966ecbf2d41db37c39604fcfa1a4d8b1e3631ec1/include/ibeo_lux/ibeo_lux_ros_msg_handler.h#L27 https://github.com/astuff/ibeo_lux/blob/966ecbf2d41db37c39604fcfa1a4d8b1e3631ec1/src/ibeo_lux_ros_msg_handler.cpp#L18

Change codes to: (uint8_t to uint16_t):

void fillAndPublish(const uint16_t& type_id,
                      const std::string& frame_id,
                      const ros::Publisher& pub,
                      IbeoTxMessage * parser_class);
void IbeoLuxRosMsgHandler::fillAndPublish(
    const uint16_t& type_id,
    const std::string& frame_id,
    const ros::Publisher& pub,
    IbeoTxMessage * parser_class)

the reason for it, see code:

https://github.com/astuff/ibeo_core/blob/94ce302437435b3175eb09a958ab2172cb875bf7/include/ibeo_core/ibeo_core.h#L590

After this change, there will be the following topics that can be published: Parsed_tx/host_vehicle_state_2807 Parsed_tx/object_data_2280 Parsed_tx/scan_data_2209

(微信likun1993630)

[JWhitleyWork]

@likun1993630 Thank you for all of your work on this issue! Can you please test your modifications to ibeo_core and ibeo_lux using the version of network_interface here: https://github.com/astuff/network_interface/pull/26 ?

[bensort]

I tried it, the problem that node did not post the message has been solved. thanks：）

[JWhitleyWork]

@likun1993630 Now that the issue with network_interface has been solved, we will test internally and create a new release. Could you possibly create a new Pull Request on this repo to add the additional messages you mention above? However, instead of modifying an existing message, please have the driver publish this as a new message/topic. We still have users with older versions of the Fusion software which will publish the other messages and we do not want to remove them from the package. I would really appreciate it!

[likun1993630]

@JWhitleyAStuff I will finish it this weekend.

[JWhitleyWork]

@likun1993630 - astuff/network_interface#26 is merged. I will release a new version to the ROS Build Farm as soon as we have done testing internally.