More on MRPT
Subscribe
Other links
Who's online
Online users
- Fluigiodo
User login
Navigation
Documentation of MRPT by J.L.Blanco & contributors is licensed under a Creative Commons License.
An important redesign of MRPT for better modularity
Hi all,
I think MRPT is becoming quite large, specially the library "mrpt-core", which right now covers from OS-abstraction layer, matrices, random numbers, up to SLAM algorithms.
After much thinking, I propose to split it into SIX smaller libraries, which IMHO will provide a much better modularity so users that only use (for example) maths and serialization, can use the new "mrpt-base" and won't need a huge .dll/.so with a lot of SLAM stuff useless to them.
See the attached image for the proposed structure.
Basically, the distribution of namespaces across libs would be:
- mrpt-base lib: bayes, utils, math, synch, system, poses, compress, jacobians, random.
- mrpt-graphics lib: gui, opengl
- mrpt-core lib: slam, scan_matching
- mrpt-mapsobs lib: obs (a new namespace for observations, which would go out of mrpt::slam), and maps (idem).
- mrpt-hwdrivers lib: hwdrivers
- mrpt-vision lib: vision
...
Since this change is quite big and will probably require changes in existing code (will try to keep them minimal, possibly just adding a new "using namespace obsmaps;"), I wanted to share this with all current users to know your opinions and suggestions!
Comment about your achitecture proposal.
I think that is a very good idea to split the mrpt-core library in smallest libraries.
Is it possible to move the "mrpt-graphics" library ? I don't think that is a good idea that most of the libraries depends on this one, because when we use MRPT in an embedded system, we don't compile it with GUI nor OPENGL. So if this library (mrpt-graphics) must be the parent of all other libraries the compilation options of mrpt should allow that this library stay empty (help to the existing macro HAS_OPENGL etc...)
Regards, A.BARRAL
PS : Did you forget a link between mrpt-monoslam and mrpt-vision ?
Monoslam
As the current responsible for monoslam (which is not yet functional), I can answer that yes, obviously monoslam depends on vision :).
By the way, what will be the difference between mrpt-base and mrpt-core? Will the core be just a wrapper to include all the functionality present in the current core library, being the base a set of mostly mathematical data and functions?
Pablo.
An interesting prospect.
I am concerned restructuring the base along with associated documentation and existing code may discourage users from downloading future releases.
The fragmentation may have a trickle down effect for MRPT repository lib users if the next upgrade breaks applications. This could turn a beautifully organized base into a version'ing nightmare.
In my opinion, more work needs to be done to stabilize the code for field use. Using MRPT on a 250kg robot around people is still a rather risky venture for new users.
Please consider native support for the .LAS format as it would offer a great reason for other researchers to try MRPT with a minimal learning curve (already documented standard). Additionally, high quality scan topologies are available (or can export) in this format.
J
I reply to each post
I reply to each post individually, and now with a little more time I'll try to explain the planned changes a bit more in depth and the reasons for partitioning like shown in the graph:
@everyone:
The most problematic change in all this, is moving all CMetricMaps+CObservations to a new libray. But, one thing that could be done to minimize (almost to zero) any possible conflict with existing code is to keep all the classes within the same namespace than now (mrpt::slam), even if they are at different libraries!
The problem with this is that future users might see it a weird design, but if it's the price to pay for zero compatibility problems, it might be a good alternative to creating new namespaces "mrpt::obs" for observations and "mrpt::maps" for maps, for example.
What do you think about this?
@joel:
"The fragmentation may have a trickle down effect for MRPT repository lib users if the next upgrade breaks applications. This could turn a beautifully organized base into a version'ing nightmare."
Completely agree in that avoiding breaking existing code must be a priority. OTOH, I have to admit that some aspects of the design of MRPT are the result of an uncontrolled growth, like the huge amount of inter-related classes in mrpt-core which can be hardly separated even having so different scopes.
That's the reason of proposing some "important" restructuring ASAP: the more it's delayed, more users will be using MRPT and it'll become harder and harder to make changes without annoying many people :-(
"In my opinion, more work needs to be done to stabilize the code for field use. Using MRPT on a 250kg robot around people is still a rather risky venture for new users."
I'm fully open to suggestions in this sense! If you want to go into any particular issue, please open a thread for it in this forum.
"Please consider native support for the .LAS ..."
Sorry, couldn't find anything about this format in relation to robotics/SLAM!! Please, give me some pointers to start with...
@barral:
"Is it possible to move the "mrpt-graphics" library?"
Sadly, I'm forced to put it below where-ever maps are defined (CMetricMap and children), since one cool thing of maps is that they can be exported to 3D objects (mrpt::opengl), and moving that code out of CMetricMap would break a lot of code. And CMetricMap are very closely related to CObservations (and children), that's why I though of the library "mrpt-mapsobs" for both of them alone. And metric maps/observations are used by slam/hwdrivers/vision, so that's the reasoning behind the graph!! :-)
As you see, there're very few chances to do it in any different way. Perhaps, mrpt::gui could be given it's own library, depending on another one for mrpt::opengl alone, but at least this new "mrpt-opengl" would need to go below ALL the other libs :-(
Anyway, this is not a problem for embedded system as you say, since it'll be allowed to build just a stub library with all gui/opengl stuff disabled.
"PS : Did you forget a link between mrpt-monoslam and mrpt-vision ?"
Yep! Fixed in the graph, thanks!
@pablo:
"By the way, what will be the difference between mrpt-base and mrpt-core? Will the core be just a wrapper to include all the functionality present in the current core library, being the base a set of mostly mathematical data and functions?"
Right!
The idea is that, say, someone wants MRPT just to grab laser scans with a Hokuyo. He doesn't need all the stuff in mrpt-core! Just mrpt-hwdrivers (+its dependencies!) will do the job, and he would depend on just a few, smaller .so/.dll than now.