kilmarnock's profile - activity

exchange "Sophus" with "sophus" in any CMakeLists.txt file did it for me

+1, man. This leads to unexpected search paths and tears.

Thank you. My mom did not tell me about name demanglers.

I can confirm ahendrix answer:

simply adding tf2 tf2_ros to the find_package statement did the trick. It would be interesting how ahendrix could find this out.

No, it did not. The rotating frame is a phenomenon I also observe when using robot_localization. It must have to do something with NED/ENU conversion which I must admit I do not understand.

Just for the records: The current answer (6/2015) would be:

Install this image: http://forum.odroid.com/viewtopic.php...

compile ('org.ros.rosjava_core:rosjava:[0.1,0.2)'){ exclude group: 'junit' exclude group: 'xml-apis', module: 'xml-apis' }

to add the lines above did help me now (AS 0.8.x, Gradle 1.12)

Hi @All

I am using hector_pose_estimation and imu_um6. The result is a slowly but constantly rotating tf frame. Has anyone tried this and what are your experiences? Is this the result of drifting values (poor IMU performance) or the result of an assumption in the ekf code or my setup? I would bet that Mr. K. and Mr. M of team hector are using another IMU? Why does the frame not become stable?

If I use hector_imu_attitude_to_tf, I get a near-realistic behaviour with the tf node having a tendency to drift back to normal, but no rotation as in the case described before.

Will the pose of hector_pose_estimation ever become stable with my setup?

Thank you Felix

P.S.:

I paste my launch config here in case of my setup is wrong:

<include file="$(find imu_um6)/normal.launch" /> 
<node pkg="hector_pose_estimation" type="pose_estimation" name="pose_estimation">
            <remap from="raw_imu" to="imu/data"/>
            <remap from="magnetic" to="imu/mag"/>
            <param name="pose" value="false"/>
            <param name="nav_frame" value="map"/>
            <param name="footprint_frame" value="fp"/>
            <param name="stabilized_frame" value="sf"/>
            <param name="base_frame" value="bf"/>
            <param name="with_covariances" value="false"/>
            <param name="position_frame" value="ps"/>
            <param name="publish_world_map_transform" value="false"/>
            <param name="world_frame" value="world"/>
            <param name="map_frame" value="map"/>
          </node>

Hi @All

I am using hector_pose_estimation and imu_um6. The result is a slowly but constantly rotating tf node. Has anyone tried this and what are your experiences? Is this the result of drifting values (poor IMU performance) or the result of an assumption in the ekf code or my setup? I would bet that Mr. K. and Mr. M of team hector are using another IMU? Why does the frame not become stable?

If I use hector_imu_attitude_to_tf, I get a near-realistic behaviour with the tf node having a tendency to drift back to normal, but no rotation as in the case described before.

Will the pose of hector_pose_estimation ever become stable with my setup?

Thank you Felix

P.S.:

I paste my launch config here in case of my setup is wrong:

<include file="$(find imu_um6)/normal.launch" /> 
<node pkg="hector_pose_estimation" type="pose_estimation" name="pose_estimation">
            <remap from="raw_imu" to="imu/data"/>
            <remap from="magnetic" to="imu/mag"/>
            <param name="pose" value="false"/>
            <param name="nav_frame" value="map"/>
            <param name="footprint_frame" value="fp"/>
            <param name="stabilized_frame" value="sf"/>
            <param name="base_frame" value="bf"/>
            <param name="with_covariances" value="false"/>
            <param name="position_frame" value="ps"/>
            <param name="publish_world_map_transform" value="false"/>
            <param name="world_frame" value="world"/>
            <param name="map_frame" value="map"/>
          </node>

I am using another armhf board and the error message is the same. I would be interested in an answer that helps building rviz. Sorry for not using the commenting tool, I cannot see (use) it.

I tried to generate a .PLY file by GUI. It stores as a pcd file:

head /mnt/temp/rgbdslam.ply

.PCD v.7 - Point Cloud Data file format

VERSION .7 FIELDS x y z _ rgb _ SIZE 4 4 4 1 4 1 TYPE F F F U F U COUNT 1 1 1 4 1 12 WIDTH 1 HEIGHT 5948210 VIEWPOINT 0 0 0 1 0 0 0 POINTS 5948210

I have a related question:

I used your hector_imu_attitude_to_tf node. rxgraph shows that the node publishes to hector_mapping as expected. The visualization of the laser scan however does not react to the imu messeages. Should it show some pitch/roll influence or is there another way to control the influence of imu messages on the mapping process?

Thank you Felix

I have a related question:

I used your hector_imu_attitude_to_tf node. rxgraph shows that the node publishes to hector_mapping as expected. The visualization of the laser scan however does not react to the imu messeages. Should it show some pitch/roll influence or is there another way to control the influence of imu messages on the mapping process?

Thank you Felix

Here, the problem is still here. I tried the followin versions, doing a clean checkout after each try, deleting ~/.ros, /opt/ros/electric/java, ~/ros_workspace/java with all of the following versions (64bit):

0 /usr/lib/jvm/java-6-openjdk/bin/javac
1 /usr/lib/jvm/java-6-openjdk/bin/javac
2 /usr/local/jdk1.6.0_25/bin/javac
3 /usr/local/jdk1.6.0_29/bin/javac
* 4 /usr/local/jdk1.6.0_30/bin/javac

but no success. What can I do? Felix