search

skasperski / navigation_2d

ROS nodes to navigate a mobile robot in a planar environment
GNU General Public License v3.0
123 stars 65 forks source link

Nav2d setup troubles #8

Closed mathew-kurian closed 9 years ago

mathew-kurian commented 9 years ago

Hi,

Our tf tree does not have an offset frame between the map and the odometry. So, is there anyway we can just remove that from MultiMapper.cpp and have no problems. Or is that a required component for your library? And what is the purpose of the offset tf for your implementation?

Bear with me as I am still new to this.

Thank you!

skasperski commented 9 years ago

The offset frame is published by the Mapper (it is used internally for multi-robot mapping). So if you use the nav2d_karto/mapper, you should automatically have this frame. If you use another mapper, you won't have this offset (and won't need it).

So to make it short: There should be no reason to remove it from the MultiMapper. The mapper provides the map->odom transform, as any localization/slam approach does. It just does this via map->offset->odom because of some special issues with multi-robot mapping.

mathew-kurian commented 9 years ago

Whenever I try to implement nav2d into our existing program, I keep getting the following error:

Extrapolation Error looking up robot pose: Lookup would require extrapolation into the future. Requested time 16.706000000 but the latest data is at time 16.700000000, when looking up transform from frame [base_footprint] to frame [map]

Our tf tree can be found here https://www.dropbox.com/s/zs620hdpom9zzl6/frames_bwi_kr_execution.pdf?dl=0

If you can help me identify the problem here, it would be great!

skasperski commented 9 years ago

The problem is your fake_localization. It publishes map->odom, which is now done by the real localization from the MultiMapper, So you have to remove this fake_localization.

mathew-kurian commented 9 years ago

It would be great if you can explain that a bit more in Laymans terms.

skasperski commented 9 years ago

Somewhere in your launch file there is a node named "fake_lokalization" (I guess it is just a static_transform_publisher). Just remove this one when adding the mapper to your system.

mathew-kurian commented 9 years ago

I am sorry, the robot seems to get stuck for some reason although I don't see the error anymore.

Here is our launch file, please let me know if you see anything that might be off. Your help is much appreciated.

<launch>

  <arg name="dir_path" default="$(find bwi_kr)/config/simulation" />
  <arg name="map_file" default="$(find utexas_gdc)/maps/3ne.yaml" />
  <arg name="location_file" default="$(arg dir_path)/locations.yaml" />
  <arg name="door_file" default="$(arg dir_path)/doors.yaml" />

  <!-- launch gazebo simulation environment and map server -->
  <include file="$(find utexas_gdc)/launch/3ne.launch" />
  <include file="$(find utexas_gdc)/launch/3ne_map.launch" />

  <!-- launch the base robot + autonomous navigation -->
  <include file="$(find segbot_gazebo)/launch/segbot_mobile_base.launch">
    <arg name="launch_localization" value="true" />
    <arg name="use_fake_localization" value="false" />
    <arg name="launch_move_base" value="true" />
    <arg name="use_full_gazebo_model" value="false" />
    <arg name="x" value="22" />
    <arg name="y" value="11.5" />
  </include>

  <!-- launch logical navigator -->
  <node name="segbot_logical_navigator" pkg="segbot_logical_translator"
        type="segbot_logical_navigator">
    <param name="map_file" value="$(arg map_file)" />
    <param name="door_file" value="$(arg door_file)" />
    <param name="location_file" value="$(arg location_file)" />
  </node>

  <!-- launch the simulation door handler -->
  <include file="$(find segbot_simulation_apps)/launch/door_handler.launch">
    <arg name="door_file" value="$(arg door_file)" />
  </include>

  <!-- launch rviz for navigation visualization -->
  <include file="$(find segbot_navigation)/launch/rviz.launch" />

  <!-- Nav2D -->

  <!-- Some general parameters -->
  <param name="use_sim_time" value="true" />
  <rosparam file="$(find nav2d_tutorials)/param/ros.yaml"/>

  <!-- Start the Operator to control the simulated robot -->
  <node name="Operator" pkg="nav2d_operator" type="operator" >
    <remap from="scan" to="base_scan"/>
    <rosparam file="$(find nav2d_tutorials)/param/operator.yaml"/>
    <rosparam file="$(find nav2d_tutorials)/param/costmap.yaml" ns="local_map" />
  </node>

  <!-- Start Mapper to genreate map from laser scans -->
  <node name="Mapper" pkg="nav2d_karto" type="mapper">
    <remap from="scan" to="base_scan"/>
    <rosparam file="$(find nav2d_tutorials)/param/mapper.yaml"/>
  </node>

  <!-- Start the Navigator to move the robot autonomously -->
  <node name="Navigator" pkg="nav2d_navigator" type="navigator">
    <rosparam file="$(find nav2d_tutorials)/param/navigator.yaml"/>
  </node>

  <node name="GetMap" pkg="nav2d_navigator" type="get_map_client" />
  <node name="Explore" pkg="nav2d_navigator" type="explore_client" />
  <node name="SetGoal" pkg="nav2d_navigator" type="set_goal_client" />

