Fabian Saccilotto's profile - activity

I am trying the same. But actually I can produce a quite good map with gmapping but when I connect the pointcloud to octomap as you do it, the octomap has a lot of artefacts from the situations were the robot's position inside the map is not correct. Did you have this problem too?

With my robot, I had the problem that some launch files were not correct in fuerte.

turtlebot_teleop/app/android_*.launch

For aquiring the map, I had to install ros-fuerte-map-store too. For navigating the map I changed the node type in android_map_nav.launch from map_loader to map_manager

-  <node pkg="map_store" type="map_loader" name="map_manager" output="screen"/>
+  <node pkg="map_store" type="map_manager" name="map_manager" output="screen"/>

Maybe this question could help: http://answers.ros.org/question/51865/how-to-get-the-topics-data-from-kinect/

I am using openni_launch to start my kinect. Per default it publishes a lot of topics (IR, Depth, RGB in mono, rectified, registered, compressed, theora versions).

I would be interested if it is possible to disable the unused topics per launch file to increase performance? Or is it necessary to change the sources?

Thanks in advance

I had the same installation configuration: Ubuntu 12.04 LTS on the workstation and 10.04 on the turtlebot. I also had a lot of problems setting the system up. Most of all wireless connection losses and Problems starting the kinect.

I got the system to work when I used the (non-clearpath) ros-fuerte-turtlebot packages. I didn't test the clearpath packages. I started my kinect with

roslaunch turtlebot_bringup kinect.launch

as far as I know, this will start the deprecated Openni nodelets.

The green light on the kinect is flashing as soon you plug into usb, but this is no indication whether there is enough power... The breaker 1 on the dashboard has to be on.

Sometimes it helped me when I stopped/started the turtlebot service.

sudo service turtlebot stop

sudo service turtlebot start

ATTENTION:

sudo service turtlebot restart doesn't work

Since a few days new apt repositories for ros-fuerte-turtlebot are available. I upgraded both systems and kinect as well as gmapping works. With this configuration you can start the kinect via openni_launch

For the battery problem you can use the solution here: http://answers.ros.org/question/30631/turtlebot-unable-to-check-laptop-batterybat0state/

You create an overlay package for this, to keep the apt-packages unchanged. If you have questions to this, just ask. It is different for electric and fuerte and it took me some time to figure out.

My robot still isn't aligned precise to the wall but I found another method to check whether the calibration was successfull: http://www.ros.org/wiki/navigation/Tutorials/Navigation%20Tuning%20Guide Chapter 2.2 Odometry

(RVIZ) If you rotate your bot with a high decay time of laser scan data, the displayed points should be approximately at the same place.

When the robot aligned quite well during the calibration the result was acceptable.

Thanks for that hint. I have other obstacles behind my turtlebot and will try it in a bigger room.

Yes, I set it to 250 according to clearpath.

Hi all, I recognized that the odometry of my turtlebot didn't work correctly. Therefore I rerun the calibration procedure http://www.ros.org/wiki/turtlebot_calibration/Tutorials/Calibrate%20Odometry%20and%20Gyro (Calibration Tutorial).

When I calibrated the first time, I considered the calibration successfull when the robot stopped again facing the wall perpendicular.

Then I read the Tutorial again:

If the TurtleBot does not successfully return to facing the wall before executing the next rotation the data will be incorrect. This can be caused by too big of an error in the existing parameters. If it under rotates, increase the odom parameter and retry. If it over rotates, lower the odom_parameter and retry.

When I got the turtlebot to face the wall correctly during the procedure, it wasn't at the end and vice versa. (The factor proposed by the calibration would work opposite the statement of the tutorial - Overrotating and a factor greater 1)

Therefore my question is: Is the stop at the end of the procedure also important? Am I doing something wrong?

Another probably important information: I changed the position of the kinect on the turtlebot from the back to the front (Because I also wanted to mount an arm on the middle platform). For that I changed the urdf file as well as the turtlebot_calib_cam_x value under turtlebot_description/turtlebot_calibration.xacro.

The urdf of the turtlebot is placed under turtlebot/turtlebot/desription/urdf/. There are different xacro files.

When I remeber correctly the main file is turtlebot.urdf.xacro which includes the other ones (you will see it in the xml code)

You can get help for editing under http://www.ros.org/wiki/urdf. You don't have to build the urdf explicitly it is normally done in the launch file via xacro.

I had the same problem Running Electric on Ubuntu 10.04 with an overlay workspace. The problem occured when I moved my ros workspace. Inspecting the system with roswtf or rosrun tf tf_monitor failed. My solution was to create a symlink from /etc/ros/setup.bash to <ros_workspace>/setup.bash Afterwards restart turtlebot service.

Explanation:

The turtlebot service uses the file in /etc for configuration. Which points to specific directories.

Content of /etc/ros/setup.bash coming from .../turtlebot_bringup/upstart/install.sh '. /opt/ros/electric/setup.bash; export ROS_PACKAGE_PATH=/home/turtlebot/ros:${ROS_PACKAGE_PATH}'

This thread helped me out: http://answers.ros.org/question/28020/difference-between-turtlebot_bringup-minimallaunch-and-turtlebot-service/

The install script in fuerte is somewhat more sophisticated but is from my point of view also not able to work with overlays.

As I am not allowed to comment with my karma, I'll write an answer...

I had the same problem when working with the turtlebot and connecting the arbotix controller for test and setup purposes.

I made several udev rules for the roomba and the arbotix. udevadm is very helpful to identify properties of your devices to write the rules. Restarting the pc was not necessary (As the man page of udevadm says too)