0
$\begingroup$

Rosanswers logo

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.


Originally posted by Atom on ROS Answers with karma: 458 on 2012-01-26

Post score: 0


Original comments

Comment by Atom on 2012-01-26:
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..

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

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).


Originally posted by JeffRousseau with karma: 1607 on 2012-01-27

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by Atom on 2012-01-27:
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.

Comment by JeffRousseau on 2012-01-27:
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.

Comment by JeffRousseau on 2012-01-27:
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?

Comment by JeffRousseau on 2012-01-27:
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.

Comment by Atom on 2012-01-27:
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... :)

Comment by Atom on 2012-01-27:
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

Comment by Atom on 2012-01-27:
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.

Comment by Atom on 2012-03-01:
Thanks for the help Jeff...

$\endgroup$
0
$\begingroup$

Rosanswers logo

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 ...


Originally posted by Atom with karma: 458 on 2012-03-01

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

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