[ros-users] problems with nav_view / nav stack

Eitan Marder-Eppstein eitan at willowgarage.com
Wed Apr 21 16:58:40 UTC 2010


David,

I don't think this is the problem. AMCL actually subscribes to the
"initialpose" topic twice. Once through a message filter and once through
the code you posted above to support a deprecated API where you wouldn't
fill in a frame_id for the message. Any message that comes in that has a
valid frame_id will pass through the message filter directly to the
"initialPoseReceived" callback when tf has enough information to transform
the pose to the "map" frame. The "initialPoseReceivedOld" callback is just
to handle those who are using the old API... and nav_view uses the new API.
Eventually the old callback will be removed.

Hope all is well,

Eitan

On Wed, Apr 21, 2010 at 9:43 AM, David Lu!! <davidvlu at gmail.com> wrote:

> I think I may have found the problem. The messages are being sent through
> the below method in AMCL (confirmed by printing debug messages)
>
> void
> AmclNode::initialPoseReceivedOld(const geometry_msgs::PoseWithCovarianceStampedConstPtr& msg)
> {
>   // Support old behavior, where null frame ids were accepted.
>   if(msg->header.frame_id == "")
>   {
>     ROS_WARN("Received initialpose message with header.frame_id == "".  This behavior is deprecated; you should always set the frame_id");
>     initialPoseReceived(msg);
>   }
> }
>
> However, the messages are not being passed on to initialPoseRecieved since their frame is not "".
>
> Should this code read like this instead...
>
> void
>
> AmclNode::initialPoseReceivedOld(const geometry_msgs::PoseWithCovarianceStampedConstPtr& msg)
> {
>   // Support old behavior, where null frame ids were accepted.
>   if(msg->header.frame_id == "")
>   {
>     ROS_WARN("Received initialpose message with header.frame_id == "".  This behavior is deprecated; you should always set the frame_id");
>
>   }
>
>   initialPoseReceived(msg);
>
> }
>
>
>
> On Fri, Apr 16, 2010 at 6:33 PM, Dan Lazewatsky <lazewatskyd at cse.wustl.edu
> > wrote:
>
>>  Hi Eitan -
>> I'm inclined to say that this isn't a network issue since lots of other
>> things work, like streaming video from the robot using image_transport (and
>> iwconfig shows really good link quality), but I'll try your suggestions next
>> time I'm in the lab.
>>
>> Thanks,
>> -Dan
>>
>>
>> On 4/16/10 4:12 PM, Eitan Marder-Eppstein wrote:
>>
>> Dan,
>>
>> Those are strange problems to have. A hunch I have is that nav_view has
>> dropped its TCP connection to the robot for one reason or another on certain
>> topics. This happens to us sometimes when we're switching between being
>> connected to our robots over ethernet to wireless or when we lose
>> connectivity to the robot for long periods of time. I'd be curious about a
>> few things:
>>
>> 1) Can you get things to start displaying in nav_view by running the
>> following command:
>>      rosrun topic_tools relay [missing_topic_name] [missing_topic_name]
>>     This will re-advertise the topic and cause nav_view to refresh its TCP
>> connections.
>>
>> 2) Are you sure that the robot can connect to the machine that's running
>> nav_view? Have you been running rostopic echo on the robot itself? Or on the
>> local machine?
>>
>> 3) If you use rviz, do you see the same kind of problems. If this is a
>> network issue, I'd expect you to see the same problems, but it'd be useful
>> to know.
>>
>> Hopefully this helps or we at least find out more about what's going on.
>>
>> Hope all is well,
>>
>> Eitan
>>
>> On Fri, Apr 16, 2010 at 1:54 PM, Dan Lazewatsky <
>> lazewatskyd at cse.wustl.edu> wrote:
>>
>>> Hi all -
>>> We've been trying to get the nav stack running on one of our robots and
>>> are having some frustrating and not totally reproducible problems. Nav
>>> is setup from config files that I got working on an erratic and have
>>> modified for this robot. When I start up nav_view after getting amcl,
>>> move_base and the like going, most of the time I don't see any laser
>>> scan, inflated obstacles etc. in nav_view and using Set Pose doesn't do
>>> anything. move_base/local_costmap/obstacles is publishing data, and
>>> rxgraph shows it connected to nav_view. When I use Set Pose, I can see
>>> the message getting sent off, but the new pose is not reflected in
>>> nav_view. Sometimes, I'll see the inflated obstacles in nav_view, but
>>> once the map shows up they disappear.
>>>
>>> Any help would be much appreciated,
>>> -Dan
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>>
>>
>>
>> _______________________________________________
>> ros-users mailing listros-users at code.ros.orghttps://code.ros.org/mailman/listinfo/ros-users
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100421/5dd7490c/attachment-0003.html>


More information about the ros-users mailing list