ElizabethA's profile - activity

I'm running AMCL navigation on a map I created with the "Autonomous Navigation of a Known Map with Turtlebot" tutorial. As you can see below, when I open RViz with "roslaunch turtlebot_rviz_launchers view_navigation.launch", the robot (the little black dot) is not centered in the middle of the map, and I think it has to do with the map's origin, set in the .yaml file.

I can reconfigure the origin of the .yaml file to fix the robot's position on the RViz visualization of the map (see the correction in the 3rd picture), but the origin of my Global_costmap hasn't been updated, which means the laserscans aren't aligned with the rest of the map.

Any ideas of what I'm doing wrong?

The odom topic offers wheel velocity - not sure if that will be a helpful indicator of what you're trying to detect. I'v

I'm driving the Turtlebot around the turtlebot_world Gazebo environment. I'm printing out the AMCL particle filter poses and the weights assigned to the poses, and when I drive around for a while (as long as 5 minutes), the weights assigned to the poses in the particle filter are all set to the same value (particle weight = 0.00196, for 500 particles, so they sum to 1, of course).

I expected there to be some variety in the particles' weights - some higher, some lower. My theories as to why they're all equal:
1. I could be printing the weights at the wrong point of the AMCL code
2. It's a demo Gazebo world and a demo AMCL map - is the set-up too "perfect" for different hypotheses to result in different weights or something?

Here's a code snippet:
File: AMCL/src/amcl_node.cpp

Function: AmclNode::laserReceived(const sensor_msgs::LaserScanConstPtr& laser_scan)

~Line 1245, Added the following:

for(int i=0;i<set->sample_count;i++) {

   ROS_DEBUG("Weight: %f",set->samples[i].weight);
}

Great catch! I moved the print statement to line 1235 before the resampling, and now I'm seeing variety in the particle

AMCL Particle Weights Are Always Equal - Why? I'm driving the Turtlebot around the turtlebot_world Gazebo environment.

AMCL Particle Weights Are Always Equal - Why? I'm driving the Turtlebot around the turtlebot_world Gazebo environment.

AMCL Particle Weights Are Always Equal - Why? I'm analyzing the particle filter output for AMCL, and when I drive around

AMCL Particle Weights Are Always Equal - Why? I'm analyzing the particle filter output for AMCL, and when I drive around

I know what you're talking about - in the turtlebot demo environment, when I drive into the white cube, the encounter pu

I think you should be able to edit the param\Kinect_costmap_params.yaml file under turtlebot_navigation package, and add

I realized the global_costmap is somehow getting its Position (x, y) and Orientation set somehow...I just can't figure o

Orienting AMCL Map/Global_Costmap I'm running AMCL navigation on a map I created with the "Autonomous Navigation of a Kn

Orienting AMCL Map/Global_Costmap I'm running AMCL navigation on a map I created with the "Autonomous Navigation o

Like tfoote said, there are two different ideas going on here.

1. If YOU need to know the positions of the obstacles in Gazebo (for testing or something), there's the get_model_state command in the Gazebo API that you can use in a plugin or a script with rospy or roscpp (C++) to get the world/global/groundtruth coordinates of models in the Gazebo simulation.

2. However, it appears you need your ROBOT to find the positions of the obstacles. That's more difficult.

I use the Turtlebot with Gazebo, and when I need to drive from one point to the next, I use the AMCL package to make a map of the environment, and then I plug the map into AMCL and use the RViz GUI to set a goal and it drives the Turtlebot to where I want it. In this case, you're making a map of a room by collecting enough laserscan data to outline entire objects.

AMCL also publishes where it thinks the robot is in the environment as you drive on the AMCL/amcl_pose topic.
Here's more on AMCL: http://wiki.ros.org/amcl

The tough part - and what I don't know the answer to, but the object recognition link from tfoote might help - is figuring out/somehow identifying that the blob at (3,4) is a couch, or a chair, etc.

Here are links to the Turtlebot/Gazebo/AMCL/RViz tutorials. To be clear, I'm not suggesting that they are a solution to your problem. But they're a good demonstration of how localization in Gazebo - using the Kinect data as a makeshift laserscan - works.

http://wiki.ros.org/turtlebot_navigat...

http://wiki.ros.org/turtlebot_navigat...

I also had to update my CMakeLists and add SET(CMAKE_CXX_FLAGS "-std=c++11") to get the 'auto' and 'thread' stuff to compile.

My question was answered on the Gazebo forum.

See http://answers.gazebosim.org/question...

I ended up needing to use ROS subscribing methods, as used here: http://gazebosim.org/tutorials?tut=gu...

and here: https://bitbucket.org/osrf/frc_red_te...

Thanks for the idea! It turned out that I was using the wrong kind of subscribing options - I was using the Transport objects/methods to connect to ROS messages, when the two are separate communications channels.

