http://gicl.cs.drexel.edu/wiki-data/api.php?action=feedcontributions&user=Aeh84&feedformat=atom 2013-05-20T02:49:05Z User contributions MediaWiki 1.18.2 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:16:36Z

<p>Aeh84: /* Do something new */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared, next steps.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on a number of pcl modules, including registration, keypoint estimation, features, and correspondence. There are a number of ways to do this and it would be helpful to get a sense of some of them before starting on one.<br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts: [[File:Registration_code.tar.gz]]<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === register_pointclouds/registration.cpp ===<br /> Reads a pointcloud off the ROS bus (the topic name is set to the same one public_from_file.py writes to). Runs Iterative Closest Point on each pair of pointclouds.<br /> <br /> To run:<br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** Further research on Euler angles and rotations in 3d space would probably be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms. These are highly dependent on the data set you use, and it seems they need to be discovered via trial-and-error, and then re-discovered if you use a different data set.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:14:55Z

<p>Aeh84: /* Registering pointclouds in ROS with PCL for Robot_Lab_(Spring_2012) */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared, next steps.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on a number of pcl modules, including registration, keypoint estimation, features, and correspondence. There are a number of ways to do this and it would be helpful to get a sense of some of them before starting on one.<br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts: [[File:Registration_code.tar.gz]]<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === register_pointclouds/registration.cpp ===<br /> Reads a pointcloud off the ROS bus (the topic name is set to the same one public_from_file.py writes to). Runs Iterative Closest Point on each pair of pointclouds.<br /> <br /> To run:<br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:13:51Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on a number of pcl modules, including registration, keypoint estimation, features, and correspondence. There are a number of ways to do this and it would be helpful to get a sense of some of them before starting on one.<br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts: [[File:Registration_code.tar.gz]]<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === register_pointclouds/registration.cpp ===<br /> Reads a pointcloud off the ROS bus (the topic name is set to the same one public_from_file.py writes to). Runs Iterative Closest Point on each pair of pointclouds.<br /> <br /> To run:<br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/File:Registration_code.tar.gz 2012-06-15T20:13:03Z

<p>Aeh84: code for the scripts described in pointcloud registration summary</p> <hr /> <div>code for the scripts described in pointcloud registration summary</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:09:18Z

<p>Aeh84: /* Learn about registration */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on a number of pcl modules, including registration, keypoint estimation, features, and correspondence. There are a number of ways to do this and it would be helpful to get a sense of some of them before starting on one.<br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts.<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === register_pointclouds/registration.cpp ===<br /> Reads a pointcloud off the ROS bus (the topic name is set to the same one public_from_file.py writes to). Runs Iterative Closest Point on each pair of pointclouds.<br /> <br /> To run:<br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:07:36Z

<p>Aeh84: /* register_pointclouds/registration.cpp */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts.<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === register_pointclouds/registration.cpp ===<br /> Reads a pointcloud off the ROS bus (the topic name is set to the same one public_from_file.py writes to). Runs Iterative Closest Point on each pair of pointclouds.<br /> <br /> To run:<br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:07:24Z

<p>Aeh84: /* Try my scripts */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts.<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === register_pointclouds/registration.cpp ===<br /> Reads a pointcloud off the ROS bus (the topic name is set to the same one public_from_file.py writes to). Runs Iterative Closest Point on each pair of pointclouds.<br /> <br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T20:01:22Z

<p>Aeh84: /* Try my scripts */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> Download a tgz of my scripts.<br /> <br /> === pose_registration.py ===<br /> Uses the pose data from the data set to transform each point cloud into a global frame of reference. Writes PLY files.<br /> <br /> Referenced http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ ./pose_registration.py<br /> <br /> === pointclouds_ah/publish_from_file.py ===<br /> Reads a pointcloud from a PLY or .3d file, in which each line gives the coordinates a point. Publishes each pointcloud as a message to the a ROS topic.<br /> <br /> To run:<br /> # first set the global variables for file locations<br /> $ rosrun pointclouds_ah public_from_file.py<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ rosrun register_pointclouds register<br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:53:34Z

<p>Aeh84: /* Do something new */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. There may be mathematical errors in the script I wrote to do this.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:52:41Z

