Morgan's profile - activity

VPN is a good approach to making ROS 1 work across the Internet. It can just be a bit tricky to get all the bidirectiona

Just some random ideas: I'd suggest rendering the costmaps in rviz to see if something looks odd (maybe a LIDAR hit some

Ah, yeah, if you're wanting to work on the leading-edge stuff and make PR's back to the main/master branches of the upst

Welcome! Thanks for your interest in contributing to ROS 2. These instructions: https://index.ros.org/doc/ros2/Installa

ROS 1 is designed to run with a single roscore. You can play various games to make nodes from one roscore talk to anothe

Any chance the baud rate is not as expected? The bytes don't look ASCII, so maybe try a bunch of other baud rates like 5

Do you have a specific application or scenario in mind, or is this a generic question? I'll just answer generically: th

Hi! Yes, we'll be adding documentation and publicly-viewable examples / tutorials to the repo.

We're actively investigating this right now. No updates yet, but we've restarted Apache a few times already today to try to keep things alive while we search for the root cause.

These debugging steps are a great place to start. Without seeing the whole program it's hard to know, but perhaps you're publishing a single point cloud immediately after calling advertise() ? Since the peer-to-peer connections take time to set up, it's recommended to (re)publish topics periodically

Hi zezefreda,

Of course I'm biased since I work at OSRF, but I use Gazebo! It has its own Answers forum, which may be of interest to you. The Gazebo website also shows off many use cases.

Best regards,

Morgan

where do you see the error? In RViz or somewhere else? Can you copy the full text and path of the file you have modified?

can you upload /home/lucasw/catkin_ws/src/robot_description/urdf/no_cable.xacro somewhere (or, some other minimalist example which shows similar behavior) so that we can try to replicate the failure? Thanks!

You don't need to run stereo_image_proc, you just want to publish the same topics and parameters as it does. In theory at least, the downstream subscribers of stereo/points (for example) aren't concerned with how the disparity and depth maps were produced.

i'll edit my answer and attempt to include some suggestions in a longer post

It's possible the default log level for move_base is lower than expected. Are you printing log messages in your custom planner plugin with a high level (i.e., ROS_ERROR) ?

hmm, I wonder if the custom global planner plugin is causing move_base to crash immediately on startup, even before the log file is created. Can you try it again without the custom global planner plugin, and see if then the log file appears as expected?

Hi Vinh, again, lots of approaches are valid here, but one would be to make a "cluster mega-launch file" that has six <include> tags that specify the __ns attribute differently for each robot. That way, their nodes won't collide in the ROS namespace.

can you post the contents of that directory? e.g., ls -l /home/sebastian/.ros/log/6c0459b4-42bc-11e5-91ba-c8f733552779

I'm not sure I fully understand what you're trying to do, but in general if you want to specify points relative to the robot (i.e., "behind the robot"), you want to define those points in a spatial frame attached to the robot, such as /robot or /base_link or something like that. Then, you'll need to have some other spatial transform to take this frame to the world frame, such as a localization algorithm, a static transform (for a stationary robot), or some other node which publishes the transform from /robot to /world. Then, you can use tf to transform the points to whatever spatial frame they are needed in for whatever other tasks the system is performing.

Hi Walter,

There are lots of valid approaches here, but one reasonable approach would be to try to (as closely as possible, anyway) create a ROS node that matches the topic and parameter names of the stereo_image_proc node, which lots of people would be familiar with already.

Cheers, -mq

Have you tried this configuration and motion plan using the MoveIt GUI (in rviz)? That may help determine why IK is saying the pose is unreachable. It's easy to flip a sign on the end-effector orientation, in particular, which would cause the wrist to have to go the wrong direction and thereby cause the workspace to be much smaller. Visualizing the poses in the MoveIt GUI often makes it much easier to see what's happening with IK, since you can drag the end-effector around interactively.

The setup you describe sounds quite reasonable. As you said, you will need to install ROS on both the Raspberry Pi and the laptop. They will talk to each other via wifi. The Raspberry Pi could talk to the arduino any number of ways, but you could start by taking a look at rosserial_arduino for some examples of getting communications up and running between Arduino widget and ROS.

You could run the ROS master (aka "roscore") on either side of the Wifi link, since you're teleoperating the robot and will be developing code actively for a while. If you eventually want to have the robot run autonomously and launch everything at power-up, many people run the ROS master on the robot to ensure that the robot's internal nodes connect regardless of the network status, but that's not terribly important when you are in the initial phases of hacking the system together.

This is hard to read because the code is not fully formatted. Can you edit your post so that all code is highlighted and indented properly in a single code block? Thanks

This TF tutorial will be a good starting point; it listens to the TF topic and calculates the requested transform in the listener.lookupTransform call.

This looks like a C++ syntax error in hello.cpp . Can you post that file?

We'll need more of an explanation of the question and your starting point, in order to give meaningful suggestions. Can you explain further?

Yes, every terminal that needs to work with the package(s) you are developing in your workspace needs to source the devel/setup.bash file from the workspace. I will typically set up a bash alias for the most common workspace I'm using, so you can just type "w" or whatever, to make it fast and easy.

There are lots of different strategies, but when debugging transform frames I find that the tf plugin in rviz is helpful.

That error message is a bit confusing. It is just saying that the plane of the laser needs to be parallel to the ground plane. I would check the transform chain you are using (i.e., what is the orientation of base_link) and make sure it has z facing directly up or down. You can do this in rviz using the tf plugin.

if you're curious, the code producing the error message can be found here

This could be happening for a few reasons (I know some of these are obvious, I'm just going through the list of things I try to verify when debugging such a problem):

1. Have you sourced the devel/setup.bash from your workspace into your current shell ? Otherwise, roslaunch won't know where to look to find the beginner_tutorials files, including turtlemimic.launch you can verify that your current shell knows about the beginner_tutorials location by running rospack list | grep beginner_tutorials and verifying that your package directory shows up in the location you expect.
2. Is the file named exactly turtlemimic.launch, and is it somewhere in the beginner_tutorials directory tree? Note that if it is somewhere in the workspace (e.g., the workspace root) rather than in the src/beginner_tutorials directory tree, roslaunch will not be able to find it.
3. Make sure the launch file is valid XML that starts with a launch tag.

Can you copy/paste the command that produced that error message?

First, I would suggest setting the use_sonar parameter using a ROS launch file rather than changing and recompiling the p2os_driver code, so that you can more easily modify the parameter setting in the future, or (perhaps more usefully) you can have multiple launch files for various application configurations, perhaps some that use the sonars and some that do not.

But in regards to the main question, there are many ways to do this. For example, you could convert the sonar readings to a point cloud. But that doesn't really capture what a sonar is doing. To get a nice visualization in rviz that more accurately represents the (large) sensitivity cone of each sonar, you could the sensor_msgs/Range datatype, which you can visualize in rviz.

I have not done this myself yet, but I believe you need to define the coordinate frame of each sonar, using something like static_transform_publisher to define static offsets relative the the frame of the robot. Then for each message you receive on the /sonar topic, you would send out a bunch of sensor_msg/Range messages, one for each sonar.

All that being said, I don't have access to a Pioneer anymore, so I haven't tried any of this myself. Perhaps one of the Pioneer users will have a better idea.

Can you post a screenshot of the map that is being generated? Unfortunately, there are many ways that mapping can fail. Perhaps if we see the failed output, we can give some suggestions. Starting with very small maps is usually best, and only going for large areas once the tiny maps are working.