pwong's profile - activity

I'm planning to use gmapping to create the 3D environment for our robot, so I'm assemble a tilting hokuyo laser scanner and using the corresponding driver.

For long term, I plan to use the velodyne laser scanner. The issue is the velodyne package appears to be outputting in pointcloud2 format, instead of laserscan format.

I see options such as using the pointcloud_to_laserscan to create the map. There is also ethzasl package I saw recommended on another post, but we need loop closer.

I basically would like to hear your experiences with using a velodyne lidar for a fast/higher quality 3D map or if the tilting hokuyo would be a viable permanent solution.

Any advice is greatly appreciated!

songvanmino, Did setting the param "allow_unknown: false" not do it for you?

Hi all,

I want to make sure that the robot does not plan through the unknow regions of the map. The map looks as follows:

I have set the allow unknown parameter in "base_global_planner_param.yaml" as follows:

NavfnROS:
  allow_unknown: false

and also set the track unknow region parameter in

global_costmap:
  map_type: costmap
  global_frame: map
  robot_base_frame: base_link
  track_unknown_space: true
  unknown_cost_value: 0
  update_frequency: 5.0
  static_map: true

It still plans a path as shown in above image. I have also played with unknown_cost_value parameter, (both 0 and 255), and still no avail.

The objective is to make sure that the robot does not plan apart from a specific region. I intended to edit the map so that i make all the regions grey where i do not want to plan them.

I use a preloaded map and not a live map from gmapping.

Any suggestions are appreciated.

Thanks,

Alex, I'm not sure how you are using your /imu frame, so I cant really answer your first question. In my application, my /base_link is connected to my /odometry frame, so all I had to do was put the roll/pitch straight into my /odometry frame, and my laser scan was fine.

