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.
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 ...
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).
Asked: Jan 26
Seen: 168 times
Last updated: Mar 01
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
