Search
More on MRPT
Subscribe
Other links
Who's online
There are currently 1 user and 16 guests online.
Online users
- adollfTilsimmiliLam
User login
Navigation
Documentation of MRPT by J.L.Blanco & contributors is licensed under a Creative Commons License.
Logging data
Wed, 06/23/2010 - 17:47 — ngoncalves
Hi,
I want to do slam on a very small environment with a Pioneer P3-AT robot equipped with a Sick LMS220 laser. I cannot use the rawlog-grabber application because I cannot plug in a joystick on the robot. Basically, as soon as I start the rawlog-grabber, I cannot move the robot. I tried writting my own simplified data logger but the code example provided on this site does not compile.
My question is: can I simply serialize the observations to a file and latter on use that file with the slam applications of MRPT ?
Thanks,
Nelson Gonçalves
Hi Nelson, Yes, you can do
Hi Nelson,
Yes, you can do it. Probably the easiest way is to serialize observations of the types "odometry" and "laser2D" as you got them. icp-slam will work on that later offline, and you can also convert it to the "sensory frame" format with rawlogviewer and then use rbpf-slam, but if the environment is small, icp-slam should be enough!
BTW: Please, let me know the code in the web that does not compiles to fix it
jl
Hi
The example code in section 4, here http://www.mrpt.org/Rawlog_Format, does not compile. I know it is just a skeleton code, but when I tried to build upon it did not compiled. Complains about incomplete types for
CActionCollection actions;
CSensoryFrame SF;
I guess it is because it is still include the core.h of mrpt.
The problem with the log, I fixed it: got a couple of usb<->rs232 and used my laptop to control the robot with a joystick. Then I could simply run the rawlog-grabber on my laptop. But then nothing else worked properly with MRPT.
Using the RawlogViewer, I got to see a nice animation of the laser scans and the robot trajectory. Then I tried running the rbpf-slam application, but it crashed badly (sigsev) almost immediately. Next I tried icp-slam, but it was taking more than 3 hours to process 2 minutes readings for a 6x9 m area. The next step was using the RawlogViewer to remove the sonar observations, and the icp-slam worked much much faster. However, after all this troubles the pf-slam application crashed right at the start with the map that I generated. So, I just gave up using MRPT.
Just in case you find it useful, I have:
Ubuntu 10.04
g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Processor: AMD Turion X2 (dual core)
3 GB of RAM
MRTP and OpenCv compile with only a few warnings, but otherwise all sample applications of both MRPT and OpenCv run smoothly.
About MRTP
Despite my negative experience with MRPT, I must admit that it seems to be a very good tool for mobile robots and that the people behind it should be proud.
I consider myself to be a slightly above average programmer in C++ and know my away around robotics. However MRPT is simply too cumbersome (too many whistles and bells) and has a steep learning curve. This is common to many other libraries (Player/Stage comes to mind, ROS is a good example on how not to write software for robotics) but that is why everybody at some point just gives up and writes yeat another mobile robotic software library.
I just needed a simple particle filter localization, but spent one week digging into the code of MRPT and running into crashes when not using the example data provided. So, in the end I just decided to build my own code using much simpler libraries (Yarp, Aria, and SMCTC) which are more plug-and-play friendly than MRPT, or Player/Stage or ROS.
If I could make one decision about the development of MRPT, it would be to hide as much as possible the details and configuration options from the user. Just provide simple, ready-made classes, for the most common needs instead of forcing users to rewrite all of their application around MRPT. Right now people have to read the papers and understand the code just to use a feature, say slam, of MRPT.
Hi there, and sorry for the
Hi there, and sorry for the big delay.
>The example code in section 4, here http://www.mrpt.org/Rawlog_Format, does not compile.
>I know it is just a skeleton code, but when I tried to build upon it did not compiled. Complains about incomplete types for
thanks for noting, just gave the documentation on that page another iteration.
>I just needed a simple particle filter localization, but spent one week digging into the code of MRPT
> and running into crashes when not using the example data provided. So, in the end I just decided
>to build my own code using much simpler libraries (Yarp, Aria, and SMCTC) which are more plug-and-play
>friendly than MRPT, or Player/Stage or ROS.
well, it's a pity you lost all that time and ended up without something really working...
I understand it must be quite hard to get into the inner workings of MRPT and that it can discourage many new users. The issue is that, being written mainly thinking of researching (and WHILE researching!) perhaps makes it too customizable, with many options and parameters everywhere.
Also time is finite and writing documentation is always below coding in the priority stack for most of us, and I'm perfectly aware MRPT really NEEDs huge amounts of new documentation (the mrpt-book...).
>If I could make one decision about the development of MRPT, it would be to hide as much as possible the details
> and configuration options from the user. Just provide simple, ready-made classes, for the most common needs
> instead of forcing users to rewrite all of their application around MRPT. Right now people have to read the papers
> and understand the code just to use a feature, say slam, of MRPT.
That's a point I've been intensively debating with other developers and researchers in the field, and I'll/we'll probably do a call for debate on a small set of "standardized interfaces", which I would announce in these forums. If you are still around then, you would be able to participate and expose your view!
jl
A rawlog question
Hi. I'm currently testing different particle-filter based SLAM algorithms, based on offline processing in order to choose the best for continuance of our project. Since MRPT is really huge and rawlog-viewer offers no chance of changing odometry-data by hand (Is THERE?!) , is there a way to write odometry and laser scan data manually to a rawlog, or perhaps import from text file?
If not, i'm probably going to have to write a program that does that and inserts data into objects of classes like CObservation2DRangeScan and CActionRobotMovement2D, without actually having any sensors online, instead reading data from file.
Are timestamps really necessary? Do you have any suggestions as to how to approach this challenge?
Thank you a thousand times,
Luka
Hi Luka, If I understand it
Hi Luka,
If I understand it right, what you want to do is to take an existing rawlog and modify its "actions" (odometry increments) ?? If it's that, nope, RawlogViewer can't do that (it can EXPORT odo+lasers to text files, but not the other way around).
But you can write a small program with a CRawlog object, load an entire dataset in memory and iterate through it modifying its actions, accessing them by indices, for example. Or you can do what you say of creating a "simulated" rawlog. If you do so, take a look at the program "simul-gridmap", perhaps has something you need.
About timestamps, it's a good practice to use them and set them to sensible values. Now, I *think* (can't remember all... :-) that RBPF SLAM methods currently in MRPT don't actually depend on those timestamps.
JL
Hi,
I have just simple questions.
I'll start to use rawloggrabber. but this application needs one ini file.
But, I want to grab 2Dscan(Hokuyo UTM) and odometry(P3-AT) for ICP-SLAM.
I think needing one ini file means to grab about one sensor. doesn't it?
My question is : Do I edit this application source to grab more than two sensors? or is there another methods?
or Is My aboved opinion wrong?
I hope you'll excuse me for using sham english or the choice of words.
thanks!
It's my mistake.
ICP-SLAM don't use odometry maybe..
But, for other uses My question is still valid.
Hi, Please, take a look at
Hi,
Please, take a look at the new documentation of rawlog-grabber: http://www.mrpt.org/Application:rawlog-grabber
Let me know if you still have doubts so I can improve the docs.
JL
Thanks, another question
Thank you for answering, simul-gridmap is an awesome example.
I do however have another question: Some other SLAM programs (LIKE DP-SLAM) use absolute odometry positions (x and y) and not just the current iteration since last position. Theta is usually always only the change from last orientation for the current iteration. I noticed, that MRPT logging logs odometry data for each step and not the cumulative of past movements. Am I correct?
Thanks,
Luka
Hi, I just improved the
Hi,
I just improved the documentation of rawlogs, hopely explaining your doubt.
See: http://www.mrpt.org/Rawlog_Format#note-odometry
JL
Thanks
Hi!
Thanks for clearing that up...
Probably I'll have some other questions in the future, so thank you for being patient :)
Cheers,
Luka