ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

How to Adjust Turtlebots odometry manually ?

asked 2012-01-26 10:16:56 -0500

Atom gravatar image

updated 2012-01-27 04:19:46 -0500

I would like to adjust the encoder information coming from my turtlebot so that it is accurate for building maps in gmapping, etc. Im trying to build a better robot base without having to reinvent the wheel, as I am very pleased with turtlebots performance over all. So basically I am fitting custom wheels(5X larger) and motors to a larger robot base but would still like to use the create with encoders and base sensors (create base still onboard the robot). I would add the creates encoders to the new shafts but instead of using gears to tune the create encoders to turtlebot specs I figured it would be easier to adjust the code. Is this possible manually , if so where should I start to play with the numbers? ,Turtlebot_node ..

self.odom_angular_scale_correction = rospy.get_param('~odom_angular_scale_correction', 1.0) self.odom_linear_scale_correction = rospy.get_param('~odom_linear_scale_correction', 1.0) ??

Also theoretically might turtlebot calibration work for this task aswell, along with some manual fine tuning of the code? I would like to understand this a bit better before breaking down the create base.. Thanks for viewing

I thought this might be a simple hardware hack to get bigger motors and wheels to carry larger payloads. I know the creates encoders might not be the most accurate but I have found them to be reliable for my needs. Maybe later I could try writing a new set of code to a new more advanced base.

edit retag flag offensive close merge delete

Comments

I'm also aware that the the dimensions of turtlebot might be comprimised leading to unaccuate mapping and navigation as the dimensions of the urdf in rviz might be smaller in comparison to my new hybrid turtlebot. But This is the first step and would deal with issues as they arose..
Atom gravatar image Atom  ( 2012-01-26 10:25:36 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
0

answered 2012-03-01 15:56:39 -0500

Atom gravatar image

updated 2012-03-01 15:59:35 -0500

I figured out that in order to get Turtlebot to move in rviz relative to my predefined speed set on my motor control, I had to play with the keyboard_teleop.launch parameters to match my actual speed emulated in rviz. My speed was faster than the stock turtlebot speed so I reduced my parameters from

param name="scale_linear" value="1.0" type="double"/ param name="scale_angular" value="1.0" type="double"/ to

param name="scale_linear" value="0.2" type="double"/ param name="scale_angular" value="0.2" type="double"/

this worked for me ...

edit flag offensive delete link more
1

answered 2012-01-27 02:49:12 -0500

The parameters you mention for odometry scale correction are probably the least of your worries until you have a working base platform. The turtlebot_node package is heavily dependent on the turtlebot_driver package which is essentially an iRobot Create/Roomba SCI/OI driver. What you propose is to replace the iRobot Create with essentially a custom base platform.

What you'll find is that there's not much code to reuse from turtlebot_node outside of parts of the "compute_odom" method and possibly a few others (maybe gyro.py if you're using the same gyro?). The code for interfacing with the analog and digital IOs will have to change, as well as the code for bumpers, batteries and "safe"/"passive"/"full" modes.

Of course once you have all the low-level drivers re-implemented for whatever motor controller/encoder package you choose, nothing stops you from outputting compatible messages like Odometry and BatteryState, etc that would allow you to work with other sections of the turtlebot stack. You can even reuse-the calibration node since there's nothing particularly turtlebot-specific about it--then you can incorporate those scaling parameters into your new driver node. Unfortunately, replacing the Create means rewriting the code to interface with Twist and Odometry messages (most of turtlebot_driver and turtlebot_node).

edit flag offensive delete link more

Comments

Actually I still plan to use the complete icreate base parts(motherboard sensors ect) complete with the gyro on my robot would just be adding a arduino and motor driver to the base utilizing the original icreates encoders by removing them from icreate base.
Atom gravatar image Atom  ( 2012-01-27 03:30:36 -0500 )edit
I would then write a python script to subscribe to cmd_vel to tell my motor driver to move motors in the proper direction. Sounds like a lot of physical hardware hacking but this seems to me an easier approach for me. So to clarify my original question which parameter would adjust how turtlebot
Atom gravatar image Atom  ( 2012-01-27 03:38:54 -0500 )edit
would interpret the scale of encoder movement in relation the the distance traveled in a map. Thanks agian for the reply I know this might sound strange to people how could easily write code for a new base but I am not the most advanced programmer yet... :)
Atom gravatar image Atom  ( 2012-01-27 03:40:31 -0500 )edit
Ah, ok. Having taken apart a Create before, I can say that there are a lot of passive components and single-package transistors that without a lot of reverse engineering may be hard to separate out their functionality. It honestly may be less work to "reinvent the wheel" (almost literally) here.
JeffRousseau gravatar image JeffRousseau  ( 2012-01-27 03:40:36 -0500 )edit
Could you describe in an update of your original post the reasoning behind this hardware hack--I've somehow lost the initial purpose. What does an arduino-based motor hack gain you over the stock create's? Especially with using the same crappy encoders?
JeffRousseau gravatar image JeffRousseau  ( 2012-01-27 03:42:44 -0500 )edit
It should be noted that odometry drifts, even with expensive motor controllers/encoders--hence odometry isn't used "for building maps". Instead you should be using something like AMCL or gmapping which takes into account sloppy encoders and drift.
JeffRousseau gravatar image JeffRousseau  ( 2012-01-27 03:49:34 -0500 )edit
Right I use the gmapping, AMCL nodes, and understand it updates the position based on a laser scan. That's why I thought that my hack would translate well.
Atom gravatar image Atom  ( 2012-01-27 03:58:05 -0500 )edit

Thanks for the help Jeff...

Atom gravatar image Atom  ( 2012-03-01 16:09:05 -0500 )edit

Question Tools

Stats

Asked: 2012-01-26 10:16:56 -0500

Seen: 2,404 times

Last updated: Mar 01 '12