Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sensor_msgs::Imu message (de)serialize problem in ROS2 [5773]. #99

Closed
OpusK opened this issue Jun 28, 2019 · 14 comments

Comments

@OpusK
Copy link
Contributor

commented Jun 28, 2019

There is a problem with the sensor_msgs::Imu message.

I am sending a fixed value for testing as below.

  header.frame_id : aaaaaaaa
  orientation.x : 0.0212352352623
  orientation.y : 0.42342352
  orientation.z : 0.00623523423
  orientation.w : 0.00823521234

However, when I try to receive `ros2 topic echo ', I get an enormously large and small number as shown below.

---
header:
  stamp:
    sec: 0
    nanosec: 0
  frame_id: aaaaaaaa
orientation:
  x: -7.000529030818643e-290
  y: -5.183349370774724e+263
  z: -1.8669755390774087e+239
  w: 1.2403065777907416e+296
orientation_covariance: [5.263824555e-315, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
angular_velocity:
  x: 0.0
  y: 0.0
  z: 0.0
angular_velocity_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
linear_acceleration:
  x: 0.0
  y: 0.0
  z: 0.0
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---

And below is the packet of the Imu topic that I checked using the option -v 6.

[1561707091.394064] debug    | UDPServerLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0xAABBCCDD, len: 332, data: 
0000: 81 80 20 00 07 01 44 01 00 2A 00 15 00 00 00 00 00 00 00 00 09 00 00 00 61 61 61 61 61 61 61 61
0020: 00 69 74 65 72 3E 3C 74 C6 D4 E5 83 B0 BE 95 3F FF 75 B0 F6 5E 19 DB 3F C3 AB 9C F1 1D 8A 79 3F
0040: 75 46 68 7D 9F DD 80 3F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0140: 00 00 00 00 00 00 00 00 00 00 00 00
[1561707091.394344] debug    | UDPServerLinux.cpp | recv_message             | [==>> UDP <<==]        | client_key: 0xAABBCCDD, len: 13, data: 
0000: 81 00 00 00 0B 01 05 00 20 00 20 00 80
[1561707091.394660] debug    | DataWriter.cpp     | write                    | [** <<DDS>> **]        | client_key: 0x00000001, len: 320, data: 
0000: 00 00 00 00 00 00 00 00 09 00 00 00 61 61 61 61 61 61 61 61 00 69 74 65 72 3E 3C 74 C6 D4 E5 83
0020: B0 BE 95 3F FF 75 B0 F6 5E 19 DB 3F C3 AB 9C F1 1D 8A 79 3F 75 46 68 7D 9F DD 80 3F 00 00 00 00
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Using Hex values and floating conversion tools, you can see some facts.

61 61 61 61 61 61 61 61 00 69 74 65 72 3E 3C 74 C6 D4 E5 83 B0 BE 95 3F FF 75 B0 F6
  • The packet has normal data.
  • However, about 4 bytes were pushed, and 4 bytes of other data were fetched and converted.
  • And the alignment for 8 bytes is not done properly. (Data is entered after 8byte alignment, but the previous 4 bytes of garbage data appears to be recognized.)

61 61 61 61 61 61 61 61 00 is represented by the string "aaaaaaaa".
However, the following data, orientation.x (8 byte double type), is output as 72 3E 3C 74 C6 D4 E5 83 data, although C6 D4 E5 83 B0 BE 95 3F data should be used for output.
In other words, after the string, it seems that the problem occurs by processing data after 4 bytes rather than 8 bytes to read data after 8 byte alignment.

For note, I am using little endian.

@OpusK OpusK changed the title sensor_msgs::Imu message deserialize problem in ROS2. sensor_msgs::Imu message (de)serialize problem in ROS2. Jun 28, 2019

@julianbermudez julianbermudez changed the title sensor_msgs::Imu message (de)serialize problem in ROS2. sensor_msgs::Imu message (de)serialize problem in ROS2 [5773]. Jun 28, 2019

@julianbermudez julianbermudez self-assigned this Jun 28, 2019

@OpusK

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2019

Currently, this phenomenon occurs not only in Imu messages but also in 8-byte serialization after other bytes (1, 2, 4).

like below.

@OpusK

This comment has been minimized.

Copy link
Contributor Author

commented Jul 10, 2019

Hi, @julianbermudez

Is there anything that is going on regarding this issue?

@robotpilot

This comment has been minimized.

Copy link

commented Jul 16, 2019

Hi, @julianbermudez

We are using the Micro-XRCE-DDS Agent you have developed.
I think it is excellent for XRCE hardware like TurtleBot3 using ROS 2.
I just want to know if this issue is ongoing.

@julianbermudez

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2019

Hi @OpusK, @robotpilot,

This issue is in backlog due to lack of time, I hope to answer as soon as possible.

@mkhansen-intel

This comment has been minimized.

Copy link

commented Jul 22, 2019

Hi @julianbermudez, please let us know an ETA when you can. This is blocking testing of Navigation2 with the Turtlebot3.

@julianbermudez

This comment has been minimized.

Copy link
Contributor

commented Jul 24, 2019

Hi @mkhansen-intel,

I'm working on it. It seems that this issue could take more time than expected. I try to find a workaround fix in order to avoid Turtlebot3 blocking.

@oneattosecond

This comment has been minimized.

Copy link

commented Jul 25, 2019

I'm also seeing very large & very small data coming from IMU on TB3 + dashing, very much interested in any fix/workaround...

@corsaircpt

This comment has been minimized.

Copy link

commented Jul 25, 2019

Could this issue be impacting the delivery of /scan lidar topic to host ? I can get /scan-half but not the /scan with host running Dashing ROS2 and Turtlebot3 compiled for Dashing.

@OpusK

This comment has been minimized.

Copy link
Contributor Author

commented Jul 26, 2019

Hi, @corsaircpt

This is an issue not related to /scan.
TB3 does not use / scan_half from dashing.

Currently, the issue related to /Imu has not been solved, and the manual is not disclosed, so it is better to try after manual release.

@julianbermudez

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2019

Hi all,

I created the new branch hotfix/cdr_workaround. It should fix partially this issue, but be careful because the fragmentation is not working so, please use enough buffer size. I will work on this issue during this week in order to fix it properly.

@OpusK

This comment has been minimized.

Copy link
Contributor Author

commented Jul 29, 2019

@julianbermudez

Thanks for your support!
I did not check it as a whole, but I have confirmed that Imu messages, including Odometry, work well.

@oneattosecond

This comment has been minimized.

Copy link

commented Jul 29, 2019

@OpusK @julianbermudez can you share some instruction on how to use the branch?

I checked out the hot fix branch, rebuilt Micro-XRCE-DDS-Client (+examples + turtlebot3_lidar app) and my imu topic is spewing out crazy large values when TB3 is sitting idle. I tried rebooting and still get the same crazy values on remote host:

orientation:
x: -2.000000189611683
y: -2.6815622205660233e+154
z: -1.5874158496e-314
w: 1.4916684960196887e-154
...
linear_acceleration:
x: 4.0340208547423063e-281
y: 7.725631069523329e+204
z: -7.961148792007827e-123

@oneattosecond

This comment has been minimized.

Copy link

commented Jul 29, 2019

OK, had to add the workaround to Arduino / OpenCR firmware and re-flash OpenCR as well. With that, I am seeing what look like more normal IMU values coming out on remote PC:

orientation:
x: 0.007786510977894068
y: -0.002495411317795515
z: -0.07825466990470886
w: 0.9968955516815186
...
linear_acceleration:
x: 0.032920272825
y: 0.158615859975
z: 10.199299071599999

Will check other functionality upstream and hope it unblocks dashing use!

@OpusK

This comment has been minimized.

Copy link
Contributor Author

commented Jul 30, 2019

Hi, all.

I have made an OpenCR firmware update, and have made an e-manual update.
I did not completely check everything I had to check, but I did update after the simple test.
Please refer to the e-manual.

This is a temporary update, and since most developers are currently on vacation, it is likely that developers will be able to begin detailed checks next week.

@julianbermudez, thanks again for your support :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.