<p>Aeh84: /* View results */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> <br /> [[File:RegistrationOdometry.png|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:51:16Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Pointclouds registered by translating them according to odometry data:<br /> [[File:RegistrationOdometry|500px]]<br /> <br /> Running the data set through odometry translation and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> Things I would do if I were to keep working on this project.<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.<br /> * Experiment more with max correspondence and epsilon parameters to registration algorithms.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/File:RegistrationOdometry.png 2012-06-15T19:49:48Z

<p>Aeh84: Pointclouds registered by translating them according to odometry data</p> <hr /> <div>Pointclouds registered by translating them according to odometry data</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:44:43Z

<p>Aeh84: /* Do something new */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data with each pointcloud; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:43:41Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == Find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == Learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == Try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == View results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == Do something new ==<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:42:26Z

<p>Aeh84: /* do something new */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == Results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == do something new ==<br /> * Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> ** I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> ** A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> ** Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.<br /> * Cleaning noise from the data could be helpful. I believe the circular artifacts in my images come from noise in the pointclouds. Without them, registration could be more accurate.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:39:30Z

<p>Aeh84: /* Results */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == Results ==<br /> The results never came out perfectly, but they do nicely show the effects of different types of translation on the data / stages in the process.<br /> <br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:34:23Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == Results ==<br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> Illustration accompanying the data set I used:<br /> [[File:RegistrationEt4.jpg]]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/File:RegistrationEt4.jpg 2012-06-15T19:32:55Z

<p>Aeh84: Illustration of registered data that comes with the data set.</p> <hr /> <div>Illustration of registered data that comes with the data set.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:31:28Z

<p>Aeh84: /* Results */</p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == Results ==<br /> Running the original data set through pointcloud registration only:<br /> <br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> <br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:30:54Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == Results ==<br /> Running the original data set through pointcloud registration only:<br /> [[File:RegistrationOriginal.png|500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> [[File:RegistrationPrecomputed.png|500px]]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:30:33Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> == Results ==<br /> Running the original data set through pointcloud registration only:<br /> [[File:RegistrationOriginal.png 500px]] <br /> <br /> Running the data set through pose registration only:<br /> <br /> Running the data set through pose registration and then pointcloud registration:<br /> [[File:RegistrationPrecomputed.png 500px]]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:27:56Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> [[File:RegistrationOriginal.png]] [[File:RegistrationPrecomputed.png]]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/File:RegistrationPrecomputed.png 2012-06-15T19:27:31Z

<p>Aeh84: Screenshot of pointclouds that were first transformed according to odometry data, then registered with registration script.</p> <hr /> <div>Screenshot of pointclouds that were first transformed according to odometry data, then registered with registration script.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:26:24Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> [File:RegistrationOriginal.png]<br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/File:RegistrationOriginal.png 2012-06-15T19:25:52Z

<p>Aeh84: Screenshot of pointcloud registration script on unmodified data set</p> <hr /> <div>Screenshot of pointcloud registration script on unmodified data set</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:21:42Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> <br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:21:32Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> Paths followed, lessons learned, and code shared.<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> <br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:20:49Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == try my scripts ==<br /> <br /> === pose_registration ===<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> === publish from file to ROS bus ===<br /> <br /> === pointcloud registration ===<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> <br /> <br /> == do something new ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:16:40Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> Ideally, it would be best to take your own data, then you know everything about it. It turns out the better you know the data (how far did the robot move between images? what unit does your scanner use for measurements -- meters? pixels?) the better off you will be in fine-tuning the registration algorithms.<br /> <br /> == learn about registration ==<br /> The pcl site has a lot of information. I would recommend reading the introductory material on <br /> <br /> == pointcloud registration ==<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == registration ==<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799<br /> <br /> == future work ==<br /> Working odometry into the registration process appears to be key. It would be nice to figure out the best way to do it.<br /> * I don't know whether / how it's possible to send odometry and pointclouds over the ROS bus and correlate them on the other side. Do they need to be combined into a single message? Can the callbacks on the two topics be tied together somehow? It would be easier to start by skipping the ROS bus altogether and just reading in the pointcloud and omdometry data from file.<br /> * A new version of pcl should be coming out any day now as I finish this quarter. A new registration algorithm will take odometry data; it's called Normal Distributions Transform. That would be worth trying out.<br /> * Further research on Euler angles and rotations in 3d space could be useful. I'm not certain that what I did in my python script is without error.</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T19:04:25Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> My python script, publish_from_file.py, can be easily adjusted to read any similar format, wherein each line gives the coordinates for a point. [http://en.wikipedia.org/wiki/PLY_(file_format) PLY] is another option; PLY pointclouds can be loaded and viewed in [http://meshlab.sourceforge.net/ Meshlab].<br /> <br /> I didn't write any code to read pcl files, but this is the format that the [http://pointclouds.org pointcloud library] reads and writes, so if you found some pcl data and like c++ that would also work.<br /> <br /> == pointcloud registration ==<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == registration ==<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T18:58:58Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> <br /> == find some data ==<br /> The data I used is dataset 14 at http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> <br /> == pointcloud registration ==<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == registration ==<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-15T18:57:27Z

<p>Aeh84: </p> <hr /> <div>= Registering pointclouds in ROS with PCL for [[Robot_Lab_(Spring_2012)]] =<br /> <br /> == pointcloud registration ==<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == registration ==<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-14T02:03:09Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == pointcloud registration ==<br /> $ rosmake register_pointclouds<br /> $ roscore<br /> $ rosrun register_pointclouds register<br /> $ <br /> <br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == registration ==<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-06-07T21:58:13Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == registration ==<br /> * http://www.euclideanspace.com/maths/geometry/space/coordinates/index.htm<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-08T23:37:46Z

<p>Aeh84: /* mapping from point clouds */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/point_cloud.py?rev=52799<br /> * https://code.ros.org/trac/wg-ros-pkg/browser/stacks/object_manipulation/branches/hri12/object_manipulator/src/object_manipulator/convert_functions.py?rev=52799</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-05T18:27:23Z

<p>Aeh84: /* mapping from point clouds */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> * http://kos.informatik.uni-osnabrueck.de/3Dscans/<br /> * http://www.ros.org/wiki/pointcloud_registration<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T20:28:27Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * regular click: rotate the view<br /> * shift-click: move the view or focal point<br /> * host click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * http://www.ros.org/wiki/rgbdslam - this appears to be just for kinect</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T19:11:50Z

<p>Aeh84: /* mapping from point clouds */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * http://www.ros.org/wiki/rgbdslam - this appears to be just for kinect</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T18:09:16Z

<p>Aeh84: /* mapping from point clouds */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> * http://www.ros.org/wiki/pointcloud_to_laserscan<br /> * http://www.ros.org/wiki/rgbdslam</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T02:34:39Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> http://www.ros.org/wiki/pointcloud_to_laserscan<br /> http://www.ros.org/wiki/rgbdslam</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T02:07:49Z

<p>Aeh84: /* mapping from point clouds */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> http://www.ros.org/wiki/pointcloud_to_laserscan</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T01:59:12Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == mapping from point clouds ==<br /> http://www.cs.washington.edu/robotics/projects/rgbd-3d-mapping/</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T00:19:11Z

<p>Aeh84: /* create a map from log data and watch it on rviz */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == sample line from gmap_tester.bag ==<br /> [RUNNING] Bag Time: 125.202523 Duration: 90.602523 / 1239670987.745222</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T00:14:03Z

<p>Aeh84: /* create a map from log data and watch it on rviz */</p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosrun rviz rviz<br /> # make sure map is checked and subscribed to topic /map<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == sample line from gmap_tester.bag ==<br /> [RUNNING] Bag Time: 125.202523 Duration: 90.602523 / 1239670987.745222</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-03T00:08:28Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == pages ==<br /> * [[Robot_Lab_(Spring_2012)]]<br /> * [[ROS_(Robot_Operating_System)]]<br /> * [[Navigation]]<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosrun rviz rviz<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == sample line from gmap_tester.bag ==<br /> [RUNNING] Bag Time: 125.202523 Duration: 90.602523 / 1239670987.745222</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-05-02T20:04:13Z

<p>Aeh84: </p> <hr /> <div>robot notes for anna by anna<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosrun rviz rviz<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == sample line from gmap_tester.bag ==<br /> [RUNNING] Bag Time: 125.202523 Duration: 90.602523 / 1239670987.745222</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-04-29T23:34:31Z

<p>Aeh84: /* create a map from log data and watch it on rviz */</p> <hr /> <div>=robot notes for anna by anna=<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> $ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosrun rviz rviz<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == sample line from gmap_tester.bag ==<br /> [RUNNING] Bag Time: 125.202523 Duration: 90.602523 / 1239670987.745222</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-04-29T23:33:28Z

<p>Aeh84: </p> <hr /> <div>=robot notes for anna by anna=<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> &lt;pre&gt;$ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosrun rviz rviz<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> &lt;/pre&gt;<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf<br /> <br /> == sample line from gmap_tester.bag ==<br /> [RUNNING] Bag Time: 125.202523 Duration: 90.602523 / 1239670987.745222</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-04-29T23:30:19Z

<p>Aeh84: </p> <hr /> <div>=robot notes for anna by anna=<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == create a map from log data and watch it on rviz ==<br /> &lt;pre&gt;$ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosrun rviz rviz<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> &lt;/pre&gt;<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-04-29T21:49:42Z

<p>Aeh84: /* rviz view controls */</p> <hr /> <div>=robot notes for anna by anna=<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (how?): move the view or focal point<br /> * host click / right click / scroll: zoom<br /> <br /> == how to create a map from log data ==<br /> &lt;pre&gt;$ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> &lt;/pre&gt;<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf</div>

Aeh84 http://gicl.cs.drexel.edu/wiki/User:Aeh84 2012-04-29T21:43:50Z

<p>Aeh84: /* tbd */</p> <hr /> <div>=robot notes for anna by anna=<br /> <br /> == tbd ==<br /> * can rosparams be set in a config file somewhere and auto-loaded?<br /> * it seems the /map frame in rviz is different from the /map topic? because rviz can't find the /map frame even when the /map topic is being published.<br /> <br /> == rviz view controls ==<br /> * left / regular mouse button: rotate the view<br /> * middle button (option click): move the view or focal point<br /> * right button / scroll: zoom<br /> <br /> == how to create a map from log data ==<br /> &lt;pre&gt;$ roscore<br /> $ rosparam set use_sim_time true<br /> $ rosrun gmapping slam_gmapping scan:=base_scan<br /> $ rosbag play ~/ros/gmap_tester.bag<br /> $ rosrun map_server map_saver<br /> &lt;/pre&gt;<br /> <br /> == topics ==<br /> * gmapping: <br /> ** /base_scan<br /> ** /clock<br /> ** /map<br /> ** /map_metadata<br /> ** /slam_gmapping/entropy<br /> ** /tf</div>

Aeh84