0
$\begingroup$

Rosanswers logo

I have some problems building a map with my Turtlebot. I run the calibration (0.85 for the gyro and 0.93 for odom) multiple times and followed the instructions in the tutorials for starting gmapping. The map looks like a set of scans scattered around, also the orientation shown in rviz is not consistent with where the robot is going.

To me it seems like there is either a problem with the odometry/gyro or the localization is not working properly. The gyro seems to work (I see the values changing when rotating), do I need to change anything in the config files (except the odo/gyro cal values)? I should also mention that I am using all the turtlebot hardware except the Kinect mounting hardware. I made my own mounting pole but the kinect is located approximately at the same place as with the standard turtlebot.

As recommended I did the tests in http://www.ros.org/wiki/navigation/Troubleshooting and it seems like there is something wrong with the odometry, but only while turning, moving straight seems to be fine. The gyro seems to output good values (see plots) and the calibration was done multiple times. Have a look at the following link for a few screenshots and some more details.

https://picasaweb.google.com/109216537228630118124/TurtlebotSLAM?authuser=0&authkey=Gv1sRgCPTsg_Wh7fuqZw&feat=directlink

I did a 180 degree turn and the /odom orientation (yaw) measured 176.8 degrees, however the /robot_pose_ekf/odom orientation (yaw) measured only 60.4 degrees. So that leads me to believe it is either the gyro or something wrong with the EKF.

Also, following is the calibration output (removed a few repeated lines to make the post shorter):

[INFO] [WallTime: 1324939496.895343] ... imu drift is -0.621943 degrees per second

[INFO] [WallTime: 1324939497.197380] Still waiting for imu

[INFO] [WallTime: 1324939497.499277] Still waiting for scan

[INFO] [WallTime: 1324939497.801215] Aligning base with wall

[INFO] [WallTime: 1324939498.103249] Still waiting for imu

[INFO] [WallTime: 1324939498.405232] Still waiting for scan

[INFO] [WallTime: 1324939545.778987] Odom error: 2.295941 percent

[INFO] [WallTime: 1324939545.780867] Imu error: -32.801991 percent

[INFO] [WallTime: 1324939546.090230] Still waiting for imu

[INFO] [WallTime: 1324939546.392098] Still waiting for scan

[INFO] [WallTime: 1324939546.996119] Aligning base with wall

[INFO] [WallTime: 1324939548.270806] Still waiting for imu

[INFO] [WallTime: 1324939548.573036] Still waiting for scan

[INFO] [WallTime: 1324939560.870167] Odom error: -11.098675 percent

[INFO] [WallTime: 1324939560.872639] Imu error: 19.686330 percent

[INFO] [WallTime: 1324939561.178241] Still waiting for imu

[INFO] [WallTime: 1324939561.480022] Still waiting for scan

[INFO] [WallTime: 1324939561.782138] Aligning base with wall

[INFO] [WallTime: 1324939565.640311] Still waiting for imu

[INFO] [WallTime: 1324939565.942336] Still waiting for scan

[INFO] [WallTime: 1324939573.806552] Odom error: 6.987265 percent

[INFO] [WallTime: 1324939573.808156] Imu error: 35.610160 percent

[INFO] [WallTime: 1324939574.111180] Still waiting for imu

[INFO] [WallTime: 1324939574.413042] Still waiting for scan

[INFO] [WallTime: 1324939574.715408] Aligning base with wall

[INFO] [WallTime: 1324939577.046587] Still waiting for imu

[INFO] [WallTime: 1324939577.348471] Still waiting for scan

[INFO] [WallTime: 1324939583.397927] Odom error: 5.578208 percent

[INFO] [WallTime: 1324939583.399454] Imu error: 33.676770 percent

[INFO] [WallTime: 1324939583.400816] Multiply the 'turtlebot_node/gyro_scale_correction' parameter with 0.876864

[INFO] [WallTime: 1324939583.404168] Multiply the 'turtlebot_node/odom_angular_scale_correction' parameter with 0.990681

Originally posted by Vassilis on ROS Answers with karma: 96 on 2011-12-23

Post score: 3

Original comments

Comment by Vassilis on 2011-12-27:
Yes, I am using electric as well. I am going through the code to understand what is going on a bit more.

Comment by Nick Armstrong-Crews on 2011-12-27:
+1: similar issue. I switched to using laser_scan_matcher instead of robot_pose_ekf, which works better but not better enough :/ A colleague reported the gyro output to contain a sign error? I have yet to verify. I also wonder if this issue is specific to electric... is that what you're using?

