ateator's profile - activity

I found that my question was not stated correctly. Restated, it would be: I have Local Rotation Axis of all the joints a

I found that my question was not stated correctly. Restated, it would be: I have Local Rotation Axis of all the joints a

• Ubuntu 18.04
• ROS2 Eloquent
• C++
• TF
• KDL
• URDF
• robot_state_publisher (but the Foxy version!)

Setup

I am running ROS2 Eloquent, but I copied the Foxy version of the robot_state_publisher from github to use in my own project. Inside robot_state_publisher (Foxy version!) I learned how to use setupURDF(...) to transform my URDF file into a URDF::Model, and subsequently copy the Joints from that Model into a MimicMap. This MimicMap is used inside the JointState callback and ultimately end up at publishTransforms. In short, the URDF Model and JointStateMsg (sensor_msgs::msg::JointState) are used to populate at a TransformStampedMsg (geometry_msgs::msg::TransformStamped), which is published for anyone to use. I can see that a bulk of the magic is done with the KDL namespace, which manages the tree, segments, joints, links, plus more, and allows us to get poses of a segment based on the current joint position.

Question

Is there a way for me to get 'live' (or Global) Joint Axis pose (with the applied joint_positions) using functions already provided to me by KDL or another ROS library? If not, how do I apply my joint rotations to the segments so that I can calculate the Forward Kinematics for the Axis of Rotation for each joint?

I found that my question was not stated correctly. Restated, it would be: I have Local Rotation Axis of all the joints a

