I use rgblslamv2 to generate PCD file and octomap file,but they have wrong coordinates.
For example,I use the kinect to explore environment,it means my view to see the object is in a parallel to the ground,it may should let my environment looks like that:

But in the below is what I get: the inital coordinate before I rotate is likely be Vertical to the view I want,and the parameter:4.15*2.53*4.77m^3 proofs that I get a wrong coordinate.

If I want to look it at rviz: yes the ground is vertical.

How can I do to convert the coodinate system?
I just feel the coordinate system depends on my first camera frame?If it is true,my camera just walk in a plane...
Now I have no idea for that?
Do you have any suggestion?
Thanks!
↧
PCD file and octomap file generated by rgblslamv2 have wrong cooedinate
↧
RobotSetup tf: Can't build in Catkin_make
catkin_make
Base path: /home/hy/catkin_ws
Source space: /home/hy/catkin_ws/src
Build space: /home/hy/catkin_ws/build
Devel space: /home/hy/catkin_ws/devel
Install space: /home/hy/catkin_ws/install
####
#### Running command: "make cmake_check_build_system" in "/home/hy/catkin_ws/build"
####
####
#### Running command: "make -j4 -l4" in "/home/hy/catkin_ws/build"
####
hy catkin_ws $ catkin_make
Base path: /home/hy/catkin_ws
Source space: /home/hy/catkin_ws/src
Build space: /home/hy/catkin_ws/build
Devel space: /home/hy/catkin_ws/devel
Install space: /home/hy/catkin_ws/install
####
#### Running command: "make cmake_check_build_system" in "/home/hy/catkin_ws/build"
####
####
#### Running command: "make -j4 -l4" in "/home/hy/catkin_ws/build"
####
make[2]: *** No rule to make target 'robot_setup_tf/CMakeFiles/tf_broadcaster.dir/build'. Stop.
CMakeFiles/Makefile2:2592: recipe for target 'robot_setup_tf/CMakeFiles/tf_broadcaster.dir/all' failed
make[1]: *** [robot_setup_tf/CMakeFiles/tf_broadcaster.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 8%] Built target tf_listener
[ 8%] Built target _axon_link_generate_messages_check_deps_AxonApp
[ 8%] Built target _axon_link_generate_messages_check_deps_AxonNode
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j4 -l4" failed
Above is the error displayed in the command prompt terminal. I was trying the navigation tutorial (building tf)
http://wiki.ros.org/navigation/Tutorials/RobotSetup/TF
Thanks
↧
↧
robot_localization tf tree changes from odom -> base to map -> base when using a custom particle filter
Hello,
I have robot_localization setup to fuse IMU data from a flight controller with pose data from ORB-SLAM. I am also using gmapping to generate a 2D map. When I run my robot_localization node, my tf tree becomes odom -> base_link -> camera_link, which I think is what I'm supposed to get because right now I'm assuming that my camera is my base. However, I'm also trying to incorporate a particle filter into this setup. And when I try to run my particle filter, my tf tree changes to map -> base_link and I'm not sure why. I've been trying to find answers but I feel like a lot is going over my head.
In any case, here are the steps I did when I was using robot_localization and also use the particle filter:
1. Go to a known fixed position (initial point).
2. Run camera, ORB, robot_localization node, and gmapping. (At this point, my tf tree is odom -> base_link)
3. Start mapping around and return to initial point when done.
4. Save the map using map_server.
5. Close gmapping.
6. Launch the particle filter and range finders. (This is where my tf tree changes to map -> base_link while my odom frame seems to just float and is unconnected to anything).
Also here is the config file I use for my robot_localization node:
frequency: 50
sensor_timeout: 0.1
two_d_mode: true
transform_time_offset: 0.0
transform_timeout: 0.0
print_diagnostics: true
debug: false
publish_tf: true
publish_acceleration: false
map_frame: map # Defaults to "map" if unspecified
odom_frame: odom # Defaults to "odom" if unspecified
base_link_frame: base_link # Defaults to "base_link" if unspecified
world_frame: odom # Defaults to the value of odom_frame if unspecified
pose0: /orb/pose
pose0_config: [true, true, true, # Position
true, true, true, # Orientation
false, false, false, # Linear Velocity
false, false, false, # Angular Velocity
false, false, false] # Linear Acceleration
pose0_queue_size: 2
pose0_nodelay: false
pose0_differential: false
pose0_relative: false
imu0: /mavros/imu/data
imu0_config: [true, true, true, # Position
true, true, true, # Orientation
false, false, false, # Linear Velocity
true, true, true, # Angular Velocity
true, true, true] # Linear Acceleration
imu0_nodelay: false
imu0_differential: true
imu0_relative: false
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: false
use_control: true
stamped_control: false
control_timeout: 0.2
control_config: [true, false, false, false, false, true]
acceleration_limits: [1.3, 1.0, 0.0, 0.0, 0.0, 3.4]
deceleration_limits: [1.3, 1.0, 0.0, 0.0, 0.0, 4.5]
acceleration_gains: [0.8, 0.5, 0.0, 0.0, 0.0, 1.5]
deceleration_gains: [1.0, 0.7, 0.0, 0.0, 0.0, 1.0]
process_noise_covariance: [0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0.05, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0.06, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0.03, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0.03, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0.06, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0.025, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0.025, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0.04, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.02, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.01, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.015]
initial_estimate_covariance: [1e-6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 1e-6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-5, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-5, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-6, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-6, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1e-9]
↧
Publishing map->odom for custom particle filter (BFL)
Hi,
I am having some trouble trying to implement the map->odom transform for our robot setup. Our stack uses ORB-SLAM, Robot Localization, Gmapping, and finally our own custom particle filter. So far, our tf tree from ORB-SLAM/Robot Localization EKF/Gmapping is functional (`odom -> base_link`) and is able to generate a map.
Our problem right now is trying to implement the `map->odom` transform in order to use our custom BFL. Our code is derived from the [BFL tutorial](http://wiki.ros.org/bfl/Tutorials/Example%20of%20using%20a%20particle%20filter%20for%20localization%20by%20bfl%20library) and is able to subscribe to range finder data and publish the map pose, which we believe is what we can use to calculate the `map->base_link` transform. We know from doing a bit of online digging that we can just use the inverse of the `odom->base_link` and combine it with `map->base_link` to generate the `map->odom` transform, but we are stuck with trying to write the code. Trying to use the AMCL code as a reference (the [laserReceived function](https://github.com/ros-planning/navigation/blob/kinetic-devel/amcl/src/amcl_node.cpp#L1044) in particular) is proving to be difficult so we're hoping to get some sort of guidance by way of some simpler sample code.
One hint we got from the AMCL code is that we might be able to "[subtract] base to odom from map to base and send map to odom instead", which we think would simply be something like this:
`map->base_link` - `base_link->odom` = `map->odom`
Or somewhere in our code, maybe have something like this:
base_odom_pose = odom_msg.pose.pose.inverse() //where odom_msg is taken from our EKF
map_base_pose = bfl_pose
map_odom_pose = map_base_pose - base_odom_pose
↧
Is a Joint in URDF a frame in tf?
Hi everyone!
I know this might sound silly but I just want to ask simple question to reassure myself. Is a joint in a URDF considered a frame in the TF library?
Thanks!
↧
↧
Does tf::StampedTransform create a parent and child frame if they both do not exist?
Hi everyone!
Quick question on tf::StampedTransform. By using that function in C++ does it create parent frame and child frame automatically?
EX:
br.sendTransform(tf::StampedTransform(transform, ros::Time::now(), "banana", "basket"));
In this case does the frame `banana` and `basket` get created?
Thanks!
↧
While building tf map for gmapping, how to set tf tree?
While building tf map for gmapping, how to set tf tree?
Following document,
http://wiki.ros.org/gmapping
----------------------------------------------------
Subscribed Topics
tf (tf/tfMessage)Transforms necessary to relate frames for laser, base, and odometry (see below)
scan (sensor_msgs/LaserScan)Laser scans to create the map from
----------------------------------------------------
I understood like as follow.
> subscribe topie as tf made it from laser , base, odom topic, and publish map topic.
> to transform tf using [ laser , base, odom ]
And in the document say like below to for making tf tree
----------------------------------------------------
Required tf Transforms
→ base_linkusually a fixed value, broadcast periodically by a robot_state_publisher, or a tf static_transform_publisher.
base_link → odomusually provided by the odometry system (e.g., the driver for the mobile base)
Provided tf Transforms
map → odomthe current estimate of the robot's pose within the map frame
----------------------------------------------------
Document say,
[ map → odom ]
[ base_link → odom ]
but, the project I run gmapping & built map show the tf tree like below
[ map -> odom -> base_footprint -> base_link -> base_scan ]
I can not understand what does document saying.
As I guess,
[ → base_link ] this could be changed as
[ base link -> base scan ] [ odom -> base link ] like that.
please understand me.
Thankyou.
↧
trying to understan my frames and tf
I have an ASV driven by a pixhawk, running ardurover, and a raspberry pi 3 as a companion computer.
Connected to the PI there is an hokuyo lidar.
I want to use IMU, odom and laser data on google cartographer, but I'm a little confuse about my frames and needed TF.
This is pixhawk IMU topic:
header:
seq: 324
stamp:
secs: 1455208218
nsecs: 779422082
frame_id: "base_link"
orientation:
x: -0.0196528313319
y: -0.0373457958945
z: 0.507724505298
w: -0.860485261041
orientation_covariance: [1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]
angular_velocity:
x: 0.000183623924386
y: -0.000642724335194
z: -2.97694932669e-05
angular_velocity_covariance: [1.2184696791468346e-07, 0.0, 0.0, 0.0, 1.2184696791468346e-07, 0.0, 0.0, 0.0, 1.2184696791468346e-07]
linear_acceleration:
x: -0.65704555
y: -0.02941995
z: 10.0223963
linear_acceleration_covariance: [8.999999999999999e-08, 0.0, 0.0, 0.0, 8.999999999999999e-08, 0.0, 0.0, 0.0, 8.999999999999999e-08]
---
as you can see pixhawk is publish IMU under base_link frame.
This is laser data publish by urg_node:
---
header:
seq: 532
stamp:
secs: 1455208419
nsecs: 333519654
frame_id: "laser"
angle_min: -2.35619449615
angle_max: 2.09234976768
angle_increment: 0.00613592332229
time_increment: 9.76562732831e-05
scan_time: 0.10000000149
range_min: 0.019999999553
range_max: 5.59999990463
ranges: [0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239, 0.01899999938905239,
Hokuyo lidar frame is laser. The lidar is mounted rotated 90ª CW from X axis of pixhawk and translated 0.5mts to teh right.
finally odom msg:
header:
seq: 1556
stamp:
secs: 1455208296
nsecs: 310980854
frame_id: "map"
child_frame_id: "base_link"
pose:
pose:
position:
x: -0.005535364151
y: -0.267928063869
z: 0.0810627788305
orientation:
x: -0.0192797667306
y: -0.0368807024663
z: 0.50707105612
w: -0.860898976899
covariance: [1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-06, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1e-06]
twist:
twist:
linear:
x: -0.00152582221037
y: -0.0375590241358
z: -0.00955859516847
angular:
x: -7.68475001678e-06
y: -0.000235044397414
z: 0.00026510679163
covariance: [0.0001, 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.0001, 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.0001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0001]
---
here starts my questions.
Why odom msg have a frame_id and a child_frame_id?
Do I have 2 links on my setup? They are base_link and laser, right. Is It the same that have 2 frames?
I have more questions, but this is a start.
Thank!
↧
Robot_localization IMU frame tf
Im running a simulation in Gazebo combining the odomery data (coming from the differential drive plugin) and the imu data (from GazeboRosImuSensor plugin). Im quite new to ROS and im totally confused with the ENU and NED frames ..
This is what I did
1)placed the IMU in its neutral position
2)setup a static transform broadcaster which broadcasts my base_link to odom frame
here i made the rotation.
this is the code snippet in my launch file
I have rolled it by 180 and yaw by 90
I tested the IMU and it shows correct accelerations as shown (http://docs.ros.org/lunar/api/robot_localization/html/preparing_sensor_data.html)
But when i visualise my odometrydatas, the unfiltered odometry data(from diffdrive plugin) and the filtered odometry data(from robot_localization) are in opposite orientation. This happens only when include my imu as an input to the robot_localization package.
↧
↧
robot_localization IMU tf
Ive been working on a simulation in gazebo which uses the robot_localization package for fusing odometry data(from differential drive plugin in gazebo) and the IMU data (from GazeboRosImuSensor).
I know that the IMU needs to be oriented in ENU but im confused how to achieve that.
This is what I've done.
1)placed the IMU in its neutral position
2)started a stactic transform broadcast node which broadcasts a transform from base_link to imu_link with 180 roll and 90 yaw.
this is a codesnippet of my launch file
But when I visualise the filtered and unfiltered odometer data the filtered one(from robot_localization ) is oriented 180 degree from the robots real orientation and this happens only when i add my IMU data as an input to the robot_localization filter.
Please help me
↧
map does not show up on RVIZ while using hector_slam
Hello everyone, i am using RPLIDAR A1 and hector_slam but so for there is no luck, RVIZ will start with nothing and no map in it. Here is the details:
from this topic https://github.com/robopeak/rplidar_ros/blob/master/launch/rplidar.launch
roslaunch rplidar rplidar.launch
and i think it runs fine because i get this
SUMMARY
========
PARAMETERS
* /rosdistro: kinetic
* /rosversion: 1.12.7
* /rplidarNode/angle_compensate: True
* /rplidarNode/frame_id: laser
* /rplidarNode/inverted: False
* /rplidarNode/serial_baudrate: 115200
* /rplidarNode/serial_port: /dev/ttyUSB0
NODES
/
rplidarNode (rplidar_ros/rplidarNode)
auto-starting new master
process[master]: started with pid [2876]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to 4191033a-ff48-11e7-a91f-08002791f4c4
process[rosout-1]: started with pid [2889]
started core service [/rosout]
process[rplidarNode-2]: started with pid [2903]
RPLIDAR running on ROS package rplidar_ros
SDK Version: 1.5.7
RPLIDAR S/N: 4450FBF2C8E49CCFC6E49FF1BA82530D
Firmware Ver: 1.20
Hardware Rev: 0
RPLidar health status : 0
then i run
roslaunch hector_slam_launch tutorial.launch
and i get
SUMMARY
========
PARAMETERS
* /hector_geotiff_node/draw_background_checkerboard: True
* /hector_geotiff_node/draw_free_space_grid: True
* /hector_geotiff_node/geotiff_save_period: 0.0
* /hector_geotiff_node/map_file_base_name: hector_slam_map
* /hector_geotiff_node/map_file_path: /home/mohamed/cat...
* /hector_geotiff_node/plugins: hector_geotiff_pl...
* /hector_mapping/advertise_map_service: True
* /hector_mapping/base_frame: base_link
* /hector_mapping/laser_z_max_value: 1.0
* /hector_mapping/laser_z_min_value: -1.0
* /hector_mapping/map_frame: map
* /hector_mapping/map_multi_res_levels: 2
* /hector_mapping/map_resolution: 0.05
* /hector_mapping/map_size: 2048
* /hector_mapping/map_start_x: 0.5
* /hector_mapping/map_start_y: 0.5
* /hector_mapping/map_update_angle_thresh: 0.06
* /hector_mapping/map_update_distance_thresh: 0.4
* /hector_mapping/odom_frame: nav
* /hector_mapping/pub_map_odom_transform: True
* /hector_mapping/scan_subscriber_queue_size: 5
* /hector_mapping/scan_topic: scan
* /hector_mapping/tf_map_scanmatch_transform_frame_name: scanmatcher_frame
* /hector_mapping/update_factor_free: 0.4
* /hector_mapping/update_factor_occupied: 0.9
* /hector_mapping/use_tf_pose_start_estimate: False
* /hector_mapping/use_tf_scan_transformation: True
* /hector_trajectory_server/source_frame_name: scanmatcher_frame
* /hector_trajectory_server/target_frame_name: /map
* /hector_trajectory_server/trajectory_publish_rate: 0.25
* /hector_trajectory_server/trajectory_update_rate: 4.0
* /rosdistro: kinetic
* /rosversion: 1.12.7
* /use_sim_time: True
NODES
/
hector_geotiff_node (hector_geotiff/geotiff_node)
hector_mapping (hector_mapping/hector_mapping)
hector_trajectory_server (hector_trajectory_server/hector_trajectory_server)
map_nav_broadcaster (tf/static_transform_publisher)
rviz (rviz/rviz)
ROS_MASTER_URI=http://localhost:11311
core service [/rosout] found
process[rviz-1]: started with pid [2961]
process[hector_mapping-2]: started with pid [2962]
process[map_nav_broadcaster-3]: started with pid [2963]
process[hector_trajectory_server-4]: started with pid [2964]
process[hector_geotiff_node-5]: started with pid [2995]
[ INFO] [1516607154.164305614]: Waiting for tf transform data between frames /map and scanmatcher_frame to become available
HectorSM map lvl 0: cellLength: 0.05 res x:2048 res y: 2048
HectorSM map lvl 1: cellLength: 0.1 res x:1024 res y: 1024
[INFO] [1516607154.473640201]: HectorSM p_base_frame_: base_link
[ INFO] [1516607154.473985848]: HectorSM p_map_frame_: map
[ INFO] [1516607154.474065501]: HectorSM p_odom_frame_: nav
[ INFO] [1516607154.474138367]: HectorSM p_scan_topic_: scan
[ INFO] [1516607154.474426569]: HectorSM p_use_tf_scan_transformation_: true
[ INFO] [1516607154.474568112]: HectorSM p_pub_map_odom_transform_: true
[ INFO] [1516607154.474655361]: HectorSM p_scan_subscriber_queue_size_: 5
[ INFO] [1516607154.474935408]: HectorSM p_map_pub_period_: 2.000000
[ INFO] [1516607154.475020520]: HectorSM p_update_factor_free_: 0.400000
[ INFO] [1516607154.475194516]: HectorSM p_update_factor_occupied_: 0.900000
[ INFO] [1516607154.475280399]: HectorSM p_map_update_distance_threshold_: 0.400000
[ INFO] [1516607154.475563451]: HectorSM p_map_update_angle_threshold_: 0.060000
[ INFO] [1516607154.475713128]: HectorSM p_laser_z_min_value_: -1.000000
[ INFO] [1516607154.475856377]: HectorSM p_laser_z_max_value_: 1.000000
[ INFO] [1516607154.551815279]: Successfully initialized hector_geotiff MapWriter plugin TrajectoryMapWriter.
[ INFO] [1516607154.551977862]: Geotiff node started
----------
and RVIZ open up but with no map or anything, even though i am sure the RPLIDAR is publishing through /scan
i tried to follow the solution presented here https://hackaday.io/project/7284-oscar-omni-service-cooperative-assistant-robot/log/26164-first-foray-into-ros
but id did not solve my problem, any help will be appreciate it. I have been trying to figure it out for 3 days now
↧
Cannot get odom->base_link from laser_scan_matcher
Hi,
I have a scanse spinning lidar that I'm trying to use to generate a map using gmapping. Right now I have a `base_link->laser_frame` tf that I am publishing using `tf2_ros`. Since gmapping requires a `odom->base_link` tf, I am now trying to use `laser_scan_matcher` to generate that transform.

