ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Tom Panzarella's profile - activity

2017-03-17 11:22:21 -0500 answered a question Can I reset RVIZ via topic?

I wanted to rekindle this idea. Before I go off and implement something to do this (in my "free time"), is anyone aware of a way to s/w trigger an rviz "reset" -- literally, to trigger the functionality that the "reset" button in the bottom left of the rviz screen carries out. Ideally passing an "empty" message to some topic/service that rviz is listening on would be ideal.

Thanks in advance for any advice.

Tom

2015-04-29 07:40:25 -0500 received badge  Enthusiast
2015-04-24 11:30:42 -0500 commented answer Install ROS Package Globally

OK. I have this sorted out now. It seems as though you need to specify the -DCMAKE_INSTALL_PREFIX when calling the install target instead of at compile time, which is what used to work. No big deal, just unexpected.

2015-04-24 11:04:27 -0500 commented answer Install ROS Package Globally

This had been working for me historically. However, it seems as of late catkin is not respecting the -DCMAKE_INSTALL_PREFIX option. Is this a regression? I'm running the latest version of Indigo as of 4/24/15.

2014-04-06 03:47:23 -0500 received badge  Enlightened (source)
2014-04-06 03:47:23 -0500 received badge  Good Answer (source)
2014-04-04 08:23:21 -0500 received badge  Nice Answer (source)
2014-04-04 07:45:35 -0500 received badge  Scholar (source)
2014-04-04 07:34:05 -0500 received badge  Self-Learner (source)
2014-04-04 07:34:05 -0500 received badge  Teacher (source)
2014-04-04 06:18:33 -0500 received badge  Famous Question (source)
2014-04-04 04:29:31 -0500 commented question Latency when sending goal to move_base and it starting

@demmeln Thanks for the comments. A combination of using a multi-threaded spinner and (down) throttling my sensors is looking promising right now. Going to do more testing before confirming a definitive resolution.

2014-04-03 09:45:21 -0500 answered a question Latency when sending goal to move_base and it starting

Please see "EDIT2" listed in my original question. The latency was indeed due to the amount of sensor data being subscribed to by move_base which (I can only presume) shares the same message queue with the /move_base/goal topic. Keeping all four sensor sources in place but dropping the rate from 30 Hz to 15 Hz provides acceptable goal responsiveness from move_base.

EDIT1: Upon further testing, it looks like the latency is due IN PART to the amount of sensor data. However, other factors are involved (e.g., TCP_NODELAY on the /move_base/goal topic, adjusting the queue size, etc.). Once I have this worked out definitively, I'll report back. Sorry for the premature resolution. More testing is required.

EDIT2: I believe I have this issue resolved. On the advice of @demmeln a combination of throttling my sensor sources and using a multi-threaded spinner in move_base has provided acceptable latency for the system. The specifics for my setup that work well are to scale the frequency of my 4 sensor sources down from 30 Hz to 15 Hz and to use a multi-threaded spinner within move_base with 2 threads. I have submitted a pull-request for the move_base changes. Those changes are minimal and available here: https://github.com/ros-planning/navig...

I should note that all changes that I had originally made to actionlib (i.e., TCP_NODELAY and changing the queue_size) were reverted during my testing today. The changes that worked for me were limited to what I describe in the preceding paragraph.

Thanks for the help / input.

2014-04-03 09:00:55 -0500 received badge  Notable Question (source)
2014-04-03 08:55:48 -0500 received badge  Nice Question (source)
2014-04-03 08:52:51 -0500 received badge  Editor (source)
2014-04-03 07:46:59 -0500 received badge  Popular Question (source)
2014-04-03 07:26:10 -0500 commented question Latency when sending goal to move_base and it starting

Yes. For the nodes in question, they are located on the same machine.

2014-04-03 07:22:57 -0500 commented answer Latency when sending goal to move_base and it starting

Note sure. Is there something simpler than SimpleActionClient that move_base will respond to?

2014-04-03 07:12:51 -0500 received badge  Student (source)
2014-04-03 07:09:47 -0500 commented answer Latency when sending goal to move_base and it starting

I'm certain it is not the global planner, the latency is occurring between the time when the client sends the goal out and when the server receives the goal in its goal callback -- this all has to happen before the global planner gets called upon to generate the plan.

2014-04-03 06:51:42 -0500 asked a question Latency when sending goal to move_base and it starting

Hi All,

I'm currently working with the ROS navigation stack. I am using move_base through its actionlib interface. The problem I am experiencing is that I seem to consistently see ~7 seconds of latency between sending the goal through the move_base action client and when the goal begins to execute. Once the server starts executing the goal, the speed is just fine and updates from the action server to client show no significant latency.

I have checked out both the navigation stack and actionlib from github so I could instrument the code to chase down the source of this latency. Specifically, what I have found is that there is a consistent ~7 seconds of latency between the time sendGoal (in simple_action_client.h) returns to when goalCallback (in action_server_base.h) begins to handle the "goal request". I have modified initialize() (in action_server_imp.h) to set TCP_NODELAY on the subscriber to the "goal" topic. One thought was that this message was getting lost in the ROS transport plumbing. Again, making this change seems to have no noticeable effect on this latency issue.

I have a couple of questions:

1) Is this normal / expected behavior? 2) Where should I look next?

If more context is needed, I'm happy to provide. However, we are not doing anything "exotic" in how we are using the advertised functionality. Any help is greatly appreciated.

Best, Tom

EDIT1: I should also note that I have tried instantiating the action client both with and without the extra thread to enable/disable using the global callback queue. Again, no difference.

EDIT2: I'm getting somewhere. My hypothesis is that, in my setup, move_base is subscribed to too many "high frequency / large data" topics. Specifically, 4 sensors sources publishing QQVGA point clouds at 30 Hz. My assumption is that the /move_base/goal topic is sharing the same message queue as these sensor sources (??). Empirically, when I remove two of the input sensor sources, the above described latency drops from ~7 seconds to ~3 seconds. What tipped me off to this was that in a separate shell, I can rostopic echo /move_base/goal and I see the goal published from the action client immediately whereas in the move_base process, I saw the ~7 seconds of latency.

I plan to turn my attention to tuning my sensor sources to get the responsiveness from move_base that I need while not sacrificing fidelity and our perception subsystem. In the meantime, is there a mechanism (I am not aware of one) within ROS that would allow me to partition out the action server's message queue from the sensor topics coming into move_base?

Thanks in advance for any pointers.