</launch>
skasperski commented 9 years ago

You include a lot of other launch files in this top-level launch file, so I can't say much about the complete system. Especially your "segbot_mobile_base.launch" seems to start a complete navigation solution of its own (localization, move_base, etc...), which will not work together with nav2d. So you should start only the gazebo-simulation with the simulated robot and nav2d. You can use rqt_graph to see all running nodes and their connections in your ROS system.

mathew-kurian commented 9 years ago

I still cannot seem to find out the problem. It would help me a lot if you can take a look at the launch files again just to make sure that I didn't overlook anything. I have disabled fake_localization as you have suggested and yet there seems to be some sort of error where the robot fails to move around. Thank you very much.

environment.launch

<launch>

  <arg name="dir_path" default="$(find bwi_kr)/config/simulation" />
  <arg name="map_file" default="$(find utexas_gdc)/maps/3ne.yaml" />
  <arg name="location_file" default="$(arg dir_path)/locations.yaml" />
  <arg name="door_file" default="$(arg dir_path)/doors.yaml" />

  <!-- launch gazebo simulation environment and map server -->
  <include file="$(find utexas_gdc)/launch/3ne.launch" />
  <!-- <include file="$(find utexas_gdc)/launch/3ne_map.launch" /> -->

  <!-- launch the base robot + autonomous navigation -->
  <include file="$(find segbot_gazebo)/launch/segbot_mobile_base.launch">
    <arg name="launch_localization" value="true" />
    <arg name="use_fake_localization" value="true" />
    <arg name="launch_move_base" value="true" />
    <arg name="use_full_gazebo_model" value="false" />
    <arg name="x" value="22" />
    <arg name="y" value="11.5" />
  </include>

  <!-- launch logical navigator -->
 <!-- Commented out for testing Nav2D -->
 <!-- Commented out for testing Nav2D -->
 <!-- Commented out for testing Nav2D -->
<!--   <node name="segbot_logical_navigator" pkg="segbot_logical_translator"
        type="segbot_logical_navigator">
    <param name="map_file" value="$(arg map_file)" />
    <param name="door_file" value="$(arg door_file)" />
    <param name="location_file" value="$(arg location_file)" />
  </node> -->

  <!-- launch the simulation door handler -->
  <include file="$(find segbot_simulation_apps)/launch/door_handler.launch">
    <arg name="door_file" value="$(arg door_file)" />
  </include>

  <!-- launch rviz for navigation visualization -->
  <include file="$(find segbot_navigation)/launch/rviz.launch" />

  <!-- Nav2D -->

  <!-- Some general parameters -->
  <param name="use_sim_time" value="true" />
  <rosparam file="$(find nav2d_tutorials)/param/ros.yaml"/>

  <!-- Start the Operator to control the simulated robot -->
  <node name="Operator" pkg="nav2d_operator" type="operator" >
    <remap from="scan" to="base_scan"/>
    <rosparam file="$(find nav2d_tutorials)/param/operator.yaml"/>
    <rosparam file="$(find nav2d_tutorials)/param/costmap.yaml" ns="local_map" />
  </node>

  <!-- Start Mapper to genreate map from laser scans -->
  <node name="Mapper" pkg="nav2d_karto" type="mapper">
    <remap from="scan" to="base_scan"/>
    <rosparam file="$(find nav2d_tutorials)/param/mapper.yaml"/>
  </node>

  <!-- Start the Navigator to move the robot autonomously -->
  <node name="Navigator" pkg="nav2d_navigator" type="navigator">
    <rosparam file="$(find nav2d_tutorials)/param/navigator.yaml"/>
  </node>

  <node name="GetMap" pkg="nav2d_navigator" type="get_map_client" />
  <node name="Explore" pkg="nav2d_navigator" type="explore_client" />
  <node name="SetGoal" pkg="nav2d_navigator" type="set_goal_client" />

