Buscar este blog

miércoles, 2 de febrero de 2011

Reconfiguring sicklms node

Well, after reinstalling everything in my computer and losing all my backup data (I dropped my external hard drive ¬¬), I have ROS running again.

I had some issues while configuring the sicklms node. I downloaded the original code from a ROS repository and the following error was being displayed:

A scan was probably missed. The last scan was 0.10704 seconds ago. sicklms.

I sent my inquiry to the mailing list and this was the answer.

"See https://code.ros.org/trac/ros-pkg/ticket/4673 for a ticket about that warning. How is your SICK connected to the computer? RS232 or RS422? With or without a USB->Serial adapter? At what rate should you be getting scans from the LIDAR as currently configured? 10Hz?

Is the SICK driver set to less than one degree of angular resolution? I only see this warning with my LMS291's when they are set to 0.5 degree angle increments. With 1 degree increments the warning is not output."
 
So I downloaded the code that the SSC Rovers team uses for the sicklms and it, i fact, had some differences with the degree angle increments. 
 
  }
  if (inverted) {
    scan_msg.angle_min = M_PI/2;
    scan_msg.angle_max = -M_PI/2;
  } else {
    scan_msg.angle_min = -M_PI/2;
    scan_msg.angle_max = M_PI/2;
  }
  scan_msg.angle_increment = (scan_msg.angle_max - scan_msg.angle_min) / (double)(num_values-1);
  scan_msg.scan_time = scan_time;
  scan_msg.time_increment = scan_time / (double)(num_values-1);
  scan_msg.range_min = 0;
  if (scale == 0.01) {
    scan_msg.range_max = 81;
  }
  else if (scale == 0.001) {
    scan_msg.range_max = 8.1;
  }
 
 


 



 

miércoles, 12 de enero de 2011

usb_cam and rviz compilation

While I am waiting for the Logitech Pro 9000 camera to arrive I am provisionally working with an IBM webcam.

Today I installed and compiled the usb_cam package created by bosch.

The repository was taken from the following source: https://bosch-ros-pkg.svn.sourceforge.net/svnroot/bosch-ros-pkg/trunk/stacks/bosch_drivers/usb_cam

And the only trouble I went through during compilation was the following message: mkdir: cannot create directory `build': Permission denied

This problem was solved by changing the permissions of the directory using chmod as follows:

$ sudo chmod ugo+rwx usb_cam

Aftewards, I tested rviz's execution (since I am using a new laptop because my own is going through some BIOS dilemmas... long story...). And while i was compiling I got the following error:

Caught exception while loading: OGRE EXCEPTION(7:InternalErrorException)

It was easily solved by installing some of the missing packages of my video card:

$ nvidia-cg-toolkit-installer --install

I am currently trying to recover the configuration of my laptop without losing any data in order to continue with my navigation tasks. Meanwhile I am starting to make some tests with the mentioned camera.

martes, 7 de diciembre de 2010

Move base: comments on particle cloud part II


I have figured out a transform tree that avoids the previously displayed warn:

Dropped 100.00% of messages so far. Please turn the [ros.costmap_2d.message_notifier] rosconsole logger to DEBUG for more information.

What I did was the following:

1. Run the Ariaoriginal node.
2. For the odom->base_link->base_scan tf I used Pablo's tf, the one I have previously used for mapping.
3. Run gmapping in order to make the tf map-> removing the scan:=base_scan parameter.
4. Run move_base.launch.
5. Run rviz.

The actual problem is that the robot's footprint isn't positioned when I click the 2DPose Estimate button. The conflict according to rviz is that the messages from the particlecloud topic aren't being received. In order to diagnose the problem I

1.Run rostopic info in order to know more about the particlecloud topic.

2. Run rxgraph and verify that the node is actually establishing communication between amcl and rviz. I am not sure if move_base should be involved as well.

3. I run rostopic echo particlecloud and nothing is displayed meaning that, in fact, no messages are being published.

I now have to inquire on the nature of this topic.

The final observation I have is that what stopped the Dropped messages warn from being displayed was that I dind't run the sicklms topic which I thik shouldn't be happening since the localization might use information from the laser as the tf tree includes it's frame. I might be wrong, however, and discover that only odometry is needed.

Standard Units of Measure and Coordinate Conventions on ROS

I found a useful link concerning measurement conventions on ROS: http://www.ros.org/reps/rep-0103.html.

This link talks about the convention of coordinate frames: http://www.ros.org/reps/rep-0105.html

lunes, 6 de diciembre de 2010

Move base: comments on particle cloud

The robot's footprint is correctly being displayed in rviz.



The particle cloud isn't. The warning message displayed indicates no messages are being received. However, when displaying rxgraph, we can observe that the topic particle cloud is being published by amcl and rviz is subscribing to it.

Here is the result of displaying the roswtf debug tool where we can observe that the topic /particlecloud isn't disconnected:

Suddenly, the following error was displayed by the move_base node and was shown as well in rxconsole:





Move_base: Comments on map_server

According to the tutorial Using rviz with the navigation stack: http://www.ros.org/wiki/navigation/Tutorials/Using%20rviz%20with%20the%20Navigation%20Stack

The map should be displayed by the nav_msgs::GetMap service. However, the message displayed by the map service in rviz with the configuration I am running is nav_msgs::OccupancyGrid. This message is published by the map_server node.

I don't really think this is a problem however. The map is still displayed in rviz and the move_base node identifies it and accepts it.

Another conflict I had at the beginning was that running gmapping during the process caused the current laser's view to be displayed instead of the .png map. I couldn't stop running this node since it is in charge of the map-odom transform. My solution to the problem was to eliminate the scan:=base_scan parameter from my launch file.

Now, the .png map is being displayed.