I am looking for information on how to get the orientation for the Joint Axis (or Axis of Rotation for the associated jo

I don't have any problem with ROS2, my system, my package or the robot_state_publisher node itself. My system works exac

At first, I was trying to understand the usage of joint_state_publisher and robot_state_publisher, so I investigated the

At first, I was trying to understand the usage of joint_state_publisher and robot_state_publisher, so I investigated the

At first, I was trying to understand the usage of joint_state_publisher and robot_state_publisher, so I investigated the

I don't have any problem with ROS2, my system, my package or the robot_state_publisher node itself. My system works exac

At first, I was trying to understand the usage of joint_state_publisher and robot_state_publisher, so I investigated the

ROS2 Eloquent - KDL - How do I get 'live' (Global) Joint Axis information? Ubuntu 18.04 ROS2 Eloquent C++ TF KDL URDF r

ROS2 Eloquent - KDL - How do I get 'live' (Global) Joint Axis information? Ubuntu 18.04 ROS2 Eloquent C++ TF KDL URDF r

I haven't figured out the exact answer but I believe the problem is in my CMakeLists.txt. I built a new minimal project

I have created a minimal reproducible package and the issue has resolved. I will be doing more research and will update

The behavior on /tf is as expected, no freezes or anything. I have use_tf_static set to false, so the /tf_static topic d

The behavior on /tf is as expected, no freezes or anything. I have use_tf_static set to false, so the /tf_static topic d

The behavior on /tf is as expected, no freezes or anything. I have use_tf_static set to false, so the /tf_static topic d

The behavior on /tf is as expected, no freezes or anything. I have use_tf_static set to false, so the /tf_static' topic

ROS2 Eloquent TF listener (tf_echo) values freeze/resume on a cycle unexpectedly Ubuntu 18.04 ROS2 Eloquent TF C++

ROS2 Eloquent TF listener (tf_echo) values freeze/resume on a cycle unexpectedly Ubuntu 18.04 ROS2 Eloquent TF C++

ROS2 Eloquent TF listener (tf_echo) values freeze/resume on a cycle unexpectedly Ubuntu 18.04 ROS2 Eloquent TF C++

ROS2 Eloquent TF listener (tf_echo) values freeze/resume on a cycle unexpectedly Ubuntu 18.04 ROS2 Eloquent TF C++

ROS2 Eloquent TF listener (tf_echo) values freeze/resume on a cycle unexpectedly Ubuntu 18.04 ROS2 Eloquent TF C++ M

bump. I would also like this comment answered

Hey there, I am creating my own package with Boost, and I have a .cpp file that is able to compile using g++ with:

g++ newboost.cpp -o boost -lboost_system -lpthread

But, when I try to put the .cpp file into my package and catkin_make my package, I get the following error:

/usr/bin/ld: CMakeFiles/keyencelaser_node.dir/src/newboost.cpp.o: undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
keyencelaser/CMakeFiles/keyencelaser_node.dir/build.make:95: recipe for target '/home/ateator/catkin_ws/devel/lib/keyencelaser/keyencelaser_node' failed
make[2]: *** [/home/ateator/catkin_ws/devel/lib/keyencelaser/keyencelaser_node] Error 1
CMakeFiles/Makefile2:4463: recipe for target 'keyencelaser/CMakeFiles/keyencelaser_node.dir/all' failed
make[1]: *** [keyencelaser/CMakeFiles/keyencelaser_node.dir/all] Error 2
Makefile:138: recipe for target 'all' failed

which is a similar error to the one I got before adding the flags onto the g++ terminal command

I have tried to add Boost into my CMakeLists.txt, but (although it did improve my errors), I am still left with the above errors. My CMakeLists.txt is:

find_package(catkin REQUIRED COMPONENTS
  roscpp

)
find_package(
  Boost
  REQUIRED COMPONENTS system thread
)
include_directories(
  ${catkin_INCLUDE_DIRS}
)
 add_executable(keyencelaser_node src/newboost.cpp)
 target_link_libraries(keyencelaser_node
   ${Boost_FILESYSTEM_LIBRARIES}
   ${Boost_SYSTEM_LIBRARY}
 )

I am pretty sure it's a linker error but I don't know how to fix it. Again, the edits I made to my CMakeLists.txt eliminated a lot of "undefined reference to" errors, but now that those are gone, I am left with the above. I appreciate any and all help.

Thank you.

I have a LaserScan node "keyencelaser" that is publishing on the topic "scan" with frame "laser_frame"

  ros::init(argc, argv, "keyencelaser_publisher");
  ros::NodeHandle n;
  ros::Publisher scan_pub = n.advertise<sensor_msgs::LaserScan>("scan", 50);
  (...)
  scan.header.frame_id = "laser_frame";

My launch file currently looks like:

<launch>


<node pkg="keyencelaser" type="keyencelaser_rosnode" name="keyencelaser" />
<node pkg="tf" type="static_transform_publisher" name="odom_to_base_link" args="0.0 0.0 0.0 0 0 0.0 /odom /base_link 100"/>
<node pkg="tf" type="static_transform_publisher" name="base_link_to_laser_link" args="0.0 0.0 0.0 0 0 0.0 /base_link /laser_frame 100"/>
<param name="pub_map_odom_transform" value="false"/>
<param name="map_frame" value="map" />
<param name="base_frame" value="base_link" />
<param name="odom_frame" value="base_link" />
<node pkg="hector_mapping" type="hector_mapping" name="hector_mapping" output="screen">
  <param name="use_tf_scan_transformation" value="true" />
  <param name="use_tf_pose_start_estimate" value="false" />
  <param name="map_resolution" value="0.050" />
  <param name="map_size" value="2048" />
  <param name="scan_subscriber_queue_size" value="5" />
  <param name="scan_topic" value="scan" />
  <param name="tf_map_scanmatch_transform_frame_name" value="scanmatcher_frame" />
</node>
</launch>

But I throw this error once I use my launch file:

[ INFO] [1482419456.331809455]: lookupTransform base_link to laser_frame timed out. Could not transform laser scan into base_frame.
Check failed in file /usr/include/boost/numeric/ublas/matrix_expression.hpp at line 2007:
size1 == size2
terminate called after throwing an instance of 'boost::numeric::ublas::bad_argument'
  what():  bad argument

Can someone please help me figure this out? I have tried multiple combinations but can't quite get it.

Hello everyone,

I have a hardware setup which consists of a Keyence SZ-V LiDAR and a Razor 9-DOF IMU. There is no real robot, I just have the two sensors somewhat attached so that I can move them at the same time with one motion. I wrote my own first laser driver node to poll the laser and produce a sensor_msgs::LaserScan with the frame_id as "base_link". No issue there. I then have a second node which uses message_filters::Synchronizer to tf transform the LaserScan into a 3D sensor_msgs::PointCloud2 that is rotated by the IMU orientation with frame_id "laser_link". No issue there. I then have a third node which listens for these sensor_msgs::PointCloud2, converts them to pcl::PointCloud2, adds 20 of them, converts them back to sensor_msgs::PointCloud2 and then publishes that larger point cloud.

Here is the issue: because the rotation is caused by a tf transform, the rotation is not seen in the combined cloud when I move the IMU. If I turn the laser alone, the combined cloud is as expected and shows some old points as well as the changed ones (not rotated). If I turn the IMU alone, the rotation is seen in the second node (Laser+IMU) but in the third node I just see a something that looks like my 20 scans stacked on top of each other, but rotated by the IMU orientation. I would expect to see several clouds at intermittent positions between the start and end rotation positions.

I have tried changing the frame_id of this combined cloud to both "base_link" and "laser link" to see if I could grab the rotated cloud when combining the clouds, but neither of these worked. I mean, this error makes sense because I'm never really getting the rotated values into my third node. How do I correctly get these transformed clouds into my third node so that I can collect several clouds together whether the changes are seen in either the LaserScan or IMU?

EDIT: Better late than never.. my objective with this combined 3D point cloud is to get a 3D SLAM going. I'm aiming for ethzasl_icp_mapper as my SLAM algo but it seems that it needs more than just single scans as an input. That's why I'm trying to produce a larger cloud. I want to give it more points to extract data from. I've also looked at loam_back_and_forth but since it's now commercial that's out. I've also looked at BLAM! but there was so many issues trying to get it and it's dependencies installed that I gave up. I forgot the exact errors there....