Mike,<br><br>I've answered in line:<br><br><div class="gmail_quote">On Mon, Jun 7, 2010 at 10:06 AM, Mike Purvis <span dir="ltr"><<a href="mailto:mpurvis@clearpathrobotics.com" target="_blank">mpurvis@clearpathrobotics.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">



You can also set all costmaps to rolling windows with their global<br>frame as /odom. As long as you actually publish a tf between that and<br>base_link (or whatever you want to call your equivalent frames), you<br>should be able to run completely without a map server. I can<br>



definitely say that it is possible to run navigation without a static<br>map - I am currently doing just that and have had no issues related to<br>lack of map server.<br></blockquote><div><br></div></div><div>Having a few remaining difficulties with this approach. I think I must be overlooking part of it. I'm successfully broadcasting a transform between base_link and odom (confirmed with tf_echo), and these are my two setup files:</div>



<div><br></div><div><div>local_costmap:</div><div>  global_frame: odom</div><div>  robot_base_frame: base_link</div><div>  update_frequency: 5.0</div><div>  publish_frequency: 2.0</div><div>  static_map: false</div><div>


  rolling_window: true</div>
</div><div><br></div><div><div>global_costmap:</div><div>  global_frame: odom</div><div>  robot_base_frame: base_link</div><div>  update_frequency: 5.0</div><div>  static_map: false</div><div>  rolling_window: true</div>


</div>
<div><br></div><div>However, I'm still receiving an error about the /map transform:</div><div><br></div><div><div>[ WARN] 1275924057.427095000: Waiting on transform from base_link to /map to become available before running costmap, tf error: Frame id /map does not exist!</div>

</div></blockquote><div><br>With the parameters that you posted, you should no longer receive this error. Can you take a look at the parameters you have set with "rosparam dump" to make sure that the parameters for the global_costmap are being set correctly? They should fall under the move_base_node/global_costmap/ namespace.<br>

</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>

</div><div><br></div><div>Is there a remaining reference to it which I haven't found?</div><div><br></div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



<div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">

</div></blockquote><div>There's a tutorial on odometry here <a href="http://www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom" target="_blank">http://www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom</a> </div>



</div></div></div></blockquote><div><br></div></div><div>This page was extremely helpful, thank you for pointing it out! I didn't realise until then that it was the responsibility of my odometry node to also be broadcasting the transform.</div>

<div>

<div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="gmail_quote"><div><div>There are no special values of frame ids.  You can use any frame_id for anything as long as your system is consistent.   However, we do try to use standard frame_ids such that nodes can have useful default values.  In general you will want a frame attached the the world/inertial frame if you want to persist any observed obstacles or landmarks. </div>



</div></div></div></blockquote><div><br></div></div><div>Okay, so just to clarify my understanding, under this convention, the "base_link" moves with the robot, and the "odom" frame is approximately equal to the map frame, which is fixed. Is this so?</div>
</div></blockquote><div><br>That's correct. The odom frame is a fixed frame.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">



<div><br></div><div>The way I've been handling my multi-robot requirement has been to use ROS_NAMESPACE when launching my simulators, and then use topic names expressed relatively. So far, this has been working great, but what will be the impact of it when it comes to tf? Should each robot have its own odom, or do they share it? Does tf honour the namespace, or it entirely absolute? It looks in the turtle demo like the name of the robot is manually included in the transform broadcast (from "world" to turtlename), which is then given as absolute.</div>
</div></blockquote><div><br>The "tf_prefix" parameter is how we handle tf trees from multiple robots, you can check out documentation on it here: <a href="http://www.ros.org/wiki/tf/CoordinateFrameConventions">http://www.ros.org/wiki/tf/CoordinateFrameConventions</a>. Typically, each robot has its own odom frame and robots are related to each other via a map frame where they know their position relative to each other.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">
<div>

<div><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="gmail_quote"><div>Also depending on your application I would expect that you will want to maintain both of what we call a map frame and odom frame.  The difference between these frames is that the odom frame is locally consistent but can drift away from global accuracy.   It is used for short term planning/control.  But long term planning is done in the map frame and our localization node estimates the amount of drift accumulated between the odom and map frame.</div>



</div></div></blockquote><div><br></div></div><div>If I want (need?) to do this, do I need to run map_server? Should I also be broadcasting a map -> baselink transform from my odometry node, or does that come from elsewhere? If my positioning data is coming from GPS or perhaps an indoor camera-based localization scheme, is that still "odometry", or is odometry only for data based on encoders and other less-certain methods?</div>
</div></blockquote><div><br>If you're doing a lot of multi-robot navigation and you want the robot's to be aware of each other's positions, you'll probably need a map frame. You don't necessarily need to run a map_server, but you will need to have your localization source, whether that be GPS, camera-based localization, or other, publish a transform from the map frame to the odom (or if you don't have odom, base_link) frame of your robot. In the case where you don't have a map_server... you'd still set the "static_map" parameter on the global_costmap to be false.<br>
<br>Hope this helps,<br><br>Eitan<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote">


<div><br></div><div>Thanks again for your assistance.</div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br>