Background:

I had a great callback function in a Gazebo plugin. I declared it with

void OnMsg(ConstVector3dPtr &msg)

and subscribed-to by my plugin's Load function with

subscriber = node->Subscribe("~/eb/vel_cmd", &MyPlugin::OnMsg, this);

Problem:

Instead of subscribing to "~/eb/vel_cmd", I'm subscribing to "/tf", so I need to change the message type of the callback (MyPlugin::OnMsg) to tf2_msgs::TFMessage. I followed the convention of the question in the link below to create a constant pointer for a tf2_msgs::TFMessage message.

http://answers.ros.org/question/21481...

Following the positionCb callback declaration in that code, now my callback is declared with:

private: void OnMsg(const tf2_msgs::TFMessage::ConstPtr& &msg)

I'm getting all kinds of compiling errors, but the biggest problem appears to be "Cannot declare reference to tf2_msgs::TFMessage_<std::allocator<void> >::ConstPtr& {aka class boost::shared_ptr<const tf2_msgs::tfmessage_<std::allocator<void="">>&}' (picture below).

Any ideas on what I'm doing incorrectly?

Compiling Errors:

The "Could not find any topics with /gazebo/spawn_model or /gazebo/delete_model even with rostopic list" part stuck out to me. The services (such as /gazebo/delete_model ) are listed when you call

rosservice list

ie, use rosservice, not rostopic, to check if the spawn/delete services are available.

Seems like AMCL does a really bad job of localizing in the map. I'm using the global_localization service to distribute the particles across the map initially, but the results are things like this:

when in fact the robot is staring at a corner like this:

Thoughts on what I'm missing here? Or what I need to look into to improve my results?

If you can set a system-wide environment variable for CURRENT_PKG (might need to put it in ~/.bashrc file), you can swap the $(find current_pkg) part with $(env CURRENT_PKG).

Maybe it can't get to the map? I think you'd get a different error if it truly couldn't find the map, so if it all works when accessed from another computer, but not on the original one, it could be a permissions issue or some kind of config setting somewhere...

Are you setting the map location inside the launch file, or with a command-line argument when you run it?

I was going about this the wrong way. One thing I learned is that my comments in the code (which I wasn't seeing on the screen initially) WERE being published, but I had to add --screen to see my comments:

roslaunch turtlebot_gazebo amcl_demo.launch (map file path) --screen

Another thing I learned is that by sourcing the overlay folder, I was adding my custom AMCL to the front of the classpath, and the overlay was being used the whole time. I discovered this by adding a custom message to the class, and then seeing what was published when I ran AMCL via rostopic list.

So. To do an overlay:

1. Make a workspace/package and get the code from GitHub
2. Edit your code how you want, add messages, etc.
3. Do source <path to workspace>/devel/setup.bash
4. Run your normal launch file.

When the launch file looks for a package in the classpath, it will find your overlay (as long as you 'source' beforehand within the same terminal.)

Grasping at straws here -

I'm using Indigo and I've made an overlay of the AMCL package. The path to it is in ROS_PACKAGE_PATH, and when I "roscd amcl", it takes me to the overlay directory. So far, so good.

One of the dependencies of turtlebot_navigation is AMCL, and I want turtlebot_navigation to start using my overlay for AMCL. Even after "sourcing" my overlay, when I run "roslaunch turtlebot_gazebo amcl_demo.launch", it's evident that I'm hitting the usual location of AMCL (/opt/ros/indigo/share/turtlebot_navigation), and not my overlay with some changes to the code. This has also been verified from the output of:

roslaunch-deps -v /opt/ros/indigo/share/turtlebot_navigation/launch/amcl_demo.launch

where I see lines such as: turtlebot_navigation [/opt/ros/indigo/share/turtlebot_navigation/launch/amcl_demo.launch]

What I've Tried: I've edited the amcl.launch.xml of turtlebot_navigation like so for the part that starts up the AMCL node: <node pkg="$(find amcl)" type="amcl" name="amcl">

hoping that the "$(find amcl)" would pick up whatever it is that "roscd" is picking up that lets it know that AMCL should be found in my overlay folder. This results in the following error:

ERROR: cannot launch node of type [/home/ebrenna8/Overlays/src/amcl]: /home/ebrenna8/Overlays/src/ ROS path [0]=/opt/ros/indigo/share/ros ROS path[1]=/home/ebrenna8/Overlays/src ROS path[2]=/opt/ros/indigo/share ROS path[3]=/opt/ros/indigo/stacks

which I've looked up and appears to mean that it can't find an executable by that name.

*Does anyone have ideas on what I need to do to get turtlebot_navigation to look to my Overlays folder instead of the original? I'm looking at modifying environment variables like CMake_Prefix_Path now. *

Let me know if I should provide additional information.