ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
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 |
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 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 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 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 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. |