Comment by Vassilis on 2011-12-27:
I compared the /odom and the /robot_pose_ekf/odom topics and I see a large error in the output of the EKF filter. See the revised question for more details.

Comment by Vassilis on 2011-12-27:
When I execute "rosparam get /turtlebot_node/gyro_scale_correction" I get the right value.

Comment by dornhege on 2011-12-26:
My only guess would be that "Multiply the 'turtlebot_node/gyro_scale_correction' parameter with 0.876864" didn't happen or not where it's supposed to be.

Comment by Vassilis on 2011-12-26:
The laser scans are all over the place with the delay on, I do agree there seems to be something wrong with the gyro. I got the Turtlebot sensor/power board last week, so I am not sure what to expect out of the gyro. Maybe somebody with a similar setup can have a look at the IMU plots?

Comment by dornhege on 2011-12-26:
I'm not familiar with the turtlebot imu, but for Imu error reported above seems quite high to me. Maybe some of the turtlebot guys know what the problem might be.

Comment by dornhege on 2011-12-26:
If picture 1 and 2 are from the same run before/after one rotation, then the gyro seems to be the problem, given that the graphs look OK. How does it look with the decay enabled, are the laserscans smeared over the rotation?

Comment by Vassilis on 2011-12-26:
Done, please have a look at the revised question for the details. Thanks!

Comment by dornhege on 2011-12-23:
Can you do the three tests under 1. here: http://www.ros.org/wiki/navigation/Troubleshooting ? If they go fine and the laserscans look OK, then everything should be setup OK on the robot side.

Comment by Vassilis on 2011-12-23:
Yes that was done.

Comment by mmwise on 2011-12-23:
did you edit the turtlebot.launch file in etc to store the calibration values and then restart the turtlebot service?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
0
$\begingroup$

Rosanswers logo

It seems like I am getting much better odometry when setting turtlebot_node/gyro_scale_correction to 2.55 instead of 0.876864 that is recommended by the odometry calibration.

Not sure if this is normal!

Originally posted by Vassilis with karma: 96 on 2011-12-27

This answer was NOT ACCEPTED on the original site

Post score: 2

Original comments

Comment by tfoote on 2012-01-01:
Ticketed https://kforge.ros.org/turtlebot/trac/ticket/111

Comment by Nick Armstrong-Crews on 2011-12-27:
+1: setting the value to 2.5 works well for me, although the calibration tells me to set it to .85 (multiplier for the original value, 1)

Comment by 130s on 2011-12-27:
Not sure enough but if configuring gyro upon calibration is the root cause, that's what I faced with mapping on turtlebots. In addition to tutorials & FAQ about turtlebot's calibration, see also http://answers.ros.org/question/3088/turtlebot-calibration-returns-absolute-parameters

Comment by dornhege on 2011-12-27:
It says: "Multiply by" - might that be the mistake?

Improve this answer
$\endgroup$
0
$\begingroup$

Rosanswers logo

I think I figured this out! My sensor/power board has the ADXRS620 gyro and not the ADXRS613, the big difference is that ADXRS613 has a +/- 150deg/s output and the ADXRS620 has a +/- 300 deg/s output. This is important because for the same angular speed the raw outputs will differ by a factor of two.

Also looking at turtlebot_node/src/turtlebot_node/gyro.py the raw signal from the analog input is multiplied by 150 to convert to deg/sec, when I changed it to 300 it worked fine with the values recommended by the calibration.

One problem with the higher rate sensor is that the resolution is now halved. As a result I noticed that the drift is very high even with the robot stationary. I added a short averaging filter on the analog input in gyro.py and it helped a lot but I need to experiment with this a bit more.

To fix this the gyro type could be defined as a parameter of turtlebot_node. I would be happy to fix this myself if I can get access to commit code.

Originally posted by Vassilis with karma: 96 on 2011-12-27

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by mmwise on 2011-12-29:
if the calibration value if off by a large enough value the calibration routine will not measure the proper value. multiply by two and then run calibration again and I suspect you will get proper results

Comment by Nick Armstrong-Crews on 2011-12-28:
nice work tracking that down. in theory, adjusting params for the EKF would work more reliably than averaging filter...

Comment by dornhege on 2011-12-28:
I think the developers will appreciate a patch!

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.