SaiHV's profile - activity

Hello all,

I have an application where I am using the turtlebot simulator with move_base for some navigation related tasks. So generally, if a goal is specified, I am assuming the nav stack comes up with a spline for a large set of points that when passed through, take the robot there. If I have my own (sufficiently large) set of waypoints; is there a way to avoid stopping at every waypoint and rather let the robot drive through them like a curve?

Thanks, Sai

Hello,

I have a PGM/YAML map generated from hector SLAM from a Hokuyo LIDAR driven around by an iRobot Create. I was trying to use AMCL for localization and simple 2d nav goals, but it seems to be very problematic for some reason.

The brown pkg provides the /odom and /tf, and I use map_server to publish the /map topic. I ran the hokuyo_node (laser scans published on /scan) and then rosrun amcl amcl.

1. AMCL outputs:

No laser scan received (and thus no pose updates have been published) for 1367364115.808416 seconds. Verify that data is being published on the /scan topic. MessageFilter [target=/odom ]: Dropped 100.00% of messages so far. Please turn the [ros.amcl.message_notifier] rosconsole logger to DEBUG for more information.

1. The /map subscription in rviz shows: No transform from [map] to [/base_link]

If I go through hector_slam, it looks like it's estimating the /odom topic from the laser scan itself, but there's no localization feature. Any suggestions as to what might need to be changed to make AMCL work with the Create's odom/tf on a known map?

Thank you Sai

Hello, I am trying to synchronize the callbacks for two topics, one of them, a geometry_msgs::PoseStamped message that acts as a signal for image capture from another computer (just using PoseStamped as a test case for now because it comes with a timestamp, will write own message type later on), and then the actual image topic of type sensor_msgs::Image. This is the code snippet that's doing the approximate time synchronization.

void callback(const geometry_msgs::PoseStamped& signal, const sensor_msgs::ImageConstPtr& rightimage)
{
   ROS_INFO("Reached callback");
   cv_bridge::CvImagePtr imgPtr;
   std::stringstream imgPath;

   //More code
}
typedef sync_policies::ApproximateTime<geometry_msgs::PoseStamped, sensor_msgs::Image> ApproxSyncPol;

Subscriber<geometry_msgs::PoseStamped> signal_sub(nh, "/signal", 1);;
Subscriber<sensor_msgs::Image> image_sub(nh, "camera/image_mono", 1);

Synchronizer<ApproxSyncPol> syncPol(ApproxSyncPol(10), signal_sub, image_sub);

syncPol.registerCallback(boost::bind(&callback, _1, _2));

This code fails to compile with a lot of errors, mostly relating to boost and the Approximate Time sync_policies statement. An excerpt:

 /opt/ros/indigo/include/message_filters/signal9.h:273:23:   required from ‘message_filters::Connection message_filters::Signal9<M0, M1, M2, M3, M4, M5, M6, M7, M8>::addCallback(C&) [with C = const boost::_bi::bind_t<void, void (*)(const geometry_msgs::PoseStamped_<std::allocator<void> >&, const boost::shared_ptr<const sensor_msgs::Image_<std::allocator<void> > >&), boost::_bi::list2<boost::arg<1>, boost::arg<2> > >; M0 = geometry_msgs::PoseStamped_<std::allocator<void> >; M1 = sensor_msgs::Image_<std::allocator<void> >; M2 = message_filters::NullType; M3 = message_filters::NullType; M4 = message_filters::NullType; M5 = message_filters::NullType; M6 = message_filters::NullType; M7 = message_filters::NullType; M8 = message_filters::NullType]’

 /opt/ros/indigo/include/message_filters/synchronizer.h:310:40:   required from ‘message_filters::Connection message_filters::Synchronizer<Policy>::registerCallback(const C&) [with C = boost::_bi::bind_t<void, void (*)(const geometry_msgs::PoseStamped_<std::allocator<void> >&, const boost::shared_ptr<const sensor_msgs::Image_<std::allocator<void> > >&), boost::_bi::list2<boost::arg<1>, boost::arg<2> > >; Policy = message_filters::sync_policies::ApproximateTime<geometry_msgs::PoseStamped_<std::allocator<void> >, sensor_msgs::Image_<std::allocator<void> > >]’

  /usr/include/boost/bind/bind.hpp:313:34: error: invalid initialization of reference of type ‘const geometry_msgs::PoseStamped_<std::allocator<void> >&’ from expression of type ‘const boost::shared_ptr<const geometry_msgs::PoseStamped_<std::allocator<void> > >’
       unwrapper<F>::unwrap(f, 0)(a[base_type::a1_], a[base_type::a2_]);