Quick question, how do I publish a multiarray? I use rostopic a lot, and its tremendously helpful. One thing I was never able to figure out, was how publish a multiarray(I also wasn't able to find a post on it).

This is the format it provides:

rostopic pub /topic_name std_msgs/Float32MultiArray "layout:
  dim:
  - label: ''
    size: 0
    stride: 0
  data_offset: 0
data:
- 0"

That can publish a single element multiarray, but I couldn't figure out how to add another element on that array.

I've tried...

rostopic pub /topic_name std_msgs/Float32MultiArray "layout:
  dim:
  - label: ''
    size: 0
    stride: 0
  data_offset: 0
data:
- [0.0, 1.0]"

and a bunch of other variants, but nothing works. If someone can help with the syntax, that would be appreciated!

I'm working on creating a server map using the tutorial:

<a href="http://wiki.ros.org/slam_gmapping/Tutorials/MappingFromLoggedData">http://wiki.ros.org/slam_gmapping/Tutorials/MappingFromLoggedData</a>

The odometry data is being published, and I have a hokuyo utm-30lx laser scanner published as well. My robot is being modeled with a urdf file.

I made sure the hokuyo was perfectly horizontal and then start recording my bag file with this:

>rosbag record -O mylaserdata /scan /tf

After the recording, it plays back into rviz fairly well. Even with all of the scan overlap, it still resembled the room recorded.

The issue comes when I try to turn it into a map with:

>rosrun gmapping slam_gmapping scan:=scan

as soon as I start playing the bag file, it gives me this warning:

[ WARN] [1384916667.376566157, 1384914870.078301371]: Failed to compute laser pose, aborting initialization ("base_link" passed to lookupTransform argument target_frame does not exist. )

This warning repeatedly keeps coming up as the bag is playing. I've also tried:

>rosrun gmapping slam_gmapping scan:=base_scan _odom_frame:=odom

But it gives me the same warning.

1. Am I not correctly recording my tf data into the bag file? Shouldn't the urdf provide the laser pose?

2. The robot_state_publisher is in the topic named '/tf'. Why isn't it my base link from my urdf file? rosbag wouldn't record my base link when I tried.

3. On a somewhat different note, if my odometry data isn't too accurate, what does it mean for gmapping and using the Navigation Stack?

Advice would be greatly appreciated! Thank you.

Edit: I've tried to create the map live with rviz. Similar to how the map was made here.

<a href="http://wiki.ros.org/pr2_simulator/Tutorials/BuildingAMapInSimulation">http://wiki.ros.org/pr2_simulator/Tutorials/BuildingAMapInSimulation</a>

Unfortunately, it still gives me the same error. I thought the error came from the target frame, and tried setting that on rviz. Still nothing.

I also double checked my urdf file, and I don't believe the issue is there. The laser scan is leveled to the laser scanner visualized modeled on the urdf file.

I'm running ros indigo on ubuntu 14.04. I'm having some stability issues regarding nodes being able to subscribe to each other over time. Just trying to do some investigating, I've noticed that some nodes constantly looks for new params and the master log keeps publishing this. Is this normal?

[rosmaster.master][INFO] 2015-10-22 11:04:34,134: +PARAM [/amcl/initial_pose_y] by /amcl
[rosmaster.master][INFO] 2015-10-22 11:04:34,135: +PARAM [/amcl/initial_pose_a] by /amcl
[rosmaster.master][INFO] 2015-10-22 11:04:34,135: +PARAM [/amcl/initial_cov_xx] by /amcl
[rosmaster.master][INFO] 2015-10-22 11:04:34,136: +PARAM [/amcl/initial_cov_yy] by /amcl
[rosmaster.master][INFO] 2015-10-22 11:04:34,137: +PARAM [/amcl/initial_cov_aa] by /amcl

I'm also looking for documents or anything would would show me how to understand the master.log, so I know if something is behaving properly or not.

Thank you!

I've noticed that every time I have a new node subscribe to a topic, a new file gets created on .ros/log called rostopic_xxxx_xxxxxxxxxxxxx.log

I run rosbag at 1 minute intervals so I create a ton of files, to a point where a rm rostopic* would fail because there are so many files. This folder just gets to be so clustered that if I try to use it when I need it, I have a hard time finding what I need.

Here are a few specific questions I would like to ask about managing the logging:

1. Is there a way to limit writing of the rostopic_xxxx_xxxxxxxxxxxxx.log files?

2. Whats the reason for the rostopic.log files to not get written into folders?

3. Is there something built in I can configure without writing a script to manage the files?

4. When does a new folder like ~/.ros/log/fdfa58c8-cf58-11e4-b18e-78d00420d50e get written?

I'll edit the post as I find out more about it.

Thanks!

Edit:

Long since I've made the question, but I have learned more about it since. Here's a couple answers I've figured out.'

1. rostopic.log is created every time an 'rostopic echo' is called, or running a node. Only when ros is run through roslaunch, all of the nodes are inside a folder.

2. Just better house keeping with rosclean worked out for me.

3. See answer 1.

The ground usually isn't completely flat, so what I like to do is add a roll and pitch from an IMU to correct the laser scan frame before using it for gmapping and amcl.

I was planning to use http://wiki.ros.org/hector_imu_attitu... to publish base_frame with the roll and pitched added, and add the laser frame to base_frame.

The IMU on the robot is offset by a translation and rotation from the actual base link. hector_imu_attitude_to_tf just takes roll and pitch from sensor_msgs/Imu published, and publishes the TF. But what I need to do, is find roll and pitch of base frame from my IMU, and not just take the roll and pitch directly from the IMU itself.

Is there a way to find roll/pitch of base_frame from using TF as it is? Or is it something which requires calculation on my end and republish the IMU message before sending it into hector_imu_attitude_tf?

The system being run is ROS indigo on ubuntu 14.04. Thank you!

I was over thinking it. As long as the IMU was mounted on the robot rigidly, the roll and pitch doesn't need additional transforms/conversions done to the values themselves.

I ended up not using the hector_imu_attitude_to_tf node. My constraint was having an IMU be mounted with a rotation of -3.14 radians(in the x direction). I subscribed to the imu topic(add the offset), then included the roll/pitch to the base_link transform and odometry.

I don't think the hector_imu_attitude_to_tf_node allows for an imu which is mounted in a different orientation as the base_link.

Turns out it was a misuse of using the clear cost map service on my end which was causing the path planning issue. Adding the "base_global_plannar_params.yaml" file with "allow_unknown: false" did fix the problem. If someone can confirm this was the proper fix, please let me know.