Buscar este blog

miércoles, 9 de marzo de 2011

Verifying network connection with Player/Stage

1. This is the cfg file that includes the p2os driver:


driver
(
name "p2os"
provides ["position2d:0" "power:0" "sonar:0"]
port "/dev/ttyUSB0"
safe 1
)

2. I first connected Pio to lola and verified the functionality of both the cfg file and the playerjoy interface. Everyting worked fine.

$ robot-player pio.cfg
$ robot-playerjoy

3. I then ran the playerjoy interface on XPS including lola's IP and the port to which player listens (6665). And once again, everything worked just fine.

(on XPS) $ robot-playerjoy 10.48.56.34:6665

4. I then inverted roles and ran the cfg file on XPS. I verified playerjoy's functionality both in XPS and lola and the following error message was being displayed:

create and bind socket():bind() failed; socket not created.: Adress already in use player.

5. By reading forums I figures out that perhaps the problem had to do with the firewall so I enabled in ins XPS and enables access of both hosts to port 6665.

On XPS (10.48.61.241) which had the problem:

$sudo ufw enable
$sudo ufw alow proto tcp from 10.48.61.241 port 6665.
That solved the problem
 
6. Now I have to figure out if ROS' issues have to do with the firewall as well, but I am not sure
in which default port does it listens. It is perhaps 11311 

martes, 8 de marzo de 2011

Running ROS on multiple machines


I am working with two computers: lola and XPS with known IP adresses.
In order for them to identify each other as hosts I indicated their IP adresses on etc/hosts:

10.48.56.34 lola
10.48.61.241 XPS

1. First, they need to ping each other.

On lola:

$ssh lola
$ping XPS

Something like this appears:

PING XPS (10.48.61.241) 56(84) bytes of data.
64 bytes from XPS (10.48.61.241): icmp_seq=1 ttl=64 time=4.35 ms
64 bytes from XPS (10.48.61.241): icmp_seq=2 ttl=64 time=4.79 ms
64 bytes from XPS (10.48.61.241): icmp_seq=3 ttl=64 time=3.65 ms
And then on XPS

$ssh XPS
$ping lola

"ping only checks that ICMP packets can get between the machines, with isn't enough. You need to make sure that you can communicate over all ports.
In lieu of a complete check, you can use netcat to try communicating over an arbitrarily selected port. Be sure to pick a port greater than 1024; ports below 1024 require superuser privileges."

3. I use netcat in order to verify that port 3333 allows communication.

 On lola:

$ nc -l 3333

Then on XPS

$ nc lola 3333

This setups a rustic chat room between computers that works just fine.
 However, when I try inverting the roles of the computers, communication isn't achieved.


That should be causing the unsuccessful running of roscore on XPS. 

II. In spite of knowing something isn't really ok with the network connection of my computers I proceed with the instructions of Getting Started with P2OS which actually worked fine for me before I reinstalled Ubuntu and ROS in lola.

1. I have decided XPS is going to be directly connected to my Pioneer, therefore, lola will be running the master.


2. On lola's setup.sh I comment the line: 

#if [ ! "$ROS_MASTER_URI" ] ; then export ROS_MASTER_URI=http://localhost:11311 ; fi

And include the following lines:

export ROS_MASTER_URI=http://lola:11311
export ROS_MASTER_IP=http://lola

3. On XPS' setup.sh I comment the same line and include

export ROS_MASTER_URI=http://lola:11311

4. I run roscore on lola and display rxgraph on both computers. /rosout is displayed which seems to indicate roscore is running successfully on them both.

5. I run RosAria node on XPS (which is connected to Pio) and connection is succesfully established.

