ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2016-12-12 07:25:30 -0500 | received badge | ● Nice Answer (source) |
2016-02-01 10:05:57 -0500 | received badge | ● Guru (source) |
2016-02-01 10:05:57 -0500 | received badge | ● Great Answer (source) |
2015-06-29 20:24:39 -0500 | received badge | ● Good Answer (source) |
2015-06-10 05:00:42 -0500 | received badge | ● Good Answer (source) |
2015-04-14 08:25:04 -0500 | received badge | ● Great Answer (source) |
2015-04-14 08:25:04 -0500 | received badge | ● Guru (source) |
2013-08-20 21:49:29 -0500 | received badge | ● Good Answer (source) |
2013-07-28 21:11:09 -0500 | received badge | ● Good Answer (source) |
2013-03-03 23:09:11 -0500 | received badge | ● Nice Answer (source) |
2013-01-18 13:51:41 -0500 | answered a question | amcl no laser data received I would guess that there's a problem in your tf tree. The laser callback in amcl is at the end of a tf message filter that will fire when the incoming scan can be successfully transformed into the odom frame. It would seem that that condition is never satisfied. I suspect that if you try to visualize the laser data in rviz in whatever frame you've specified as the odom_frame for amcl, you won't see any data there, either. The solution depends on what exactly is wrong in your tf tree. Try visualizing transforms in rviz. |
2012-11-27 06:28:23 -0500 | answered a question | ARM: Buffer Overrun debug help I would guess that your ARM machine is configured to run big-endian. The ROS communication protocol uses little-endian on the wire and as far as I know, Adding big-endian support to But you can likely work around your problem by configuring your ARM machine to run as little-endian instead of big-endian. There's usually a way to do that. Btw, I would expect |
2012-10-29 05:42:48 -0500 | received badge | ● Nice Answer (source) |
2012-10-17 09:54:08 -0500 | received badge | ● Guru (source) |
2012-10-17 09:54:08 -0500 | received badge | ● Great Answer (source) |
2012-10-10 12:17:02 -0500 | received badge | ● Good Answer (source) |
2012-07-25 07:59:33 -0500 | received badge | ● Guru (source) |
2012-07-25 07:59:33 -0500 | received badge | ● Great Answer (source) |
2012-07-20 02:02:33 -0500 | received badge | ● Nice Answer (source) |
2012-07-10 08:41:36 -0500 | received badge | ● Good Answer (source) |
2012-07-07 19:15:16 -0500 | received badge | ● Nice Answer (source) |
2012-06-22 13:36:39 -0500 | answered a question | Are these features possible with ROS/Stage? All of those feature should be implementable, with enough work. You would start by deconstructing the code for stageros and augmenting it with the features that you want. Basically, you'd end up writing your own ROS wrapper for libstage, with the extra functionality that you want. I expect that the toughest part will be the graphical selection of robots and execution of ROS code, because that may require modifying libstage's GUI hooks. Fair warning: you'll be coding in a space that is not well exercised by other people, and so you'll likely end up diving into the libstage code itself to understand what's going on. Sorry that I can't provide more guidance than that; if I were doing this, I would start by reading the libstage headers to see what's possible. |
2012-06-18 06:05:28 -0500 | received badge | ● Good Answer (source) |
2012-06-09 10:14:11 -0500 | received badge | ● Guru (source) |
2012-02-29 18:29:13 -0500 | received badge | ● Nice Answer (source) |
2012-01-10 16:20:05 -0500 | received badge | ● Great Answer (source) |
2012-01-10 16:20:05 -0500 | received badge | ● Guru (source) |
2011-12-12 01:20:25 -0500 | received badge | ● Great Answer (source) |
2011-12-12 01:18:01 -0500 | received badge | ● Necromancer (source) |
2011-12-09 02:55:35 -0500 | answered a question | gmapping simulation I'm not sure that I completely understand your use case. But here's something that might be useful: you can selectively filter messages from a .bag. E.g., to get all the non-tf messages, plus only those tf messages that encode a particular transform: I often do something like this to remove the map->odom transform from a bag so that I can test amcl or gmapping. |
2011-12-08 12:51:24 -0500 | edited answer | Launching with parameters (was "How to block until a master is running") I'm not sure that I fully understand your use case, but you might try roslaunch args. Here's a launch file that sets two params from arguments: Defaults for the args are given, so you can launch it normally: But you can override them on the command-line, e.g.: |
2011-12-08 10:01:50 -0500 | commented answer | Rosbag cannot record multiple topic with same type That's definitely a symptom of the problem addressed in #3755. It'll probably be a day or two before new debs are available. A lot of stuff depends on ros_comm, which means that a lot of debs need to be (re)built. The build farm is chugging away now... |
2011-12-08 02:43:09 -0500 | commented answer | trying to play back images from multiple cameras in rxbag causes both videos to flip between cameras Definitely sounds like it could be the bug that @dornhege pointed to. Does `rosbag info` show that both of the image topics are in the .bag file? If you post your .bag somewhere, I can have a look at it. |
2011-12-06 17:44:05 -0500 | received badge | ● Good Answer (source) |
2011-12-06 05:34:04 -0500 | received badge | ● Nice Answer (source) |
2011-12-06 01:22:04 -0500 | answered a question | open-source distance query library I don't know whether it's ready for use, but maybe FCL can do what you need. |
2011-12-06 01:19:04 -0500 | answered a question | What is ROS exactly? Middleware, Framework, Operating System? I usually explain ROS in the following way:
In the early days, the plumbing, tools, and capabilities were tightly coupled, which has both advantages and disadvantages. On the one hand, by making strong assumptions about how a particular component will be used, developers are able to quickly and easily build and test complex integrated systems. On the other hand, users are given an "all or nothing" choice: to use an interesting ROS component, you pretty much had to jump in to using all of ROS. Four years in, the core system has matured considerably, and we're hard at work refactoring code to separate plumbing from tools from capabilities, so that each may be used in isolation. In particular, we're aiming for important libraries that were developed within ROS to become available to non-ROS users in a minimal-dependency fashion (as has already happened with OMPL and PCL). |
2011-12-05 22:47:36 -0500 | received badge | ● Good Answer (source) |
2011-12-05 12:09:41 -0500 | received badge | ● Good Answer (source) |
2011-12-05 11:24:52 -0500 | received badge | ● Nice Answer (source) |
2011-12-05 10:26:41 -0500 | answered a question | ROS and C++11 According to REP 3: "We use the C++03 (ISO/IEC 14882:2003) standard, and are compiler-agnostic. While we mainly develop with gcc, no use of compiler-specific features is allowed without proper use of macros to allow use on other platforms. Use of C++[0|1]x or tr1 features are only allowed if support for that feature is checked at compile time, and equivalent functionality exists without requiring C++[0|1]x code. A wholesale jump to C++[0|1]x will not happen until all commonly used OS platforms fully support it." |
2011-12-05 08:41:15 -0500 | commented answer | Effects of manually editing gmapping maps? Good point, and I would expect that to be the case. In my answer, I was only addressing localization performance, not path-planning or overall navigation performance. Removing stray obstacles will help global path-planning (local planning will generally overwrite static map data with sensor readings). |
2011-12-05 06:03:28 -0500 | received badge | ● Nice Answer (source) |
2011-12-05 01:47:39 -0500 | answered a question | Effects of manually editing gmapping maps? Cleaning up the map as you're suggesting shouldn't hurt localization performance, but probably won't help either. By default, If you compare performance with both maps, I'd be interested to know the results. |
2011-12-01 06:48:02 -0500 | received badge | ● Nice Answer (source) |
2011-11-28 07:53:15 -0500 | commented answer | rxgraph No module named gobject (OS X) I have the same problem with OSX 10.7.2, electric, and brew install. |
2011-11-27 01:27:07 -0500 | received badge | ● Guru (source) |
2011-11-27 01:27:07 -0500 | received badge | ● Great Answer (source) |
2011-11-20 03:30:39 -0500 | answered a question | AMCL doesn't work well with my robot It looks like your robot may have an under-reporting bias in its odometry. Try this sanity check to get an idea of how just odometry + laser looks. |
2011-11-20 03:29:45 -0500 | commented question | AMCL doesn't work well with my robot What kind of robot and laser are you using? |