0
$\begingroup$

Rosanswers logo

This is an example sensor message from my robot topic (/base_imu/data):

header: 
  seq: 286841
  stamp: 
    secs: 1634593671
    nsecs: 585787017
  frame_id: "base_imu_frame"
orientation: 
  x: 0.000403192
  y: 0.019378814
  z: -0.9942339840000001
  w: 0.105465872
orientation_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
angular_velocity: 
  x: 0.00122173
  y: -0.0002138
  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.05120641
  y: -0.39003008
  z: 9.7951648
linear_acceleration_covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

As shown above, the covariance matrices are blank and I want to fill this message with my own experimental values. The problem is that I'm currently setting these values by 1) subscribing the topic 2) set the values and publish because I cannot access to a ros driver of this robot and modify the code. However, I personally don't like this method (redundancy & message filtering) and want to try any better way to directly set those values. I appreciate if someone can give me some information regarding this.


Originally posted by kidpaul on ROS Answers with karma: 38 on 2021-10-18

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

The problem is that I'm currently setting these values by 1) subscribing the topic 2) set the values and publish because I cannot access to a ros driver of this robot and modify the code. However, I personally don't like this method (redundancy & message filtering) and want to try any better way to directly set those values.

well, as messages are exchanged peer-to-peer between nodes, unfortunately there isn't a "better way" afaik.

What did you have in mind yourself?

I can only think of one other way to approach this (if we exclude non-ROS-based approaches), and that would be injecting them (ie: your covariances) on the consumer side (ie: the node which subscribes to these messages). If that node is under your control (ie: you can change the source), you could change its subscriber callback to first pre-process the incoming messages.

If it's not under your control, I believe subscribe-process-publish is what you'll need to do,

Note that you don't need to write a "whole new node" for this. topic_tools/transform can do most of the work for you. You just need to provide the correct expression.


Originally posted by gvdhoorn with karma: 86574 on 2021-10-19

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Vic on 2021-10-19:
Regarding injecting things by simultaneous dependencies, you can always use the string ros message type and boost serialize to avoid changing your topics and just maintaining an object doing that

Comment by gvdhoorn on 2021-10-19:
I'm not sure I understand your suggestion.

The OP has a robot with a driver which publishes sensor_msgs/Imu messages without the covariance fields set to correct/expected values.

How can std_msgs/String (or string) help in that case?

Comment by Vic on 2021-10-19:
Using boost::serialization and creating a serializable matrix object, you can put it in/out of your string object using the <</>> operator. For creating a serializable matrix object : https://stackoverflow.com/questions/18382457/eigen-and-boostserialize

You set your matrix with correct/expected values. Serialize it, turn it in string. Send in your topic, get it on the other side (assuming you program both the nodes), unserialize it, get the right thing.

Comment by gvdhoorn on 2021-10-19:
Ok, so ignore the typed messaging system completely and (de)serialise (from) to a string (ie: plain memory) and exchange those buffers.

I would not recommend to do that in a typed system like ROS, but that's up to you of course.

Question remains: how would this help the OP with his problem? Where other ROS nodes must be able to consume the updated sensor_msgs/Imu messages? The problem doesn't seem to be receiving the messages, changing them or republishing them. The OP is asking whether there is any "better way".

assuming you program both the nodes

it doesn't seem like that's the case, as the OP writes:

I cannot access to a ros driver of this robot and modify the code.

Comment by Vic on 2021-10-19:
My bad, failed to correctly understand the problem, you're right

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.