</launch>

3ne.launch

<launch>

  <arg name="use_sim_time" default="true" />
  <arg name="gui" default="true" />
  <arg name="world" default="gazebo" />
  <arg name="debug" default="false" />

  <arg unless="$(arg debug)" name="gazebo_binary" value="gzserver" />
  <arg if="$(arg debug)" name="gazebo_binary" value="debug" />

  <!-- set use_sim_time flag -->
  <group if="$(arg use_sim_time)">
    <param name="/use_sim_time" value="true" />
  </group>

  <!-- start world -->
  <node name="$(arg world)" pkg="gazebo_ros" type="$(arg gazebo_binary)" args="$(find utexas_gdc)/worlds/3ne.world" respawn="false" output="screen" launch-prefix="$(optenv OPTIRUN_LAUNCH_PREFIX)" />

  <!-- start gui -->
  <group if="$(arg gui)">
    <node name="gazebo_gui" pkg="gazebo_ros" type="gzclient" respawn="false" output="screen" launch-prefix="$(optenv OPTIRUN_LAUNCH_PREFIX)" />
  </group>

</launch>

segbot_mobile_base.launch

<launch>

  <arg name="world" default="gazebo" />
  <arg name="map_frame" default="map" />
  <arg name="map_service" default="/static_map" />
  <arg name="map_topic" default="/map" />
  <arg name="x" default="0" />
  <arg name="y" default="0" />
  <arg name="z" default="0" />
  <arg name="roll" default="0" />
  <arg name="pitch" default="0" />
  <arg name="yaw" default="0" />
  <arg name="robotid" default="segbot" />
  <arg name="tf_prefix" default="" />
  <arg name="use_full_gazebo_model" default="true" />
  <arg name="configuration_file" default="$(find segbot_bringup)/launch/includes/auxiliary.segbot_hokuyo.launch.xml" />

  <!-- whether to launch autonomous stuff or not -->
  <arg name="launch_localization" default="false" />
  <arg name="use_fake_localization" default="false" />
  <arg name="launch_move_base" default="false" />

  <!-- set tf prefix (used by gazebo plugins) -->
  <param name="tf_prefix" value="$(arg tf_prefix)" />
  <arg name="base_frame_id" default="$(arg tf_prefix)/base_footprint" />
  <arg name="odom_frame_id" default="$(arg tf_prefix)/odom" />

  <!-- launch robot description and robot internal tf tree, along with any common nodes between h/w and software -->
  <include file="$(arg configuration_file)">
    <arg name="use_full_gazebo_model" value="$(arg use_full_gazebo_model)" />
    <arg name="tf_prefix" value="$(arg tf_prefix)" />
  </include>

  <!-- push robot_description to factory and spawn robot in gazebo -->
  <node name="spawn_robot" pkg="gazebo_ros" type="spawn_model"
    args="-param robot_description
    -urdf
    -x $(arg x)
    -y $(arg y)
    -z $(arg z)
    -R $(arg roll)
    -P $(arg pitch)
    -Y $(arg yaw)
    -model $(arg robotid)
    -gazebo_namespace /$(arg world)"
    respawn="false" output="screen">
  </node>

  <!-- launch localization -->
 <!-- Commented out for testing Nav2D -->
 <!-- Commented out for testing Nav2D -->
 <!-- Commented out for testing Nav2D -->
  <!-- <group if="$(arg launch_localization)">
    <group unless="$(arg use_fake_localization)">
      <include file="$(find segbot_navigation)/launch/amcl.launch">
        <arg name="initial_pose_x" value="$(arg x)" />
        <arg name="initial_pose_y" value="$(arg y)" />
        <arg name="map_service" value="$(arg map_service)" />
        <arg name="map_topic" value="$(arg map_topic)" />
        <arg name="map_frame_id" value="$(arg map_frame)" />
        <arg name="base_frame_id" value="$(arg base_frame_id)" />
        <arg name="odom_frame_id" value="$(arg odom_frame_id)" />
      </include>
    </group>
    <group if="$(arg use_fake_localization)">
      <node name="fake_localization" pkg="fake_localization" type="fake_localization">
        <remap from="base_pose_ground_truth" to="odom"/>
        <param name="global_frame_id" value="$(arg map_frame)" />
        <param name="base_frame_id" value="$(arg base_frame_id)" />
        <param name="odom_frame_id" value="$(arg odom_frame_id)" />
      </node>
    </group>
  </group> -->

  <!-- launch move base -->
 <!-- Commented out for testing Nav2D -->
 <!-- Commented out for testing Nav2D -->
 <!-- Commented out for testing Nav2D -->
  <!-- <group if="$(arg launch_move_base)">
    <include file="$(find segbot_navigation)/launch/move_base_eband.launch">
      <arg name="map_topic" value="$(arg map_topic)" />
    </include>
  </group> -->