But this same structure works perfectly, if both topics are sensor_msgs::Image. I am not getting what I'm doing wrong here, because geometry_msgs::PoseStamped is a message that does contain a timestamp.

I have two computers, each connected to a camera and on the same wireless network; and I want them to capture and log images simultaneously using ROS. If I had multiple cameras on the same machine, I would have gone for ApproximateSyncPolicy, but because this is decoupled and over wireless, I was wondering if it's a good method to subscribe to camera1 on machine1, and every time the callback for this is reached, I publish a 'signal' over another topic for machine2 to listen to. So the flow would be:

image1 read on machine1 -> signal sent to machine2 -> image1 saved on machine1, image2 saved on machine2

Would this be an efficient approach, or is there a better way of doing this?

class SubscribeAndPublish
{
public:
SubscribeAndPublish()
{
  pub_ = n_.advertise<std_msgs::String>("/signal_topic", 1);
  sub_ = n_.subscribe("/camera/image_mono", 1, &SubscribeAndPublish::callback, this);
}

void callback(const sensor_msgs::ImageConstPtr& image)
{
  std_msgs::String output; //some number or string
  pub_.publish(output);
  // Once the other machine is signaled, read and save the local image, expecting the same to happen there
}

Hello,

I have a PGM/YAML set map that was generated from a Hokuyo LIDAR with an iRobot Create, and the objective is to use OMPL's libraries for motion planning in this map. I have the OMPL GUI, but there seems to be no straightforward way to use user generated maps, and all the example maps are in .dae format. ROS tutorials always seemed to talk about PR2 arm navigation.

I would greatly appreciate any suggestions as to how I can start off using OMPL's algorithms for navigation in my own map. Thank you.

Hello,

I am trying to implement concepts such as entropy of a map and information gain through 3D sensing, where I am storing my map data as an Octomap. I am a beginner when it comes to concepts like this, so I have been reading up recently on information theory and how the concepts of entropy, mutual information etc. work, but I am failing to grasp how to implement something like that practically. Given a certain scene and associated Octomap data, is the whole set of cells treated as a probability distribution which then can be used to determine entropy? Or is there a pre programmed straightforward way of determining the entropy of the map at a given instant? Any suggestions/inputs would be very welcome.

Thanks, Sai

Did you do a catkin_init_workspace and catkin_make? And then source the devel/setup.bash, or just add it to .bashrc?

Hi Daniel, I don't know if you've already solved this issue, but this is being caused by some comments in the xacro files which have the middle dot. A solution has been posted in the github issues section of rotors_simulator.

https://github.com/PX4/rotors_simulat...

Hi, I am currently using openni_tracker to tele-op a robot arm using an RGBD sensor. I am able to obtain the joint positions and orientations using openni_tracker, which publishes a TF with respect to the camera frame for every joint. I am getting confused when I think about how I can convert this into relative orientation of each joint, which I can then pass to t he robot control. For each joint, I am interested in two angles: the up-down motion angle and the sideways angle, and I feel that TF is giving me way more data than what's really relevant to me. Any suggestions will be very helpful.

Thanks, Sai

Did you try changing the fixed frame in rviz?

Here's a thought: You have 10 m/s as your max. vel in x, but 1 m/s for theta. May be it's just slow because of the difference? Are you using the turtlebot files and parameters in the nav stack? Did you tweak any of the files?

Hi, try this.

1. Download hector_slam fro here. http://wiki.ros.org/hector_slam
2. Do a roslaunch hector_mapping mapping.launch
3. Then do a roslaunch faketf.launch from whichever directory you have the faketf.launch

Can you try removing the <remap from="scan"> line?

So it just keeps going straight and misses the goal?

It looks like you're using /depth/image_raw in your nodelet and /camera/depth/image_raw in your rosrun command.

If you're using a laser scanner, using hector_mapping can be easier than gmapping. Launch the mapping program and publish a 0,0,0 static transform between base_link and laser to account for your non existent odometry and you should be set.

<node pkg="tf" type="static_transform_publisher" name="base_to_laser_tf" args="0 0 0 0 0 0 base_link laser 100"/>

Just my two cents.

If you have a Hokuyo laser, hector_slam is much better than gmapping for mapping purposes.

Looks like moveit is not able to find the planning plugins properly. How was moveit installed? Did you do a ros-indigo-moveit-full?

Some well used, although not technically "state-of-the-art", algorithms are implemented in OMPL, which have support for dynamic collision avoidance. It is available for ROS through moveit.

http://wiki.ros.org/ompl

http://wiki.ros.org/moveit

I have, yes. Octomap comes in the box with moveit, so once you set up your move_group launch files, all you need to do is edit the sensor_manager.launch.xml and add the parameters of your camera there. For more info:

https://groups.google.com/forum/#!top...

In base local planner, there is a file called latched_stop_rotate_controller.cpp. In that function, the stop command is implemented using LatchedStopRotateController::stopWithAccLimits() [line 108] which uses acc_lim as an argument. I think you can define your own, say, decel_lim and use that instead in this function. I am not entirely sure as to whether they should be kept the same from the code's perspective though.

Hi all,

I am trying to do 3D navigation using a quadrotor and moveit, using mavros as an interface. I am using hector_quadrotor_urdf as my robot description for MoveIt. I just had a couple of questions about the whole ROS pipeline, it would be great if someone can provide a few inputs.

1. I have a fixed frame called /world to which /base_link is attached (floating). The mavros messages are under the fixed frame /fcu. Would publishing a tf between /base_link and /fcu suffice to introduce this data (IMU etc.) into /world?

2. If I use hector_quadrotor in simulation, the robot position is published through gazebo ground truth data. With the real MAV, mavros returns a sensor_msgs/IMU and a geometry_msgs/PoseStamped message that deal with the robot position. Is there a good way of integrating this into moveit? Because for now, the robot always faces forward and the occupancy map is updated only directly in front of the robot wherever it is moved.

Thank you,

Sai

Not really sure, but I have been using moveit to perform 3D navigation using a quadrotor and its path planning, obstacle avoidance etc is quite good.

There is an A* for nav_core on github.

https://github.com/ros-planning/navig...

Also, if you don't mind moving away from the nav_core interface, you can use a simple urdf model for your robot and then implement MoveIt! so you can use OMPL, SBPL etc.

Hi, I am having the following error when I try to visualize the octomap occupancy map in rviz.

