Ask Your Question
0

Pose message lost decimal

asked 2021-01-13 03:04:51 -0600

MCmobil gravatar image

updated 2021-01-13 03:11:04 -0600

Good morning!

I am dealing with gps data that I convert and published into a geometry_msgs::PoseWithCovarianceStamped.

Thus I am supposed to publish "large" values (x~330 000, y~420 000), but I could see that I loose completely the decimals values on the code.

When I do "rostopic echo" I have this:

header: 
  seq: 29
  stamp: 
    secs: 1590407673
    nsecs: 738122463
  frame_id: "/map"
pose: 
  pose: 
    position: 
      x: 330288.65625
      y: 4156626.75
      z: 43.8396682739
    orientation: 
      x: -0.0146753482234
      y: 0.000946441286636
      z: 0.990484373245
      w: 0.136837293016
  covariance: [0.6361376939995259, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.6361376939995259, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.6361376939995259, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.6361376939995259]

But by displaying via the code (std::cout) I got this:

pose 330287 4.15663e+06

NB:Using also the initial pose tool on RVIZ gives me the same behavior.

Is there a reason, I must miss, that explains why I find this behavior? If yes is there any way to get the decimals (avoiding to shift everything to get closer to 0) ?

PS: Therefore I found that using a printf with the %lf gives me the decimals... And using static_cast<double> does not solve the problem.

edit retag flag offensive close merge delete

Comments

1

This is likely not a problem with lost decimals, but with how you've configured std::cout.

By default it prints only a limited number of significant digits.

But that doesn't mean they are lost. They just aren't displayed.

Thus I am supposed to publish "large" values (x~330 000, y~420 000)

note though: double precision floating point numbers do support only approx 15 significant digits, so with the large numbers you mention, you're already using about half of that.

See also #q286682.

Finally: as everything in ROS is in metres, the values you quote would be 330 Km and 420 Km respectively. As a PoseStamped is relative to some origin, REP-105 mentions some considerations when dealing with very large distances. See the Transitions between maps section.

gvdhoorn gravatar image gvdhoorn  ( 2021-01-13 03:07:16 -0600 )edit

See #q248060 for what I believe is almost a duplicate of your question.

gvdhoorn gravatar image gvdhoorn  ( 2021-01-13 03:08:30 -0600 )edit

Ok I see... I might have been confused about that only half of numbers have been displayed and what's left after the comma not considered, whereas it is that part I was considering for my application. I will post an answer in order to close this request.

MCmobil gravatar image MCmobil  ( 2021-01-13 20:15:51 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2021-01-13 20:27:30 -0600

MCmobil gravatar image

As @gvdhoorn explained in commentaries, there is no loss of information, but effectively std::cout must be tuned for displaying decimals.

It is possible by the following lines:

std::cout << std::fixed;
std::cout << std::setprecision(7); //display 7 first decimals
std::cout << "pose " << input->pose.pose.position.x << std::endl;

Anyway using big values are not a good solution overall if you are using other libraries that do not accept "double" precision.

The best I could do for now is shift the coordinates to the first position received and put it as the origin. This workaround must be changed (explained in the commentaries) if the robot is moving over huge distance.

NB: the original problem was due to a third party library that did not have enough precision to show a position difference between two different position because it could deal only with floating numbers, and this error has been spreaded into the message!

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2021-01-13 03:04:51 -0600

Seen: 20 times

Last updated: Jan 13