</launch>
skasperski commented 9 years ago

Can you post the DOT-graph from rqt_graph while your system is running? (Open rqt_graph and click "Save as DOT graph") And are there any errors in rqt_console?

mathew-kurian commented 9 years ago

@skasperski I apologize for the delay. I did get it running for exploration. I don't see any errors in rqt_console. Additionally, I have attached the rqt_graph here. But, I did notice the robot just moving in circles. Do you know why that might be?

skasperski commented 9 years ago

In your graph, there is still the map_server and fake_localization, but no Navigator and Mapper. Is this the graph from your exploration setup? Can you remote-control your robot with the joystick? If the robot moves in circles, the local map from the Operator might not be updated correctly. You can use RVIZ to check the local costmap.

mathew-kurian commented 9 years ago

Hello, I apologize for the delay. I got caught up with a lot of homework. But, I am back at it now. I see what you meant by what you said. Here is the new tf_graph with the changes you suggested. But the problem is that the robot does not show on the simulator. It also has the following error:

[ERROR] [1415050419.867396222]: Could not get robot position: "map" passed to lookupTransform argument target_frame does not exist. 
[ERROR] [1415050419.868015469]: Exploration failed, could not get current position.

On the other hand, If I launch our existing localization along with Nav2D, the robot shows up but the tf_graph looks like that which doesn't seem like what you suggested.

Can you please provide some guidance with this?

skasperski commented 9 years ago

My bad, I actually meant the result of rqt_graph. Can you post this as well? And what do you mean with the robot does not show in simulation? You mean within Gazebo? This should not depend on the rest of your ROS setup.

mathew-kurian commented 9 years ago

That is understandable. I have uploaded a lot of information to this Dropbox folder. It contains two subfolders:

Thank you for taking the time to help me out.

NOTE: I have fixed the Mapper:base_scan [uknown type] issue that can be seen in bwi_kr_merge_data\rosnode-bwi_kr_merge.[docx|pdf]

skasperski commented 9 years ago

Looking at your RVIZ-screenshot it seems a bit like the robot is not moving the way it thinks it does. (The map patches are overlayed incorrectly.) Some ideas only:

I remeber I did some runs with a robot in Gazebo as well. Maybe you can use some of the launchscrips from there: https://github.com/skasperski/gazebo_robots

mathew-kurian commented 9 years ago

@skasperski So we found out the problem with our codebase and was able to implement your library. We used the joystick and was able to correctly map out the floor. However, we did face some issues during auto-exploration. It seems the robot keeps getting stuck on door entrances. To better show the issues, I have recorded two videos which should identify the problem for you.

Thank you again. I hope you can help us out with this.

skasperski commented 9 years ago

This is likely due to the size of the robot. How big is your robot and how wide are the doors? For the Operator, you have set a robot radius of 0.4 (costmap.yaml) and for the Navigator a radius of 0.2 (navigator.yaml). The radius for the Operator should match that of the robot (maybe plus a little safety when using the real thing) and the Navigator should have a little more than the Operator. So the Navigator should never assume a smaller Robot than the Operator, as it is the case in your setup. Hope that helps!