However, I'm stuck with trying to generate the `odom->base_link`. Here is the launch file I'm using:
Additionally, I'm getting the following warning when running `laser_scan_matcher`:

I am using Ubuntu 16.04 with ROS Kinetic with the scanse sweep-ros wrapper.
Thanks in advanced!
↧
Where's the official Python API documentation for TF?
The web article http://wiki.ros.org/tf only seems to point to the C++ API documentation (e.g. the following sub-article http://wiki.ros.org/tf/Overview/Data%20Types only contains C++ examples). I would like to use Python instead. I would like to read the official Python documentation for `tf`. Where can I find it?
In other ROS Wiki pages, there's usually the possibility to see both the Python and C++ version of the code or documentation. Why doesn't http://wiki.ros.org/tf provide such a duality?
I know there are a few `tf` tutorials (e.g. http://wiki.ros.org/tf/Tutorials/Writing%20a%20tf%20broadcaster%20%28Python%29) which use Python, but I would like to see all other examples and documentation in Python. There's this page http://mirror.umd.edu/roswiki/doc/diamondback/api/tf/html/python/tf_python.html, but it doesn't seem to be official.
I have also seen that there's also a new Python interface to the new tf library, i.e. to `tf2`, which is called `tf2_ros`. However, the documentation is pretty much empty. For example, the class [`TransformBroadcaster`](http://docs.ros.org/latest/api/tf2_ros/html/python/tf2_ros.html#transformlistener) is not documented. Why? Why aren't people putting some effort on the documentation?
Furthermore, there's also the following article http://wiki.ros.org/tf/TfUsingPython, but there's no link from the web page http://wiki.ros.org/tf to it, besides being very poorly written and very incomplete.
↧
↧
What's interpolation and extrapolation in the context of ROS?
In the [FAG](http://wiki.ros.org/tf/FAQ#How_does_tf_deal_with_interpolation_and_extrapolation.3F), it's written
> ### How does `tf` deal with interpolation and extrapolation?
> Our experimentation has shown that interpolation is fine, but extrapolation almost always ends up becoming more of a problem than a solution. If you are having trouble with data being ready before transforms are available I suggest using the `tf::MessageFilter` class in `tf`. It will queue incoming data until transforms are available. Having tried allowing "just a little" extrapolation, waiting for accurate data to be available has proved a much better approach.
First of all, what, in general, is interpolation and extrapolation in the context of ROS? I understood it's something to do with data, but could someone give me a **complete** explanation of these concepts?
Furthermore, the excerpt above states:
> Our experimentation has shown that interpolation is fine
Fine in which sense, to do what? Why is it fine? How does ROS support interpolation? Which experiments did "they" use?
> but extrapolation almost always ends up becoming more of a problem than a solution
Why does extrapolation almost always ends up becoming a problem? And why `tf::MessageFilter` would be a "solution" to extrapolation?
↧
How to get a custom fixed frame with hector_slam?
Hello!
I'm currently using the [slam branch](https://github.com/robopeak/rplidar_ros/tree/slam) of the rplidar_ros package which uses Hector_slam in order to localize a mecanum wheel robot in a room. Since the robot will only need to be inside this room, I would like to fix a reference frame in the middle of the room, but I fail to see how to use the tf package to do so.
I tried creating a fixed frame broadcaster with the wanted origin frame **fixed_map** as parent of the usual **base_link** frame given by the hector_pose_estimation node:
#!/usr/bin/env python
# import roslib
import rospy
import tf
import time
from time import sleep
import math
from geometry_msgs.msg import Pose2D
if __name__ == '__main__':
rospy.init_node('fixed_tf_broadcaster')
br = tf.TransformBroadcaster()
rate = rospy.Rate(10.0)
while not rospy.is_shutdown():
br.sendTransform((0.0, 2.0, 0.0),
(0.0, 0.0, 0.0, 1.0),
rospy.Time.now(),
"base_link",
"fixed_map")
rate.sleep()
and modifing the given launch by commenting the **link1_broadcaster**, creating a new broadcaster called **origin** and changing the **base_frame** parameter by the **fixed_frame** I believe I'm broadcasting:
The result is I can launch the launch file wihtout problem:
SUMMARY
========
PARAMETERS
* /hector_height_mapping/advertise_map_service: True
* /hector_height_mapping/fixed_frame: base_link
* /hector_height_mapping/laser_max_dist: 3.7
* /hector_height_mapping/map_pub_period: 0.5
* /hector_height_mapping/map_resolution: 0.05
* /hector_height_mapping/map_size: 1024
* /hector_height_mapping/map_start_x: 0.5
* /hector_height_mapping/map_start_y: 0.5
* /hector_height_mapping/map_update_angle_thresh: 0.1
* /hector_height_mapping/map_update_distance_thresh: 0.02
* /hector_height_mapping/map_with_known_poses: False
* /hector_height_mapping/odom_frame: base_link
* /hector_height_mapping/output_timing: False
* /hector_height_mapping/pub_map_odom_transform: True
* /hector_height_mapping/scan_topic: scan
* /hector_height_mapping/update_factor_free: 0.45
* /hector_height_mapping/use_tf_pose_start_estimate: False
* /hector_height_mapping/use_tf_scan_transformation: True
* /rosdistro: kinetic
* /rosversion: 1.12.13
* /rplidarNode/angle_compensate: True
* /rplidarNode/frame_id: laser
* /rplidarNode/inverted: False
* /rplidarNode/serial_baudrate: 115200
* /rplidarNode/serial_port: /dev/ttyUSB0
NODES
/
hector_height_mapping (hector_mapping/hector_mapping)
origin (bot/map_tf.py)
rplidarNode (rplidar_ros/rplidarNode)
rviz (rviz/rviz)
auto-starting new master
process[master]: started with pid [3183]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to 5cc94820-2468-11e8-ae56-b827ebc52417
process[rosout-1]: started with pid [3196]
started core service [/rosout]
process[rplidarNode-2]: started with pid [3213]
process[origin-3]: started with pid [3214]
process[hector_height_mapping-4]: started with pid [3223]
process[rviz-5]: started with pid [3233]
RPLIDAR running on ROS package rplidar_ros
SDK Version: 1.5.7
HectorSM map lvl 0: cellLength: 0.05 res x:1024 res y: 1024
HectorSM map lvl 1: cellLength: 0.1 res x:512 res y: 512
HectorSM map lvl 2: cellLength: 0.2 res x:256 res y: 256
[ INFO] [1520689135.328928743]: HectorSM p_base_frame_: base_link
[ INFO] [1520689135.329487337]: HectorSM p_map_frame_: map
[ INFO] [1520689135.329763014]: HectorSM p_odom_frame_: base_link
[ INFO] [1520689135.329990201]: HectorSM p_scan_topic_: scan
[ INFO] [1520689135.330214785]: HectorSM p_use_tf_scan_transformation_: true
[ INFO] [1520689135.330413170]: HectorSM p_pub_map_odom_transform_: true
[ INFO] [1520689135.330544785]: HectorSM p_scan_subscriber_queue_size_: 5
[ INFO] [1520689135.330684785]: HectorSM p_map_pub_period_: 0.500000
[ INFO] [1520689135.330814056]: HectorSM p_update_factor_free_: 0.450000
[ INFO] [1520689135.330958066]: HectorSM p_update_factor_occupied_: 0.900000
[ INFO] [1520689135.331090358]: HectorSM p_map_update_distance_threshold_: 0.020000
[ INFO] [1520689135.331232024]: HectorSM p_map_update_angle_threshold_: 0.100000
[ INFO] [1520689135.331365514]: HectorSM p_laser_z_min_value_: -1.000000
[ INFO] [1520689135.331501139]: HectorSM p_laser_z_max_value_: 1.000000
failed to get the current screen resources
RPLIDAR S/N: C5F5FBF8C5E299F1C4E592F734205B3F
Firmware Ver: 1.20
Hardware Rev: 0
RPLidar health status : 0
QXcbConnection: XCB error: 170 (Unknown), sequence: 163, resource id: 90, major code: 146 (Unknown), minor code: 20
But once the rviz terminal opens, there is an error: **Fixed Frame [map] does not exist** and therefore I can't get the **/scan** topic nor the map. While echoing the **/tf** topic I get the transformation I imposed:
---
transforms:
-
header:
seq: 0
stamp:
secs: 1520688972
nsecs: 640590906
frame_id: "fixed_map"
child_frame_id: "base_link"
transform:
translation:
x: 0.0
y: 2.0
z: 0.0
rotation:
x: 0.0
y: 0.0
z: 0.0
w: 1.0
---
So, I was wondering what's the correct way to set up a custom fixed frame in a map, which doesn't correspond to the initial pose of the robot.
I'm running ROS Kinetic on a ubuntu mate 16.04.4 LTS on a raspberry pi 3.
Thank you!
↧
Start odometry with bias depending on Pose
Hi,
I want to fuse two localization methods, odometry and a PoseWithCovariance sensor.
When the robot "starts" it already has a location and rotation from the PoseWithCovariance sensor (like x=4 and y=3 etc)
But the odometry is (0,0,0, etc), how do I make sure that both systems start at the same position?
Of course, the two coordinates will change and be different from each other as time goes, which is expected. To get an accurate position I'm going to use an EKF from robot_localization. So I don't need a constant transform between the two, just only at the start.
My odometry uses the odom and base_link frames (as the standard) and the Pose messages has the frame_id odom.
What is the best way to do this?
↧
What exactly does it mean to "send a transformation from the child to the parent frame"?
*First of all, I would like to note that I have some background in computer graphics (e.g., I know what homogenous transformations, etc., are). So, please, do not explain to me what matrix multiplications are.*
---
I have a question regarding the `sendTransform` method of the class [TransformBroadcaster](http://docs.ros.org/lunar/api/tf/html/python/tf_python.html#transformbroadcaster).
The documentation says:
> Broadcast the transformation from tf frame child to parent on ROS topic "/tf".
So, e.g., suppose we subscribe to the topic `/turtle1/pose` and, in the callback, we use `sendTransform`, for example
def _send_pose_transform(self, pose):
br = tf.TransformBroadcaster()
translation = (pose.x, pose.y, 0)
rotation = tf.transformations.quaternion_from_euler(0, 0, pose.theta)
br.sendTransform(translation, rotation, rospy.Time.now(),
self.turtle_name, self.parent_frame)
I have at least two questions.
1. The last two arguments of `sendTransform` are the child and parent frames. Can either the child or the parent frames be different than the frame of the object associated with the topic I subscribed to (i.e. `/turtle1/pose`), i.e. can the child or the parent frames be a frame which is not the local frame of `turtle1`? I suppose the answer is "yes", given that I don't see why this use case should be "forbidden".
Now, my actual questions/doubts.
2. What exactly does it mean to **send a transformation from the child to the parent frame**, in this case? What if either the child or the parent frames do not exist in `tf`? Let's now assume that `tf` keeps track of the local frames of the child frame and the parent frame. Does **send a transformation from the child to the parent frame** actually mean that `tf` sends e.g. a homogenous matrix representing the transformation (i.e. rotation and orientation) of a point in the local frame of the child to a point in the local frame of the parent, or is it vice-versa?
3. I know there are plenty of tutorials regarding `tf` and there's also the paper which introduced it. But how does `tf` know how to represent a point in a local frame of a child in the local frame of the child's parent, that is, how does `tf` know the homogeneous transformation matrix? I have seen examples where people do not explicitly specify relationships between e.g. the turtle's local frame and the world. In this case, it's pretty obvious that `tf` can figure out the transformation, but what if I wanted to add a custom and explicit relationship between an existing frame and a new frame? After briefly reading the tutorial [http://wiki.ros.org/tf/Tutorials/Adding%20a%20frame%20%28Python%29](http://wiki.ros.org/tf/Tutorials/Adding%20a%20frame%20%28Python%29), it looks like we can define such new frames by explicitly broadcasting/sending to the `tf` topic the transformation which explicitly defines the relationship between the frames. Is this correct?
3. How does `tf` define the local frame of new objects?
↧
↧
No transform to fixed frame [odom]
I have launched Gazebo with URDF model of wheeled robot. Robot and joint state publishers have launched too. The odometry topic is published by gazebo with header.frame_id = odom, child_frame_id = base_link. But RViz shows that there is no transform to fixed frame [odom]. Here is tf tree from frames.gv:
"map" -> "odom"
"base_footprint" -> "base_link"
"base_link" -> "camera_link"
"base_link" -> "hokuyo_link"
"base_link" -> "wheel_1"
"base_link" -> "wheel_2"
"base_link" -> "wheel_3"
"base_link" -> "wheel_4"
What should I do to fix it?
↧
"Debugging tf problems" tutorial not working for me
ROS Kinetic & Ubuntu 16.04
The tutorial about debugging /tf has some major issues, or my brain does. Probably the latter. (http://wiki.ros.org/tf/Tutorials/Debugging%20tf%20problems)
First, I start the `start_debug_demo.launch` file. A turtle sim comes up, with a live and dead turtle, and a
"turtle3" passed to lookupTransform argument target_frame does not exist
error, as expected. Except my error looks like
"turtle3" passed to lookupTransform argument target_frame does not exist.
My first clue.
In `learning_tf /src` I create the `turtle_tf_listener.debug.cpp` file. Somehow the tutorial also forgets to mention that I need to put `add_executable(...)` in the `CMakeLists.txt` . But I put it in.
I'm not sure why it's expected that this cpp would erase the error. The error existed before the creation of this `turtle_tf_listener_debug.cpp` file. It's clear this cpp file is completely unattached to the launch file.
According to the tutorial, you mention "turtle3" in this cpp file. Then you change it to "turtle2" and hooray, the "turtle3 doesn't exist" error is gone. Except, no it isn't. I already put "turtle2" in this cpp file. Doesn't change the error. As expected, the start_debug_demo.launch is not in contact with this cpp file. I investigate:
I go to `$roscd turtle_tf` to look inside. Doesn't have /src or /nodes. Just /rviz and /cmake and /launch.
I look inside `/opt/ros/kinetic/share/turtle_tf/launch` which has the `start_debug_demo.launch`. I open it with gedit.
Sure enough, it doesn't even mention `learning/tf/src` 's cpp file. If I change it to
I do the catkin_make, the source bash, re-run roscore, and try again, I still get errors about "turtle3" not existing. But where am I mentioning "turtle3"? Not in the launch file. Not in the cpp file for the nodes. And there's no alternative turtle_tf_listener_debug.cpp files that I can find. Only the one I created. `Rqt_graph` doesn't show any "turtle3". `view_frames` of course doesn't show any "turtle3" either.
According to the tutorial, I should be witnissing timestamp errors now. But I'm still getting turtle3 errors. What did I do wrong?
↧
RViz error:Transform [sender=unknown_publisher] - For frame [X]: Frame [X] does not exist
[ROS Kinetic, Ubuntu 16.04]
Hello, I have a problem with sensor frames in rviz. I have created a static trasform broadcaster that publishes all static transforms of my robot (did it according to http://wiki.ros.org/tf2/Tutorials). Map->odom tf is created temporarily as static, until I integrate some SLAM module. Now map and odom coordinate systems are placed in the same position. Odom->base link is published by ros_controllers node.
The tf tree looks as follows:

However when I start a visualization in rviz I can't see any sensor_msgs::Range data (from any of my 3 sonars) but I can choose corresponding topics. Rviz shows error (example, shows similar for other sonars):
"**Transform [sender=unknown_publisher] - For frame [base_sonarF]: Frame [base_sonarF] does not exist**".

I am really confused as you can see on the tf_tree that the system recognizes transforms I'm publishing. Is it rviz error or I did something wrong? In my URDF file I didn't create any joints for sonars, only for wheels and base, if that matters. When I'm echoing sonar topics everything seems to be right, especially distances from obstacles.
I've found same issue in other questions but none of the solutions worked (like adding marker in rviz, making sonar's frame a fixed frame).
Thanks in advance.
↧