I'm trying to estimate the position of a robot using the robot_localization ROS package. Currently I use a UM7 Orientation Sensor wich has their own ROS package (um7_driver) and a Adafruit Ultimate GPS Breakout version 3.
To read the GPS data I use the nmea_serial_driver. I read a lot of answers in this page and documents as REP-103 and REP-105, but I'm still not able to configure correctly the nodes and topics to obtain an output in /odometry/filtered or /odometry/gps topics.
I'm usign the navsat_transform_node to convert the GPS raw data (fix) to a odometry/gps message. This odometry/gps message is an input for the ekf_localization_node. In addition the odometry message (output) of the ekf_localization_node is an input for the navsat_transform_node in a circular path as were described in: [How to fuse IMU & GPS using robot_localization](http://answers.ros.org/question/200071/how-to-fuse-imu-gps-using-robot_localization/#200087)
I think that my IMU configuration is ENU compliant. My launchers files are described below with samples of gps/fix and imu/data messages, unfortunately I can't upload an imageof my rqt_graph. Any comments and suggestions will be appreciated!!!
IMU Message Sample:
---
header:
seq: 352
stamp:
secs: 1491248090
nsecs: 477437036
frame_id: imu
orientation:
x: 0.0580077504
y: 0.0024169896
z: 0.9721333587
w: -0.2270291759
orientation_covariance: [0.002741552146694444, 0.0, 0.0, 0.0, 0.002741552146694444, 0.0, 0.0, 0.0, 0.007615422629706791]
angular_velocity:
x: 8.9495899038e-05
y: -0.000212560517745
z: 0.000418925544915
angular_velocity_covariance: [1.0966208586777776e-06, 0.0, 0.0, 0.0, 1.0966208586777776e-06, 0.0, 0.0, 0.0, 1.0966208586777776e-06]
linear_acceleration:
x: -4.19586237482
y: 1.07622469897
z: 8.44690478507
linear_acceleration_covariance: [0.0015387262937311438, 0.0, 0.0, 0.0, 0.0015387262937311438, 0.0, 0.0, 0.0, 0.0015387262937311438]
---
GPS Message Sample:
---
header:
seq: 54
stamp:
secs: 1491248749
nsecs: 594259977
frame_id: /gps
status:
status: 0
service: 1
latitude: -33.0408566667
longitude: -71.6299133333
altitude: 132.4
position_covariance: [3.9204, 0.0, 0.0, 0.0, 3.9204, 0.0, 0.0, 0.0, 15.6816]
position_covariance_type: 1
---
↧
Integrate UM7 IMU and Adafruit GPS with robot_localization
↧
Using the Localization Package using only the GPS and IMU (no output odometry/filtered message being echoed)
Hi Everyone, I am currently working on the Localization package in order to get position and velocity data for my robot using only a GPS and IMU. Right now when I try to run the program, my odometry/filtered topic does not output any data. I assume it is because it is not inputting any data for the odometry topic. The following is our launch / parameters files and a sample output of our GPS and IMU data.
*My questions are:*
1. How do I map / configure my data to give me an accurate odometry output? Is there anything more inputs I need to add?
2. How do I get a velocity output using the localization package?
I am fairly new to ROS so any feedback would be helpful, thank you.
**current rqt_graph**
http://imgur.com/a/b2Wdm
**Hardware**
GPS: Sparkfun
IMU: Razor 9dof
**GPS Output Data:**
header:
seq: 37
stamp:
secs: 1491283112
secs: 297769069
frame_id: /gps
status:
status: 0
service: 1
latitude: 21.382495
longitude: -157.92706
altitude: 69.0
position_covariance: [1.44, 0.0, 0.0, 0.0, 1.44, 0.0, 0.0, 0.0, 5.76]
position_covariance_type: 1
**IMU output data:**
header:
seq: 2108
stamp:
secs: 1491283316
nsecs: 151560068
frame_id: base_imu_link
orientation:
x: 0.0896993330926
y: 0.023179361013
z: 0.266404467092
w: 0.959398460901
orientation_covariance: [0.0025, 0.0, 0.0, 0.0, 0.0025, 0.0, 0.0, 0.0, 0.0025]
angular_velocity:
x: 15.9
y: -0.61
z: -4.1
angular_velocity_covariance: [0.02, 0.0, 0.0, 0.0, 0.02, 0.0, 0.0, 0.0, 0.02]
linear_acceleration:
x: -0.037921640625
y: 1.83019796875
z: 9.490369375
linear_acceleration_covariance: [0.04, 0.0, 0.0, 0.0, 0.04, 0.0, 0.0, 0.0, 0.04]
**Launch File:**
↧
↧
about xmlrpcpp/XmlRpcException.h
when I catkin_make the robot_localization package it says:
fatal error: xmlrpcpp/XmlRpcException.h: No such file or directory
#include
how to solve it?
↧
Basic robot_localization example
I am attempting to get the most basic example of robot_localization working on a raspberry pi. I am new to linux and the ROS ecosystem, so I have fought through an exceptional number of issues to get it working. The information necessary to do this seems to be somewhat fragmented or over complicated for a beginner.
In order to do the localization I am using the BNO055 IMU by bosch that outputs orientation as well as standard IMU data. I am also using two incremental encoders on the wheels of lets say a "cart." This example is as simple as it can get, There are no motors and I just want to know the position of a cart that is pushed externally.
I have the system working, and it looks like filtered odom data seems to be more accurate, but I am having trouble making sure I did everything right.
The most basic question... is this the proper way to use ekf node?
In the very simpliest terms do these three codes seem correct? I have simplified them into the important components
The IMU uses:
#create publisher
imu_pub = rospy.Publisher('imu/data', Imu, queue_size=1)
#init node and set rate
rospy.init_node('imu_talker', anonymous=True)
rate = rospy.Rate(10) # 10hz
while not rospy.is_shutdown():
#PLACEHOLDER TO GET DATA FROM IMU
#create message and header
imu = Imu()
imu.header.stamp = rospy.Time.now()
imu.header.frame_id = 'imu'
#put data into the message
imu.orientation = quaternion
imu.angular_velocity = ang_vel
imu.linear_acceleration = lin_acc
#publish message
imu_pub.publish(imu)
#sleep at known rate
rate.sleep()
The ODOM uses:
#create publishers
odom_pub = rospy.Publisher("odom", Odometry, queue_size=1)
odom_broadcaster = tf.TransformBroadcaster()
#init node and rate
rospy.init_node('odom_talker', anonymous=True)
rate = rospy.Rate(10) # 10hz
while not rospy.is_shutdown():
#PLACEHOLDER TO GET ODOMETRY FROM ENCODERS
#create message and header
odom = Odometry()
odom.header.stamp = rospy.Time.now()
odom.header.frame_id = "odom"
#convert euler to quaternion
odom_quat = tf.transformations.quaternion_from_euler(0, 0, th)
#broadcast transform
odom_broadcaster.sendTransform((x, y, 0.), odom_quat,current_time,"base_link", "odom")
# set the position
odom.pose.pose = Pose(Point(x, y, 0.), Quaternion(*odom_quat))
# set the velocity
odom.child_frame_id = "base_link"
odom.twist.twist = Twist(Vector3(vx, vy, 0), Vector3(0, 0, vth))
# publish the message
odom_pub.publish(odom)
#sleep at known rate
rate.sleep()
The EKF launch file uses:
[true, true, false,
false, false, true,
true, true, false,
false, false, true,
false, false, false] [false, false, false,
true, true, true,
false, false, false,
true, true, true,
true, true, true] [LARGE ARRAY with small values] [LARGE ARRAY with 1e-9]
↧
GPS waypoint navigation with Jackal
I have a the UGV "Jackal" from Clearpath Robotics. My Task is to let the robot follow a predetermined path (given in UTM -Coordinates). The robot has already GPS, IMU and odometry implemented. The `robot_localization` package is also already installed and preconfigured.
To let the robot navigate autonomously, I would like to use the `move_base` package. Therefore the goals (`move_base/goal` or `move_base_simple/goal`) have to be "in the robots world frame, or a frame that can be transormed to the world frame" (see Answer for this [question](http://answers.ros.org/question/251347/gps-waypoint-navigation-with-robot_localization-and-navsat_transform_node/)).
The `robot_localization` package should provide a transform from **world_frame->utm**. But when I start the robot outside, I cant't see this transformation in the `tf` node. Because of that I can't send goals to the `move_base` node with `frame_id` **utm** I think.
My Questions are now:
1. Where can I check that the `navsat_transform_node` provides the **world_frame -> utm** transformation?
2. How should I configure the `move_base` node that he will accepts goals in the utm-frame? (I know this is a very open question, but I am very glad for every tip.)
Thank you for your help and support.
↧
↧
robot_localization producing 180° rotation jumps only when static publishing map->odom
I have configured `world_frame=odom`. When I statically publish TF map->odom my output of ekf_localization_node is jumping a lot. I've looked all over for the problem but I am stuck!
Here's an 8 second streamable video of the problem seen in rviz:
https://drive.google.com/file/d/0B6qINUvvDwDfMzdWUG1CWWNlMm8/view?usp=sharing
When I comment out...
[false, false, false,
true, true, true,
false, false, false,
false, false, false,
false, false, false] [true, true, false,
false, false, false,
false, false, false,
false, false, true,
false, false, false]
Date: Mon Mar 27 19:45:55 2017 +0100
Merge pull request #355 from clearpathrobotics/fix_gains_defaults
Fix acceleration and deceleration gains default logic
I appreciate any help! Thanks!
↧
navsat_transform_node bad data
I've been trying to fuse gps data with a odometry and an imu for a few days now and for some reason cannot get the navsat_transform_node to work. I plot the odometry/gps topic right next to the raw converted gps data from the receiver and the odometry/gps will randomly start slowly shooting off to hundreds of meters while the raw data stays in a nice small area.
Am I doing anything obviously wrong? I just can't seem to figure it out.
My launch file is here:
[false,false,false,
false,false,false,
true,false,false,
false,false,true,
false,false,false] [false,false,false,
false,false,true,
false,false,false,
false,false,true,
false,false,false]
↧
ros_localization - drift in z when fusing pitch from imu sensor
Hello,
I am currently using ros_localization to fuse imu and wheel odometry in the *odom* frame.
2. Imu0 is obtained from a pixhawk, using the package *mavros*, which outputs the topic */mavros/imu/data*, which has the message type: sensor_msgs/Imu, and provides roll,pitch,yaw, roll vel, pitch vel, yaw vel, x accel, y accel, z accel. I've checked this data in rviz and have confirmed that it is already in the ENU coordinate frame which ROS uses.
1. odom0 is wheel odometry coming from topic */quadOdom* and has the message type: nav_msgs/Odometry. This is a 2D position estimation in odom frame which provides x,y and yaw. The odometry is started at the same heading as the imu so that they are in-line with each other.
When I integrate x,y,yaw from odom0 and yaw from the imu, the EKF filter works fine and the filtered state estimate *odometry/filtered* looks reasonable (although it is only 2D). However when include pitch and roll from the imu, the z value of the *odometry/filtered* drifts by a huge amount, although the x,y and yaw values of the filtered path remain fine. How can i fix this so that when I include pitch and roll from the imu sensor the z value of *odometry/filtered* follows a more sensible path. My launch file is:
↧
Is it possible to use robot_localization for multiple robots?
Hello all,
I'm working on a small, multi-robot simulation using Husky robots. I've been using the base [husky_simulator](http://wiki.ros.org/husky_simulator) with some modifications to allow for multiple robots. The way I've accomplished this is through the use of namespaces. I call each "spawn_husky.launch" file in a separate namespace, which sets up all the plugins and publishes unique topics for each robot.
Everything seems to be working fine except for the the topics husky1/odometry/filtered and husky2/odometry/filtered. So I dug through the launch files and found that this topic is published in the control.launch file which uses a "robot_localization" node of the "ekf_localization_node" type.
The tf frame tree of a single robot simulation (without namespaces) looks like this:
But when launched from within the namespace, with multiple robots, looks like this:
I know it's hard to see, but the "odom" frame no longer exists, so this seems the localization is not working properly. My initial guess is that the robot_localization limits the parameters to "map" or "odom" but since I'm using a namespace and tf_prefix, it becomes "husky1/odom" and this is not allowed. But does anyone have any ideas as to how I might be able to correct this or why it might be happening?
Edit 1:
Some additional information, as requested by Tom.
Here are the frame_ids during a single robot simulation with no namespace or tf_prefix
RESULTS: for all Frames
Frames:
Frame: base_footprint published by unknown_publisher Average Delay: -0.000202703 Max Delay: 0
Frame: base_laser published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: base_link published by unknown_publisher Average Delay: -6.75676e-05 Max Delay: 0
Frame: front_bumper_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: front_left_wheel_link published by unknown_publisher Average Delay: 0 Max Delay: 0
Frame: front_right_wheel_link published by unknown_publisher Average Delay: 0 Max Delay: 0
Frame: imu_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: inertial_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: laser_mount_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: rear_bumper_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: rear_left_wheel_link published by unknown_publisher Average Delay: 0 Max Delay: 0
Frame: rear_right_wheel_link published by unknown_publisher Average Delay: 0 Max Delay: 0
Frame: topPlate published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: top_chassis_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: top_plate_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
Frame: user_rail_link published by unknown_publisher Average Delay: -0.000135135 Max Delay: 0
All Broadcasters:
Node: unknown_publisher 150.338 Hz, Average Delay: -6.94586e-05 Max Delay: 0
And here are all the frame_ids shown by tf_monitor when running the multi robot simulation:
RESULTS: for all Frames
Frames:
Frame: husky1/base_footprint published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/base_laser published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/front_bumper_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/front_left_wheel_link published by unknown_publisher Average Delay: 0.0185882 Max Delay: 0.04
Frame: husky1/front_right_wheel_link published by unknown_publisher Average Delay: 0.0185882 Max Delay: 0.04
Frame: husky1/imu_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/inertial_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/laser_mount_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/rear_bumper_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/rear_left_wheel_link published by unknown_publisher Average Delay: 0.0185882 Max Delay: 0.04
Frame: husky1/rear_right_wheel_link published by unknown_publisher Average Delay: 0.0185882 Max Delay: 0.04
Frame: husky1/topPlate published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/top_chassis_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/top_plate_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky1/user_rail_link published by unknown_publisher Average Delay: 0.0182353 Max Delay: 0.04
Frame: husky2/base_footprint published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/base_laser published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/front_bumper_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/front_left_wheel_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/front_right_wheel_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/imu_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/inertial_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/laser_mount_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/rear_bumper_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/rear_left_wheel_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/rear_right_wheel_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/topPlate published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/top_chassis_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/top_plate_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
Frame: husky2/user_rail_link published by unknown_publisher Average Delay: 0.0188824 Max Delay: 0.03
All Broadcasters:
Node: unknown_publisher 200.59 Hz, Average Delay: 0.0186471 Max Delay: 0.04
And this is what my localization.yaml file looks like (it is left the same for both):
map_frame: map
odom_frame: odom
base_link_frame: base_link
world_frame: odom
two_d_mode: true
frequency: 50
odom0: husky_velocity_controller/odom
odom0_config: [false, false, false,
false, false, false,
true, true, true,
false, false, true,
false, false, false]
odom0_differential: false
odom0_queue_size: 10
imu0: imu/data
imu0_config: [false, false, false,
true, true, true,
false, false, false,
true, true, true,
false, false, false]
imu0_differential: true
imu0_queue_size: 10
imu0_remove_gravitational_acceleration: true
print_diagnostics: true
I notice there are no "base_link" frames for the multi-robot version, but I'm not sure what this could mean.
Edit 2:
Here is the output from rqt_map on the working single robot:
And now the output from the multi robot:
So it looks like there are for input topics coming into the localization node for husky1. Here are examples of all:
/tf
transforms:
-
header:
seq: 0
stamp:
secs: 1597
nsecs: 300000000
frame_id: husky1/base_link
child_frame_id: husky1/front_left_wheel_link
transform:
translation:
x: 0.256
y: 0.2854
z: 0.03282
rotation:
x: 0.0
y: 0.144187547375
z: 0.0
w: 0.989550378294
-
header:
seq: 0
stamp:
secs: 1597
nsecs: 300000000
frame_id: husky1/base_link
child_frame_id: husky1/front_right_wheel_link
transform:
translation:
x: 0.256
y: -0.2854
z: 0.03282
rotation:
x: 0.0
y: 0.157750826895
z: 0.0
w: 0.98747894996
-
header:
seq: 0
stamp:
secs: 1597
nsecs: 300000000
frame_id: husky1/base_link
child_frame_id: husky1/rear_left_wheel_link
transform:
translation:
x: -0.256
y: 0.2854
z: 0.03282
rotation:
x: 0.0
y: -0.158428913083
z: 0.0
w: 0.987370386177
-
header:
seq: 0
stamp:
secs: 1597
nsecs: 300000000
frame_id: husky1/base_link
child_frame_id: husky1/rear_right_wheel_link
transform:
translation:
x: -0.256
y: -0.2854
z: 0.03282
rotation:
x: 0.0
y: -0.192699433619
z: 0.0
w: 0.981257829667
/husky1/imu/data
header:
seq: 23902
stamp:
secs: 1776
nsecs: 540000000
frame_id: base_link
orientation:
x: 0.000136499101278
y: 1.42176279272e-05
z: 0.00338303918051
w: 0.999994268089
orientation_covariance: [2.6030820491461885e-07, 0.0, 0.0, 0.0, 2.6030820491461885e-07, 0.0, 0.0, 0.0, 0.0]
angular_velocity:
x: -0.00250481986211
y: 0.000314847644066
z: -0.00384896932272
angular_velocity_covariance: [2.5e-05, 0.0, 0.0, 0.0, 2.5e-05, 0.0, 0.0, 0.0, 2.5e-05]
linear_acceleration:
x: -0.00435986520834
y: 0.00647963661132
z: 9.79696593816
linear_acceleration_covariance: [2.5e-05, 0.0, 0.0, 0.0, 2.5e-05, 0.0, 0.0, 0.0, 2.5e-05]
---
/husky1/husky_controller_velocity/odom
header:
seq: 29601
stamp:
secs: 1890
nsecs: 960000000
frame_id: odom
child_frame_id: base_link
pose:
pose:
position:
x: 0.00760542738025
y: -3.62838407179e-05
z: 0.0
orientation:
x: 0.0
y: 0.0
z: -0.000862957133054
w: 0.999999627652
covariance: [0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.03]
twist:
twist:
linear:
x: 3.82179164307e-05
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: -1.04046111105e-07
covariance: [0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.03]
---
And /tf_static
Which doesn't seem to be publishing anything.
Thanks all!
↧
↧
Help migrating from robot_pose_ekf to robot_localization
Hi,
I am currently trying to migrate to robot_localization. I am using IMU and odometry data for the ekf_localization_node.
When running ekf_localization_node I get a tf error:
Error: TF_NAN_INPUT: Ignoring transform for child_frame_id "base_footprint" from authority "unknown_publisher" because of a nan value in the transform (-nan -nan -nan) (-nan -nan -nan -nan)
at line 240 in /tmp/binarydeb/ros-kinetic-tf2-0.5.15/src/buffer_core.cpp
Error: TF_DENORMALIZED_QUATERNION: Ignoring transform for child_frame_id "base_footprint" from authority "unknown_publisher" because of an invalid quaternion in the transform (-nan -nan -nan -nan)
at line 253 in /tmp/binarydeb/ros-kinetic-tf2-0.5.15/src/buffer_core.cpp
[Here is a Bagfile](http://s000.tinyupload.com/index.php?file_id=09022578863517099218) I made containing IMU and Odometry data.
My cofing:
frequency: 30
sensor_timeout: 0.1
two_d_mode: false
transform_time_offset: 0.0
transform_timeout: 0.0
print_diagnostics: true
debug: false
publish_tf: true
publish_acceleration: false
odom_frame: odom_combined # Defaults to "odom" if unspecified
base_link_frame: base_footprint # Defaults to "base_link" if unspecified
world_frame: odom_combined # Defaults to the value of odom_frame if unspecified
odom0: odom
odom0_config: [true, true, false,
false, false, true,
true, false, false,
false, false, true,
false, false, false]
odom0_queue_size: 2
odom0_nodelay: false
odom0_differential: true
odom0_relative: false
odom0_pose_rejection_threshold: 5
odom0_twist_rejection_threshold: 1
imu0: imu/data
imu0_config: [false, false, false,
true, true, true,
false, false, false,
true, true, true,
true, true, true]
imu0_nodelay: false
imu0_differential: true
imu0_relative: true
imu0_queue_size: 5
imu0_pose_rejection_threshold: 0.8 # Note the difference in parameter names
imu0_twist_rejection_threshold: 0.8 #
imu0_linear_acceleration_rejection_threshold: 0.8 #
imu0_remove_gravitational_acceleration: true
Any chance someone can help me figure this out.
↧
robot_localization ignores pose topic
Hi,
I wish to compare the outputs of two instances of robot localization on Clearpath's Jackal: one that gets IMU and odometry as inputs and another that gets the same IMU and odometry topics but also a pose topic that originates in observations from a UAV that hovers above.
It seems like the second instance ignores the pose topic since the outputs of the two instances are identical:
[plot of the two outputs of the two instances](https://drive.google.com/open?id=0BxGCYwjzq79dUTB3RS16ZjlySEU)
Below are the two .yaml config files of the two instances:
**robot_localization.yaml**
frequency: 50
odom0: /jackal_velocity_controller/odom
odom0_config: [false, false, false,
false, false, false,
true, true, true,
false, false, true,
false, false, false]
odom0_differential: false
imu0: /microstrain/imu/data
imu0_config: [false, false, false,
true, true, true,
false, false, false,
true, true, true,
false, false, false]
imu0_differential: false
odom_frame: odom
base_link_frame: base_link
world_frame: odom
**robot_localization_collaborative.yaml**
frequency: 50
publish_tf: false
odom0: /jackal_velocity_controller/odom
odom0_config: [false, false, false,
false, false, false,
true, true, true,
false, false, true,
false, false, false]
odom0_differential: false
pose0: /ugv_pose_from_air
pose0_config: [true, true, false,
false, false, false,
false, false, false,
false, false, false,
false, false, false]
pose0_differential: false
imu0: /microstrain/imu/data
imu0_config: [false, false, false,
true, true, true,
false, false, false,
true, true, true,
false, false, false]
imu0_differential: false
odom_frame: odom
base_link_frame: base_link
world_frame: odom
I uploaded a bag file and sample messages of the three EKF input topics [here](https://drive.google.com/open?id=0BxGCYwjzq79dbjJnY0FPZFd1S2s).
My code is available in [GitHub](https://github.com/omershalev/jackal/tree/indigo-devel/jackal_control).
Thanks!
↧
How to customize robot_localization
I'm using robot_localization package offered by ROS community. I've read over the relevant documents and code. I want to customize it based on the package .Here's my question:
1.If I have one odom and one imu as data source, then only odom0 & imu0 are needed, can I just delete contents about odom1,pose0 and twist0 ?
2.I enable X,Yaw,Vx,Yawrate in odom0_config and Yawrate,Ax in imu0_config. I should set the covariance of these variables mentioned before properly,what about the rest of covariances(including Q and P) whose variables being disabled? Maybe set them to small value (eg.1e-6)?
3.If I want to operate in 2D mode, I need to enable two_d_mode. Should I adjust the transfer function matrix to 2D mode?
4.If I want to adopt the robot_localization. I need to modify the document named ekf_template.yaml, making some change on covariance matrices and deleting some unused contents.Also, I need to modify the transfer function and transfer function Jacobian matrices or say,just simplify it. Is that so?
5.Is the coordinates used in transfer function right-handed coordinate system with X pointing forward ?
I do appreciate it if someone can enlighten it to me.
↧
Indoor GPS with Navsat_transform
I have a set of [Marvelmind robotics](http://www.marvelmind.com/) indoor GPS beacons and have it setup with pose data(no yaw, only x,y) published on a topic with msg type: nav_msgs::Odometry
Is there a way to get this works with the Navsat transform? UTM co-ordinates are not used here.
Is this the route to go:
1. One instance of robot_localization with continuous sensors, in odom_frame.
2. Second instance of robot_localization with output of (1.) + GPS(pose0) in map frame
I'm using [this](http://docs.ros.org/kinetic/api/robot_localization/html/integrating_gps.html#notes-on-fusing-gps-data) documentation as a reference.
Thanks.
↧
↧
How to improve the reliability of my robot's localization ?
## Context ##
I have a differential drive robot with 4 wheels, similar to the Clearpath Jackal. It moves in a closed environment in indoor and outdoor, and the map is known. It is equipped with a laser range, an IMU, and odometry is computed thanks to wheel encoders. The robot is also equipped with a GPS, but I would prefer not to use it for now.
Some area of the map (outdoor) are such that the robot walk through "weak" localization phases due too lack of landmarks.
I am trying to improve the localization chain, to be more robust to these "weak" localization phases.
Basically what I am trying to do is to be able to navigate in a degraded mode whitout being completely lost (i.e. AMCL could be lost temporarily but tf map -> odom would still be available).
## Setup ##
I use a first "local" robot_localization instance to fuse odom and imu data. This outputs what I called /odom/filtered.
Next I have an AMCL instance, which takes as input laser range measurements and /odom/filtered.
Then I fuse the AMCL position, odom and imu with a second "global" robot_localization instance.
The first local ekf_localizer provides odom -> base_link transform
The second global ekf_localizer provides map -> odom
The output of the first local ekf_localization is really good as I can see in rviz (The robot return to about 1m from it's departure point after a loop of 93m x 35m, cf image).
odom(blue) vs odom filtered(red)
- **Os:** Ubuntu Server 14.04 with ROS Indigo
- **Localization:** [robot_localization](http://wiki.ros.org/robot_localization) (v2.3.0) package with [AMCL](http://wiki.ros.org/amcl) (v 1.12.13)
- **Visualization:** To visualize the covariance of the position and odometry, the [rviz_plugin_covariance](https://github.com/laas/rviz_plugin_covariance) is used.
## AMCL Covariance problem ##
All this chain is based on the covariance of the respective measurements. So the covariance matrix values must be as representative of the reality as possible and it seems that's not the case.
At first I thought that the position covariance provided by AMCL was an estimation of how confident AMCL is on the current robot position in the map, but I am not sure. By displaying the covariance, I see that the robot localization is inside an ellipsoid about 20 to 30cm in diameter when it is well localized.
Note: For readability purpose, the displayed ellipsoid is 3sigma (estimated position +- 3 times the standard deviation)
When AMCL begin to get lost the covariance increase significantly,
and then decrease to, again, 20 to 30 cm in diameter, but with AMCL sometimes being really lost !
Why this strange behavior ? This causes the global ekf_localization to "trust" the position more than the odometry.
In an attempt to workaround this behavior, I tried a naive approach : if the covariance ellipsoid is more than 50cm in diameter, I stop sending the AMCL position to the global ekf node. When the diameter is less than 50cm, I send the current estimated positon as initial position of AMCL. In some way it works well, but the reinitialization of AMCL is worse than expected : most of the time it founds an erroneous position. I need a way to estimate the quality of the AMCL output.
I found this : https://github.com/dejanpan/snap_map_icp which is a node which performs an ICP (Iterative Closest Point) to get a corrected pose and reset amcl particule distribution, but I haven't tried it yet.
## Global ekf covariance ##
Another problem is the value of the global ekf covariance: when I momentarily disable AMCL pose input, the covariance begin to increase. That's normal, because the filter is only fed with odom and imu measurements. But it increase a lot: for example, the robot moving in strait line, after a few meters the incertitude ellipsoid displayed can reach several meters. This does not reflect the reality of the output of the first local ekf.
Is this a normal behavior ? or my covariance values for odom and or imu are bad ?
odom.twist.covariance[covIndex(0, 0)] = 0.002304;
odom.twist.covariance[covIndex(1, 1)] = 1e-6; //Very small because non holonomous robot
odom.twist.covariance[covIndex(2, 2)] = 1e-6; //very small because not measured ?
odom.twist.covariance[covIndex(3, 3)] = 1e-6; //very small because not measured ?
odom.twist.covariance[covIndex(4, 4)] = 1e-6; //very small because not measured ?
odom.twist.covariance[covIndex(5, 5)] = 0.00188411;
The covariance values for linear speed and angular speed are the result of specific measurement, so these are good.
I have a doubt about (2,2) (3,3) and (4,4) if they need to be really big or really small... But it's not so important as the corresponding value are disabled in input of the ekf node.
//Position covariance is supposed to increase because robot's position drifts ??`
odom.pose.covariance[covIndex(0, 0)] = 0.01;
odom.pose.covariance[covIndex(1, 1)] = 0.01;
odom.pose.covariance[covIndex(2, 2)] = 1e-6;
odom.pose.covariance[covIndex(3, 3)] = 1e-6;
odom.pose.covariance[covIndex(4, 4)] = 1e-6;
odom.pose.covariance[covIndex(5, 5)] = 0.1;
For now the odometry pose covariance values are fixed, but I think they should increase over time. If I understand, fixed values should give me a smaller covariance than the real one, so this does not explain the big covariance values I have.
IMU Covariance (Computed from datasheet parameters):
imu angular_velocity_covariance(0, 0) = 2.7415569547883933e-07
imu angular_velocity_covariance(1, 1) = 2.7415569547883933e-07
imu angular_velocity_covariance(2, 2) = 2.7415569547883933e-07
linear_acceleration_covariance(0, 0) = 7.789801020408049e-05
linear_acceleration_covariance(1, 1) = 7.789801020408049e-05
linear_acceleration_covariance(2, 2) = 7.789801020408049e-05
Configuration of the first "local" EKF node:
frequency: 20
two_d_mode: true
# X, Y, Z
# roll, pitch, yaw
# X vel, Y vel, Z vel
# roll vel, pitch vel, yaw vel
# X accel, Y accel, Z accel
#Odometry input config
odom0: /odom
odom0_config: [false, false, false,
false, false, false,
true, true, false,
false, false, true,
false, false, false]
odom0_differential: false
odom0_relative: true
#IMU input config
imu0: /imu_data
imu0_config: [false, false, false,
false, false, false,
false, false, false,
true, true, true,
false, false, false]
imu0_differential: false
imu0_relative: true
imu0_remove_gravitational_acceleration: false
#Frames config
odom_frame: odom
base_link_frame: base_link
world_frame: odom
Configuration of the "global" EKF node:
frequency: 10
two_d_mode: true
# X, Y, Z
# roll, pitch, yaw
# X vel, Y vel, Z vel
# roll vel, pitch vel, yaw vel
# X accel, Y accel, Z accel
#Odometry input config
odom0: /odom
odom0_config: [false, false, false,
false, false, false,
true, true, false,
false, false, true,
false, false, false]
odom0_differential: false
odom0_relative: true
#IMU input config
imu0: /imu_data
imu0_config: [false, false, false,
false, false, false,
false, false, false,
true, true, true,
false, false, false]
imu0_differential: false
imu0_relative: true
imu0_remove_gravitational_acceleration: false
#Pose from localizer
pose0: /localizer/pose_filtered
pose0_config: [true, true, false,
false, false, true,
false, false, false,
false, false, false,
false, false, false]
pose0_differential: false
pose0_relative: false
#Frames config
odom_frame: odom
base_link_frame: base_link
world_frame: map
If you have any thought about all this setup, it would be really appreciated.
Thanks in advance
### Update1: ###
Relative to @TomMoore answer.
I tuned the process_noise_covariance for both of the ekf_localization nodes, and it improved a lot the resulting output covariance.
**Edit:** I updated a new screenshot showing when all data is fused (odom, imu, amcl pose) in green and when only odom and imu are fused in orange.
I added in both configuration files :
process_noise_covariance: [0.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001, 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.0001]
↧
How to tune robot_localization parameter
Hi Tom/all
It's mentioned in the document of robot_localization that we can achieve superior results by tuning Q. If the odom data input has noise, which leads to oscillating trajectory as can be seen below. So is tuning Q the only way to eliminate that? What should I do with that ?
I do appreciate it if you can enlighten it to me.Thank you so much.
↧
robot_localization IMU and visual odometry from rtabmap
I realize this topic has come up a lot, but I've read every related question on here and nothing is quite working yet.
I have a depth camera and an IMU. The IMU is rigidly attached to the camera. I'm using rtabmap to produce visual odometry and localize against a map I previously created, and I've created my own IMU node called Tacyhon for my invensense MPU 9250 board.
Here are my frames and rosgraph...
The acceleration and angular velocity seem to be working fine, however, orientation is relative to camera_link, not relative to map. Thus a 90 degree rotation results in robot_localization thinking that the IMU is facing 180 degrees from its starting location, since it is 90 degrees rotated from camera_link. How can I set my acceleration and angular velocity from the IMU topic to be relative to camera link, but my orientation data to be relative to map so that r_l can fuse the orientation from the IMU with the orientation from rtabmap?
Here is my launch file.
Any help would be appreciated!
[false, false, false,
true, true, true,
false, false, false,
true, true, true,
true, true, true]
[true, true, true,
true, true, true,
false, false, false,
false, false, false,
false, false, false]
↧
Transform different to its own inverse
When configuring `robot_localization` today I came across a weird phenomenon which is, I think, an error. I'm using `navsat_transform_node` to take in our GPS data, and I have the `broadcast_utm_transform` parameter set to `true`. When using `tf_monitor` to view the transforms `utm -> map` and `map -> utm`, they actually differ in translational value, and one is not the negative of the other. [See here](http://imgur.com/a/5QswT) for the result of `tf_monitor`. The time says '0.000', meaning it is a static transform, so it doesn't seem like it can be multiple publishers.
**robot_localization.launch**
[-27.454919, 153.029867, 0.0] [false, false, false,
false, false, false,
true, true, true,
false, false, true,
false, false, false] [false, false, false,
true, true, true,
false, false, false,
true, true, true,
true, true, true,] [false, false, false,
false, false, false,
true, true, true,
false, false, true,
false, false, false] [true, true, false,
false, false, false,
false, false, false,
false, false, false,
false, false, false] [false, false, false,
true, true, true,
false, false, false,
true, true, true,
true, true, true,]
↧
↧
Axis conventions
Hi everybody,
I need some clarification on the axis orientation convention used in the package robot_localization.
I am pretty sure answers will be profitable for everybody as this is giving me headeach.
For acceleration of [Imu](http://docs.ros.org/kinetic/api/robot_localization/html/preparing_sensor_data.html#imu) , the wiki says :
> Imu neutral,
> Measure +9.81 meters per second
> squared for the Z axis.
> If the sensor is rolled +90 degrees
> (left side up), the acceleration
> should be +9.81 meters per second
> squared for the Y axis.
>> If the sensor is pitched +90 degrees
> (front side down), it should read
> -9.81 meters per second squared for the X axis.
I understand, that in local frame:
> x up
> y right
> z down
But according to the REP 103:
> In relation to a body the standard is:
> x forward
> y left
> z up
At least, i understand that for magnetometer which is related to "short-range Cartesian representations of geographic locations" of REP-103:
> X east
> Y north
> Z up
1) Is it correct that odom/map frame (for magnetometer, barometer) have a different axis convention than local frame (for accel, gyro).
2) Am i misunderstanding the conventions used, or there is a mistake on the wiki ?
I have drift issue on the orientation, and i think it is related to some conflict between sensors.
Here is the conventions of my IMU (It seems to be reversed ...):
![Heberger image]()
Thanks in advance
Thanks in advance
↧
Yet another problem with robot_localization and amcl
Hi there,
I've read several threads about robot_localization with amcl and odometry data, but I have not being able to make it work.
**What I did:**
- amcl config file:
tf_broadcast: false
- ekf config file
publish_tf: true
map_frame: "/map"
odom_frame: "/base_odom_link"
base_link_frame: "/base_footprint_link"
world_frame: "/map"
odom0: "/dev/odom"
pose0: "/amcl_pose"
The `odometry/filtered` topic is almost the same as the `/dev/odom`, which means it is filtering the odom_frame. This looked to me as if the ekf could not read the config file and went to its default settings. But I checked the rqt_graph and it listens to the right odom and pose topic.
If a set the `tf_broadcast` of the amcl to true. The scan matches in RVIZ jump between the amcl and ekf tf, which is somehow the same as odom.
**What am I missing?**
**Edit 1:** in response to comments from @Nicholash Bedi
odom0_config: [true, true, false,
false, false, true,
true, true, false,
false, false, true,
false, false, false]
odom0_differential: true
odom0_relative: false
pose0_config: [true, true, false,
false, false, true,
false, false, false,
false, false, false,
false, false, false]
pose0_differential: false
pose0_relative: false
**Edit 2:** uploaded pics of my config files.
Hopefully you can see the error.
[ekf_config.jpg](/upfiles/14890512606654804.jpg)
[amcl_config.jpg](/upfiles/1489051347508047.jpg)
**Edit 3** In response to @Tom Moore -> output of rostopic echo /amcl_pose and /dev/odom. I am sorry for the very very late response
**odom**
header:
seq: 161063
stamp:
secs: 1495189822
nsecs: 753257722
frame_id: base_odom_link
child_frame_id: base_footprint_link
pose:
pose:
position:
x: -0.0955580770969
y: -0.127791434526
z: 0.0
orientation:
x: 0.0
y: -0.0
z: -0.00566518455002
w: -0.999983952713
covariance: [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.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]
twist:
twist:
linear:
x: 0.0
y: 0.0
z: 0.0
angular:
x: 0.0
y: 0.0
z: 0.0
covariance: [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.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]
**amcl**
header:
seq: 185
stamp:
secs: 1495187483
nsecs: 905225829
frame_id: /map
pose:
pose:
position:
x: 2.232329958
y: 4.91519891085
z: 0.0
orientation:
x: 0.0
y: 0.0
z: 0.692934073576
w: 0.721000949845
covariance: [0.0028978789516864722, -0.0026280780170626628, 0.0, 0.0, 0.0, 0.0, -0.0026280780170626628, 0.018904477044003443, 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.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.008812990937814283]
Thanks and kind regards,
Julio
↧
Problem about the consistency of positioning results using robot_localization
Hi Tom and everybody,
I'm using robot_localization to solve the problem of mobile robot positioning. The sensors used are IMU, odometry(from wheel encoders), UWB. After tune parameters i got a good positioning result, then i found a problem that positioning results are not same, consistency when the input sensors' data (rosbag) are the same and parameters are the same. At the beginning, I think the reason is that the parameters are inappropriate, so i tune parameters for a long time, what is very unpleasant is that the result is still inconsistent. Then I am confused, What is the reason for the inconsistency and instability?
Any help is appreciated. Thanks.
↧