PS: On Ubuntu, you can use "recordmydesktop" (install via apt-get) to make videos from the desktop!

mathew-kurian commented 9 years ago

Our robots are 0.35 - 0.4 meters in radius. The doors are only 1 meter wide. Are the doors to narrow for the navigator to work correctly?

EDIT: I have set the radius to 0.4 and the map_inflation to 0.5. But the robot still seems to get stuck. Can you let me know other paramters that might be important related this. None of the variables on navigator.yaml don't seem to be documented.

skasperski commented 9 years ago

This should work I guess. Our doors are also like 1m wide and our Pioneer-Robots could pass them without much problems. You should keep the inflation radius at 1m. Maybe leave the radius in costmap.yaml at 0.4 and set it to 0.45 in navigator.yaml.

It is always useful to display the Operator's costmap and the Navigator's plan topics in RVIZ to see what's going on when the robot gets stuck.

The parameters are documented here: http://wiki.ros.org/nav2d_navigator

mathew-kurian commented 9 years ago

@skasperski So, what I noticed was that the robot in order to diagonally, it would move left and then right. it jumps back and forth. I have attached a video that really describes it. i used my camera to record the screen instead of the program you suggested since i am on lab machines. I talked to a graduate student who mentioned that Gazebo has a slight "deceleration" that is applied on angular velocity which needs to be accounted for. Can you please provide some suggestions on how to resolve the issue or to account for this.

https://www.dropbox.com/s/1u91lhscbqb9xzg/Video%20Dec%2001%2C%202%2053%2039%20PM.mov?dl=0

skasperski commented 9 years ago

Your robot is moving really fast, can you try to reduce the Operator's "max_velocity" to 0.25 (just for testing) and see if it solves the issue? Note that it is relatitive to your platforms speed, so 1.0 means full speed of your platform.

