Kogut's profile - activity

I have an instance of robot_localization working very well with an IMU (without accels) , wheel odometry, and secondary gyro (as IMU).

I have a barometer, and have written a node to convert atmospheric pressure to meters relative to the first barometer sample. This sensor and conversion node have been tested and are relatively accurate (approx 2m variance).

But when I add this data to my filter, configuring it to use the "z" position field of a pose source, the filter completely almost instantly blows up, with the error largely in the "z" field of the state estimate. Even though my input data is only fluctuating between 0 and 2m at the stationary startup position, the state estimate can rocket hundreds of meters in the air.

I have verified that the correct covariance field for the 'z' position is being used, and have tried a variety of variance values, to no apparent effect. I have tried relative and differential, with similar behavior.

I am not doing the work to convert the barometer data into a true vehicle frame, e.g. it's always relative meters above ground regardless of the pitch/roll of the vehicle, not the true Z distance from the base_link origin. However given that my starting position is basically level, I don't think this is the source of my problem.

Are there any ideas from people who've tried integrating a standalone altitude sensor measurement?

Done. also significantly edited the question to reflect my further isolation of the issue. It has nothing to do with the Odometry message (other than its size), but kept use of Odometry in my code for its ease of use vs. the custom message I used to identify the precise size.

Publishing a message of size 519 bytes at 100Hz results in this output for 'rostopic hz':

average rate: 99.997 min: 0.010s max: 0.010s std dev: 0.00006s window: 996

Increasing the message size by one byte to 520 bytes results in this output for 'rostopic hz':

average rate: 99.985 min: 0.000s max: 0.044s std dev: 0.01651s window: 4908

This is a custom message defined as an array of int8. But the behavior is independent of message type. Any message of size >519bytes exhibits the same effect. The behavior is also independent of Python/C++ and queue size. The effect is dependent on publish rate, but starts to appear around a rate of 35Hz.

The much larger std. dev. is caused by a seeming buffer effect whereby the larger messages come in groups of 3-5 messages vs. the much more consistently timed publishing rate of the smaller message.

Is this a known behavior? It is surprising to me because 520 bytes isn't a terribly large message size. The nav_msgs::Odometry message is larger.

While I used a custom message to narrow down the precise behavior above, this code that simply uses the Odometry message (>519 bytes) will replicate the issue:

#!/usr/bin/env python

import rospy
from nav_msgs.msg import Odometry


def odomer():
    pub=rospy.Publisher('odomer',Odometry,queue_size=100)
    rospy.init_node('odomer',anonymous=True)
    rate=rospy.Rate(40)
    while not rospy.is_shutdown():
        odom_msg = Odometry()
        pub.publish(odom_msg)
        rate.sleep()


if __name__ == '__main__':
    try:
        odomer()
    except rospy.ROSInterruptException:
        pass

I have a similar problem. Usually point clouds are not published. If I keep re-starting I can sometimes get point clouds rendered for a glorious 4-5 seconds before they stop publishing. My intuition tells me there's a race condition/deadlock somewhere, but I have no idea where to start looking because there are no useful error messages.

I will try 64-bit Ubuntu, but that's annoying.