    [ WARN] [1409157693.871637407]: OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface on texture MapTexture0 face 0 mipmap 0. Probably, the GL driver refused to create the texture. in GLTexture::_createSurfaceList at /build/buildd/ogre-1.8-1.8.1+dfsg/RenderSystems/GL/src/OgreGLTexture.cpp (line 420)
    [ WARN] [1409157693.872059551]: Failed to create full-size map texture, likely because your graphics card does not support textures of size > 2048.  Downsampling to [2048 x 1861]...
    [ WARN] [1409157693.877818283]: OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface on texture MapTexture0Downsampled face 0 mipmap 0. Probably, the GL driver refused to create the texture. in GLTexture::_createSurfaceList at /build/buildd/ogre-1.8-1.8.1+dfsg/RenderSystems/GL/src/OgreGLTexture.cpp (line 420)

terminate called after throwing an instance of 'Ogre::RenderingAPIException'
  what():  OGRE EXCEPTION(3:RenderingAPIException): Zero sized texture surface on texture MapTexture0Downsampled face 0 mipmap 0. Probably, the GL driver refused to create the texture. in GLTexture::_createSurfaceList at /build/buildd/ogre-1.8-1.8.1+dfsg/RenderSystems/GL/src/OgreGLTexture.cpp (line 420)
Aborted (core dumped)

I am running ROS Indigo on 14.04, and I believe 14.04 has native support for Optimus graphics, so my graphics card should be usable. rviz page says that this issue was fixed in version 0.3 though. For further information, occupancy grid is displayed well, but just the map crashes rviz. I tried reducing the resolution through octomap's launch file, but the same issue persists. Are there any known fixes to this?

Thanks!