If yes you might have to increase the Operators cycle rate, which is 10Hz at the moment and might cause this oscillating behaviour. This is no parameter yet, so you would have to change it in node.cpp (http://docs.ros.org/indigo/api/nav2d_operator/html/node_8cpp_source.html)

mathew-kurian commented 9 years ago

@skasperski It is still doing the same thing but now at a much smaller scale. Also, it still drifts into the edge of a door although the navigation path says to go straight through.

I will run some additional tests and see what happens and let you know.

mathew-kurian commented 9 years ago

@skasperski I have tested out a lot here. Everytime I run it, the robot plans a path (that looks correct to in RVIZ) but right as it approaches the door. It "turns" too hard which causes it to steer off course. At this point, the robot replans but keeps failing. The oscillation issue persists.

EDIT: I also want to mention that with the teleop I can easily map the floor with no troubles what so ever. It is only with the auto exploration.

skasperski commented 9 years ago

To look into the issue with the doors, please add the visualization topics from the Operator to your RVIZ. (~local_map/costmap, ~desired and ~route). This way you can see what actually happens at the doors.

To solve the oscillating behaviour, you can try to increase the Operators conformance_weight and distance_weight parameters. (Effectively decreasing the safety_weight, which might keep the robot from moving through the narrow doors.) (http://wiki.ros.org/nav2d_operator).

About linear/angular speed: The Operator doesn't use this linear/angular speed concept, but uses steering angle and velocity instead. (Very much like driving a car) Does the oscillating still occur away from the doors, when you run the robot on low speed?

mathew-kurian commented 9 years ago

I don't see a ~/route but I added everything else. I can see it just "replan" at that point after making an initial operator command that offshoots the turn. This happens ~1m from the front of the door. Essentially it turns before its supposed to and crashes into the door.

Does the oscillating still occur away from the doors, when you run the robot on low speed?

Yes it does. Oscillation always happens, nut obviously its much slower since the the speed is lowered.

I am up right now. I can let you see my desktop (via. TeamView) if that might help you see the issue better. Just an idea. Might be easier to solve the problem :)

mathew-kurian commented 9 years ago

Better view of the problem. Sometimes it clears the door like below but its really cutting it close. 95% of the time it never clears the first door.

I

skasperski commented 9 years ago

Aha, this screen totally shows the problem! Your local costmap is not updated at all from the laser scanner. And this is why the robot oscillates, because it never has free space where it can move to. So check two things:

mathew-kurian commented 9 years ago

It seems like the scanner is connected correctly. So, I have no idea why the costmap is not being updated. I will look into it more right now but please let me know if you have any ideas.

rostopic info /scan

Type: sensor_msgs/LaserScan

Publishers: 
 * /gazebo (http://mkurian-M17xR3:39014/)

Subscribers: 
 * /hokuyo_laser_filters (http://mkurian-M17xR3:47835/)
 * /Mapper (http://mkurian-M17xR3:56152/)
 * /Operator (http://mkurian-M17xR3:34757/)

ros.yaml

###########################################################
# Defines topics services and frames for all modules

### TF frames #############################################
laser_frame: nav_hokuyo_laser_link
robot_frame: base_link
odometry_frame: odom
offset_frame: offset
map_frame: map

### ROS topics ############################################
map_topic: map
laser_topic: scan

### ROS services ##########################################
map_service: static_map

Our Laser Settings

<ray>
  <scan>
    <horizontal>
      <samples>640</samples>
      <resolution>1</resolution>
      <min_angle>${min_angle}</min_angle>
      <max_angle>${max_angle}</max_angle>
    </horizontal>
  </scan>
  <range>
    <min>0.02</min>
    <max>20.0</max>
    <resolution>0.03</resolution>
  </range>
</ray>

Laser Our laser is located about 1/3m from the ground. So I don't feel like I should adjust the default settings. Please advise.

mathew-kurian commented 9 years ago

Better video with /desired and /route

mathew-kurian commented 9 years ago

Video of costmap from static map

#set to true if you want to initialize the costmap from a static map
static_map: true

A lot better but still gets stuck at the end with the following message:

[ERROR] [1418075732.765972014, 237.376000000]: No way between robot and goal!
skasperski commented 9 years ago

"static_map: true" is for global costmaps (path planners) and should not be used for the Operator's costmap. In the video you often see the doors getting "closed" (the pink parts of the costmap filling the whole opening), which means the robot cannot pass through. You might further decrease the robot radius (costmap.yaml) or decrease safety_weight (operator.yaml), but this is secondary. First you need the costmap to be updated from Scans. Have you tried to just change min_obstacle_height and max_obstacle_height (for example 0.0 - 1.0)?

mathew-kurian commented 9 years ago

min_obstacle_height and max_obstacle_height. It still doesn't work :( Should I expect to see something with that? I would like to present your work in a couple of days to the UT BWI robotics as a way of exploring and mapping so I would really like to get this working.

skasperski commented 9 years ago

In the past it was usually due to these params, that the costmap was not updated. Can you check in RVIZ if the scans are really 0.3m above ground? Sometimes there is some problem with transforms and your scans are actually below ground. (e.g. -0.3)

mathew-kurian commented 9 years ago

@skasperski How can I check if they are below ground?

mathew-kurian commented 9 years ago

@skasperski The pink like is the hokoyu_laser_filters

a

skasperski commented 9 years ago

Visualize the /scan topic (it already is in your screen) and look if the points are above the grid.

mathew-kurian commented 9 years ago

@skasperski I don't see much from the scan_topic (i see a very faint line) thats all.

skasperski commented 9 years ago

These are the points from the laser scanner. (The actually simulated laser points.) You can increase their size on RVIZ in the left menu. Are they above the grid?

mathew-kurian commented 9 years ago

yes they are. They are above ground.

skasperski commented 9 years ago

Have you tried running only your simulator and the Operator (with remote_controller) to see if it works then?

PS: I'm not sure whether I find time, but what packages are needed in order to locally test your Gazebo-Setup?

mathew-kurian commented 9 years ago

With the operator. It works well.

The packages are quite easy. This is all you really have to do. It would be really appreciated if you can take a look at the code.

Dependencies (including your lib)

sudo apt-get install ros-hydro-bwi-desktop-full ros-hydro-openni-tracker openjdk-6-jdk ros-hydro-roslint ros-hydro-cmake-modules gringo ros-hydro-nav2d -y
sudo apt-get install build-essential libgtkmm-2.4-dev -y

BWI/Nav2D packages

cd ~/catkin_ws/src

git clone 'https://github.com/utexas-bwi/bwi.git'
git clone 'https://github.com/utexas-bwi/bwi_common.git'
git clone 'https://github.com/utexas-bwi/bwi_planning.git'
git clone 'https://github.com/bluejamesbond/bwi_experimental.git'
git clone 'https://github.com/bluejamesbond/navigation_2d'
git clone 'https://github.com/utexas-bwi/clasp.git'
git clone 'https://github.com/bluejamesbond/segbot.git'
git clone 'https://github.com/utexas-bwi/segbot_apps.git'
git clone 'https://github.com/utexas-bwi/segbot_simulator.git'

cd navigation_2d
git checkout hydro
cd ~/catkin_ws
catkin_make

You must add the following lines to /catkin_ws/CMakeLists.txt.

# toplevel CMakeLists.txt for a catkin workspace
# catkin/cmake/toplevel.cmake

cmake_minimum_required(VERSION 2.8.3)
set(CATKIN_TOPLEVEL TRUE)

INCLUDE(FindPkgConfig) # Add

pkg_check_modules(GTKMM gtkmm-2.4) # Add
pkg_check_modules(SIGC2 sigc++-2.0) # Add

Running the system

roslaunch bwi_nav2d nav2d_mapper_krr2014.launch

Using the operator (once the previous command is called)

rosrun segbot_bringup teleop_twist_keyboard
skasperski commented 9 years ago

Ok, maybe I can try it. But if it works for you with the Operator alone, then you should step by step add the other stuff and see when and why it stops working.

mathew-kurian commented 9 years ago

I have tried a lot and asked my peers. Unfortunately to no avail. So that is why I was hoping you could take a look at it. I tried adding step by step but it did not work. I have put a simple website if you want to see your library in action. The website is still a little weak but check it out. I will be presenting this in a couple days to the robotics team here at University of Texas at Austin.

mathew-kurian commented 9 years ago

@skasperski Did you get a chance to look at the code? Any issues from our end that need to be resolved? Please let me know. I have been looking forward to using your library our labs.

skasperski commented 9 years ago

Now I was able to try it. As I said, your laser is mounted higher than expected. Just increase max_obstacle_height to 1.0 and the costmap works.

mathew-kurian commented 9 years ago

I kept changing the wrong max_obstacle_height since was define defined twice in the same file :( It works really well now except for one case when it reaches the boundaries of the map - it tries to go into the edge wall and keeps retrying the edge over and over. It gives the following error:

Robot is stuck! Trying to recover...

EDIT:

Some cases it just gets stuck and gets the following error. Any idea as to why this might happen?

No way between robot and goal!
Exploration failed

I have pushed in all my updates so you can look at the params and see if there is anything out of the ordinary. And again thank you so much for putting the time to help me out! Really appreciate it.

https://github.com/bluejamesbond/bwi_experimental

Image of Robot being stuck; failed at this point. Orange blocks are LaserScan.

A

skasperski commented 9 years ago

Oh, the parameter really is twice in the costmap.yaml. The file is taken from the costmap_2d package, so I assume it has to be that way.

About the wall at the edge of the map: This is a problem with OpenKarto that happens in simulation only, where you have very sharp edges that are exactly perpendicular to the mapping grid. A work around is to place your robot with a start heading of e.g. 45°, so your map is not aligned with the simulated walls. Tutorial 3 in nav2d does this to avoid exactly this problem.

If it says "No way between robot and goal" it means that the Navigator cannot plan through doors. So you might also have to decrease the robot_radius in the navigator.yaml a bit further. (But keep it larger than in the costmap.yaml)

Because of the very narrow doors, I also changed the operator's conformance_weight to 5, which also gave some better results here when passing the doors.

mathew-kurian commented 9 years ago

Ok. Ill test this out. What do you mean by "place your robot with a start heading of e.g. 45°". Can you put that in simpler form please?

skasperski commented 9 years ago

Start Tutorial 3 and you see what I mean. ;)

mathew-kurian commented 9 years ago

@skasperski The conformance_weight to 5 coupled with reducing the navigation radius has drastically improved exploration. However, the map edge issue is still there. I just put the yaw of the robot to 45 degrees. is that right?