robot_localization high cpu usage and no output #329
Comments
|
Do you have a question for this on ROS answers? If so, can you direct me to it? I've been neglecting it lately, sorry. In any case, this typically points to an issue with one of your covariance matrices. If the filter's estimate error covariance becomes singular (via bad measurement covariances or bad covariance parameters), I find the filter slows to a crawl and stops producing data. Can you post a sample IMU message and your configuration? |
|
Thanks for your fast response! The ROS Answers question is here:
http://answers.ros.org/question/250086/robot_localization-high-cpu-and-no-output/
I will get you a sample of the input data later today. The covariance is
static for both the IMU pose and twist, measured by analyzing noise from
data samples. Since only orientation is available pose covariance is for θ,
φ, ψ, and twist covariance is for dθ, dφ, dψ. All other points in the
covariance matrix diagonal are 0, such that for the pose, only the fourth,
fifth, and sixth elements on the diagonal are occupied and for twist the
tenth, eleventh, and twelfth on the diagonal are occupied. All other values
in the matrix are zero.
In the launchfile, pose is set to
[false, false, false,
true, true, true,
false, false, false,
false, false, false,
false, false, false]
and twist is set to
[false, false, false,
false, false, false,
false, false, false,
true, true, true,
false, false, false]
I discovered last night that if I set the frequency of robot_localization
to any value <= 2.5 Hz, it will work for a long time. Any value higher and
it can never get more than 11 messages before ceasing to output. It seems
this is the threshold where the CPU runs at 98% or more. Before that, the
CPU never uses more than 6%.
…On Thu, Dec 15, 2016, 12:30 AM Tom Moore ***@***.***> wrote:
Do you have a question for this on ROS answers? If so, can you direct me
to it? I've been neglecting it lately, sorry. In any case, this typically
points to an issue with one of your covariance matrices. If the filter's
estimate error covariance becomes singular (via bad measurement covariances
or bad covariance parameters), I find the filter slows to a crawl and stops
producing data. Can you post a sample IMU message and your configuration?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#329 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIZ80VjdKGeNMGVhPpB2l3EjdU6c5XKKks5rIPqMgaJpZM4LNvSg>
.
|
|
Can you just paste your entire config file for r_l along with the sample IMU messages when you get them? Thanks. |
|
Here is my launch file: Here are a few IMU pose messages: Here are a few IMU twist messages: Here are a few rtabmap odom messages: Here is the entire output of r_l before it stops publishing: |
|
We found the problem. It had nothing to do with r_l. We were inadvertently publishing bad data on our twist topic. The odom output of r_l was accidentally being routed into the twist message... ROS took the odom data type and evidently interpreted it as a twist message. Yes, our covariance matrix is technically singular, but I believe that's okay due to the values in the boolean matrix. In any case, it now works, and it's totally not a problem with r_l. |
|
Cool. One thing you should fix, though, is that your IMU twist data has a |
|
Two other things:
Can you please update your ROS answers question? |
|
ROS Answers is closed and links back here. Thanks for noticing those. We caught the frame issue and switched it to base_link and it works much better now. We are noticing the jitter, but rtabmap is jittery anyway. The orientation ends up looking very stable, but due to the lack of translational data from the IMU, position jitters a lot. This is probably partially due to the transform closely linking the IMU to the map. Thanks so much for your help! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have an IMU (orientation only) and rtabmap connected to robot_localization ukf. When I include the pose from the IMU and the odom from rtabmap, robot_localization works fine and uses 1-2% CPU. However, when I add the twist messages from the IMU, robot_localization only produces about 10 messages before ceasing to have any output. When I watch it in htop, it uses 100-105% CPU. I assume that whatever it's doing is blocking indicated by no messages being published and ctrl-c failing to work. I examined the twist data going into robot_localization from the IMU and they look fine. They're coming in at about 375 Hz like the pose messages. rtabmap is coming in at about 10Hz with its odom message. Transforms have been applied, but I'm not sure if they are correct in the way they relate the rtabmap reference frame with the IMU frame. Any idea why this would be happening?
The text was updated successfully, but these errors were encountered: