[ros-users] problems with nav_view / nav stack

Thu Apr 22 01:11:54 UTC 2010

Thanks Eitan. I think I understand why there's two subscribers now.

I think the real problem has to do with getting the timing of the TF tree
correct.

First, nav_view is spitting this out...
MessageFilter [target=/map ]: Dropped 100.00% of messages so far. Please
turn the [ros.nav_view.message_notifier] rosconsole logger to DEBUG for more
information.
Which leads to a bunch of these debug messages
MessageFilter [target=/map ]: Removed oldest message because buffer is full,
count now 2 (frame_id=/odom, stamp=1271897446.118687)
MessageFilter [target=/map ]: Added message in frame /odom at time
1271897447.119, count now 2

Setting the pose in nav_view leads to
Failed to transform initial pose in time (You requested a transform that is
0.956 miliseconds in the past,
but the most recent transform in the tf buffer is 1501.008 miliseconds old.
 When trying to transform between /base and /map.
)

tf view_frames shows everything connected. The most concerning part is that
the map->odom and odom->base transforms are 1.564 sec old.

The problem remains that setting the pose in nav_view does not actually
change the pose. The laser scans are now showing up as obstacles around the
robot's footprint, but that footprint is in the wrong spot. I've solved that
by making transform_tolerance: 10 on the costmaps. That doesn't quite seem
like the right approach. How else can I speed up my tfs?

-David!!

On Wed, Apr 21, 2010 at 11:58 AM, Eitan Marder-Eppstein <
eitan at willowgarage.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/7b79ff9a/attachment-0003.html>