6. I then run my teleoperation node on lola and while verifying node connection on rxgraph I get the following error:

 ERROR: Communication with node[http://XPS:58281/] failed!

7. Actually,  when I run rxgraph on XPS every single node  and topic seems to be working fine, but in lola RosAria node is enclosed in two red circles which I read indicates connection isn't being fully established.

miércoles, 16 de febrero de 2011

Camera calibration

Today I ran the cameracalibrator configuration file. I had to make some modifications to it due to the node I am using to communicate with the camera.


First, I verified that the camera's topics were being published.

$rostopic list


/usb_cam/camera_info
/usb_cam/image_raw



I then modified the node in the cameracalibrator.py file:

In line 128 instead of camera node we place usb_cam node:

        self.set_camera_info_service = rospy.ServiceProxy("%s/set_camera_info" % rospy.remap_name("camera"), sensor_msgs.srv.SetCameraInfo)

        self.set_camera_info_service = rospy.ServiceProxy("%s/set_camera_info" % rospy.remap_name("usb_cam"), sensor_msgs.srv.SetCameraInfo)






In line 100 as well:

            for svcname in ["camera", "left_camera", "right_camera"]:
            

            for svcname in ["usb_cam", "left_camera", "right_camera"]:


Now, in order to run the cameracalibrator node we must specify the topics we are using:


$rosrun camera_calibration cameracalibrator.py --size 6x4 --square 0.0508 image:=/usb_cam/image_raw camera:=/usb_cam

Here is a screenshot of the program's functionality:


 

lunes, 14 de febrero de 2011

Error message with Genius webcam

I was provided a new webcam to work with. It is a Genius Slim 1322AF. When trying to run usb_cam node (on dev/video1) I get the following error message:

VIDIOC_S_FMT error 22, Invalid argument


I have tested it on Ubuntu's Cheese Webcam Booth application and it works fine so I don't think the problem lays on the driver.

I am very tired... and haven't found any satisfying answer on linux forums so I'm just going to ask someone on ROS' mailing list.

jueves, 3 de febrero de 2011

Running usb_cam node

I have created a launch file with the help from this guide: http://www.princeton.edu/~ctralie/Projects/DukeDusty2/Tutorial/
Note: /dev/video0 is the device of the integrated webcam of my laptop and /dev/video1 is the device of the Logitech Quickcam I am currently using.

When running this launch file with the /dev/video0 device I can successfully visualize video on rviz. However, a status error is displayed:

CameraInfo/P resuted in an invalid  position calculation (nans or infs)

According to ROS users, I should calibrate my camera in order to avoid this error. I had no idea on how to do so until I found this tutorial:

http://www.ros.org/wiki/camera_calibration/Tutorials/MonocularCalibration. I hope this does the trick.









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.


miércoles, 17 de noviembre de 2010

Costmap configuration

I created a new file in the itesm_demo package in order to include all of the configuration files related to the configuration of move_base.

$roscd itesm_demo
$mkdir config
$cd config

I created four files in this folder. The description of each of them follows:

1. costmap_common_params.yaml: Parameters that are common both for local and global costmaps:


obstacle range: determines the maximum range sensor reading that will result in an obstacle being put into the costmap.
raytrace range: determines the range to which we will raytrace freespace given a sensor reading.

footprint: in the case of specifying the footprint, the center of the robot is assumed to be at (0.0, 0.0) and both clockwise and counterclockwise specifications are supported.

Inflation radius: The inflation radius should be set to the maximum distance from obstacles at which a cost should be incurred.

2. global_costmap_params.yaml: long term plans over the entire environment


global frame: defines what coordinate frame the costmap should run in
robot base frame: defines the coordinate frame the costmap should reference for the base of the robot.
static map: determines whether or not the costmap should initialize itself based on a map served by the map_server.

3. local_costmap_params.yaml: local planning and obstacle avoidance

Rolling window: parameter to true means that the costmap will remain centered around the robot as the robot moves through the world.

4. base_local_planner_configuration.-yaml: The base_local_planner is responsible for computing velocity commands to send to the mobile base of the robot given a high-level plan

miércoles, 3 de noviembre de 2010

Successful map

The map created today seems to be fairly coherent. In order to create it I drove the robot around the hallway. Here it is:

martes, 2 de noviembre de 2010

Mapping



Today I could make a more or less coherent map of lab conditions. The problem is that my lab's conditions aren't ideal at all ... However, the overlapping of the map, which was the main issue to be solved, seems to have disappeared.

What I did this time was to use the original RosAria node since the one modified by the sscrovers team seems to throw odometry errors due to the introduction of an additional function (update). I will post later my comments concerning this code.

What I did afterwards, was to verify that the cmd_vel message published by the teleoperation node coincided with the one to which RosAria node subscribes to. In this case the specific name of the topic is /RosAria/cmd_vel and its type is geometry::msg.

Tomorrow I will physically construct a map with ideal conditions in order to verify that the odometry issue isn't present at the original RosAria node.

martes, 12 de octubre de 2010

Configuration of the Joystick

1. Verify that Linux recognizes my joystick
$ ls /dev/input/
by-id event1 event12 event2 event5 event8 mice mouse2
by-path event10 event13 event3 event6 event9 mouse0
event0 event11 event14 event4 event7 js0 mouse1

js0 is my joystick's port.

2. Make sure my joystick is working

$ sudo jstest /dev/input/js0

I see the data parameters changing.

3. List the permissions of the joystick

$ ls -l /dev/input/js0

crw-rw-r--+ 1 root root 13, 0 2010-10-12 20:07 /dev/input/js0

This indicates I need to change the mode of the port through:

$ sudo chmod a+rw /dev/input/js0

Listing the permissions again will show this result:

crw-rw-rw-+ 1 root root 13, 0 2010-10-12 20:07 /dev/input/js0

4. Start the joy node

$ rosrun joy joy_node

5. Echo the joy topic

$ rostopic echo joy

And I see the data of my joystick is being published through the joy topic.








miércoles, 22 de septiembre de 2010

Comments on ROS Time

"ROS has builtin time and duration primitive types, which roslib provides as the ros::Time and ros::Duration classes, respectively. A Time is a specific moment (e.g. "today at 5pm") whereas a Duration is a period of time (e.g. "5 hours"). Durations can be negative."

The function Time::now(), which is used in most of the codes I am working with uses the system time:

Time Time::now()
{
if (!use_system_time_)
{
boost::mutex::scoped_lock lock(g_sim_time_mutex);
Time t = sim_time_;
return t;
}

Time t;
getWallTime(t.sec, t.nsec);

return t;
}


When I create the map in "real time" the time used is the one from my computer:

"When running with a real robot, the ROS client libraries will use "wall-clock" time (i.e. the time your computer reports). "

In the case of the playback of the bag files I have noticed the following:

"if you are playing back sensor data into your system, you may wish to have your time correspond to the timestamps of the sensor data. "

Concerning Clock server:

"If you are playing back a bag file with rosbag play, using the --clock option will run a Clock Server while the bag file is being played."

Map overlapping

After modifying the launch file Renato shared with me, gmapping was no longer displaying neither the TF_OLD_DATA error, nor the dropped messages warnings. However, the map is still overlaping. Here is the content of the launch file I am currently using named launch_rovers.launch. The attempts to change nodes are presented as comments:


What I am doing right now is playing this launch file simultaneously with rviz, with which I have as well some doubts. Here are two screenshots of what the mapping process looks like:



I have been playing with the fixed and the target frames as can be appreciated in the screenshots. I, however, get the same result always: overlapping of the map.

I have noticed that during this process the mobile frame isn't able to fully rotate when it is necessary and this is what I think is causing the overlapping.

I have several suppositions for the generator of this problem:

1. Odometry isn't being correctly actualized.
2. Gmapping has an error (which I have no idea about).
3. The time ins ROS isn't properly actualized nor the buffer is properly being cleaned out when necessary.


I hope the question I placed at the mailing list is soon answered.

sábado, 28 de agosto de 2010

Pablo's pioneer_tf.cpp

Renato shared with me a post of a ROS user that does slam using the ROSARIA node. Here is the url where this post can be found and following the program itself can be found:

http://ros-users.122217.n3.nabble.com/Pioneer3-td1265101.html#a1288712




#include
#include
#include



void poseCallback(const nav_msgs::Odometry::ConstPtr& odomsg)
{
//TF odom=> base_link

static tf::TransformBroadcaster odom_broadcaster;
odom_broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(tf::Quaternion(odomsg->pose.pose.orientation.x,
odomsg->pose.pose.orientation.y,
odomsg->pose.pose.orientation.z,
odomsg->pose.pose.orientation.w),
tf::Vector3(odomsg->pose.pose.position.x/1000.0,
odomsg->pose.pose.position.y/1000.0,
odomsg->pose.pose.position.z/1000.0)),
odomsg->header.stamp, "/odom", "/base_link"));
ROS_DEBUG("odometry frame sent");
}




int main(int argc, char** argv){
ros::init(argc, argv, "pioneer_tf_publisher");
ros::NodeHandle n;

ros::Rate r(20);

tf::TransformBroadcaster broadcaster;

//subscribe to pose info
ros::Subscriber pose_sub = n.subscribe("RosAria/pose", 1, poseCallback);

while(n.ok()){
//base_link => laser
broadcaster.sendTransform(
tf::StampedTransform(
tf::Transform(tf::Quaternion(0, 0, 0), tf::Vector3(0.13, -0.04, 0.294)),
ros::Time::now(), "/base_link", "/laser"));

ros::spinOnce();
r.sleep();
}
}