Revision history [back]

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right?

Thanks, Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right?right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• A small note, in this wiki page, you mention the datum parameter with 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks, Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• A small note, in this wiki page, you mention the datum parameter with 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks, Thanks,

Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• The topic /odometry/global has frame_id = map and child_frame_id = base_link. Should not the second be equal to odom?
• A small note, in this wiki page, you mention the datum parameter with 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks,

Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• The topic /odometry/global has frame_id = map and child_frame_id = base_link. Should not the second be equal to odom?
• A small note, in this wiki page, you mention the datum datum parameter with has 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks,

Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• The topic /odometry/global from the second EKF has frame_id = map and child_frame_id = base_link. Should not the second be equal to odom?
• A small note, in this wiki page, you mention the datum parameter has 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks,

Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

So, the overview graph is now like that?

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• The topic /odometry/global from the second EKF has frame_id = map and child_frame_id = base_link. Should not the second be equal to odom?
• A small note, in this wiki page, you mention the datum parameter has 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks,

Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

So, the overview graph is now like that?

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• The topic /odometry/global from the second EKF has frame_id = map and child_frame_id = base_link. Should not the second be equal to odom?
• A small note, in this wiki page, you mention the datum parameter has 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks,

Guido

Ok, I set the input of navsat to the output of the second EKF, the situation is a little better, i.e. setting map_link as fixed in RVIZ, I can see odom-->base TF remaining consistent as before, since it comes from the first EKF, but map_link-->odom_link stays a bit closer to the real trajectory, even if after a bit it still diverges very much, even if it seems the raw GPS data are not so noisy.

So, the overview graph is now like that?

Some more questions about this setup:

• With your correction, the first warning about odom-->map transform disappeared, but the second one about map-->base is still there. I have GPS data produced at about 1Hz, do I have to change navsat frequency to a lower value?
• I also tried to set use_odometry_yaw="true" in navsat parameters, but from the node graph it still seems not using the IMU orientation for creating /odometry/navsat. Is this an intended behavior?
• If I have understood well, looping /odometry/global into navsat and keeping /odometry/local separate from it have the effect of the first one producing map-->odom and the second odom-->base independently, right? This concept is still a bit obscure to me after reading this and your dual_ekf ROS example... :(
• The topic /odometry/global from the second EKF has frame_id = map and child_frame_id = base_link. Should not the second be equal to odom?
• A small note, in this wiki page, you mention the datum parameter has 5 arguments, but it seems the latest version accepts only the first 3, frames are not necessary.

Thanks,

Guido