ROS2 Inquery

[SteveMacenski]

Hi,

I'm a maintainer / developer on ROS2 Navigation [1] and was curious about this. I saw you posted on Navigation and in my glancing around I found your blog on it. There's definitely some work to be done on it, but I think its a good starting point to be a candidate for replacement of AMCL in ROS2 Navigation stack, if you're interested. I would be open to helping you finish it up to be feature parity and move it into the later stack.

The big things questions I'd have are:

• You mention not testing KLD sampling, but I see it implemented. Can you explain more about why you didn't test against it? Just want to make sure feature-wise it works, regardless of the specific determinism of the memory/CPU benchmarks.
• Did you do localization accuracy testing in simulation (or ground truth hardware)? I'd want to know that it works on the order as well. Did you test that your implementation correctly was able to recover from delocalization?
• Other than motion models/beam skipping, anything else missing? Those are things I can do pretty fast.

Finally, why GPL-3? I admit, I'm a fan of relatively restrictive licenses for my application-level code [2] but since this is lower-level and people need to build on top of it, that's going to be quite an up-hill battle to get people to use it. I use LGPL-2.1 when building very difficult application-level code because its the most restrictive (give back if you improve it) license that companies will actually accept. However if it wasn't some new technique or non-application level I'm usually running Apache/BSD. GPL-3 for many companies is a non-starter [3]. It would be monumentally easier of a sell if this was available as Apache-2.0 (which still leaves IP + ability to patent should there be something here) or BSD (very very permissive, good baseline if you don't actually care). Given you're the only author, if this interests you, the process is trivial.

[1] https://github.com/ros-planning/navigation2
[2] https://github.com/SteveMacenski/slam_toolbox
[3] https://www.cnet.com/news/torvalds-no-gpl-3-for-linux/

[VorpalBlade]

While it would be awesome to see other people use this, first of, one issue currently is available time for me to do anything except what I need right now. Also, ROS2 development seems to be going rather slow and have lots of bikeshedding from what I have heard. I'm not interested in getting involved in heated discussions.

• I'm not sure where I mentioned not testing KLD, that must be a typo and I will have to look into it. It is what I use normally and it is the default.
• Since I did this as course work during the first year of my masters and after that as a side project, I was rather limited at the time with available hardware (using a very cheap robot with bad odometry and a cheap Chinese LIDAR). My testing consisted of driving (from no/global localisation) and measuring how long it took to "look good", then measure with a measuring tape to known reference points (table legs) in the real world as well as the map in rviz. I could send you the report if you are interested. I think it is somewhat confusingly written and hope that my writing skill has improved since then.
• Issues (all relatively minor individually):
  • One minor issue is that I had not discovered the ROS style guide when writing this. So everything uses under_score rather than camelCase. This could presumably be fixed.
  • QuickMCL has only been tested with Kinetic, but I don't see any reason it shouldn't work with newer distributions, or at least be easy to fix for them.
  • The point cloud support really will only work for a 2D pointcloud and should probably be overhauled or removed. Also consider switching away from using PCL (would probably improve performance further and reduce build memory usage).
  • QuickMCL has some unit tests, but they are far from complete (not like AMCL has much in that department either). There are no integration tests, because I haven't had time to read up on how to do them.

Adding other motion models should indeed be trivial (odometry.h/cpp). Adding beam skipping requires using the beam (as opposed to likihood) model from what I understand/remember, which if not implemented. Presumably it could be done as another class inheriting MapBase.

These days I work with a robot with much better odometry as well as a better LIDAR (Velodyne VLP-16) and I'm using QuickMCL on it (and it is working well), which is why I added dynamic_reconfigure this autumn (it didn't have that before). I think the code related to parameter handling is probably a bit messy and it is clear that dynamic_reconfigure is an afterthought.

I also started on extracting some components from QuickMCL into a separate library ( https://github.com/VorpalBlade/ros_spatial_utils) since I needed them for a different node. There I did the conversion to camel case. I have not yet had time to make QuickMCL use that, nor figure out how the CI should be set up for that.

As for license, I'm open to reconsideration (to LGPL-2/3 or perhaps Apache). I'm quite keen on copy left in general though, so BSD is a much harder sell. My understanding is that ROS messaging between nodes however does not count as linking. Thus it would be equivalent to using a non-GPL browser to access a web page served by a server licensed under GPL (i.e. not a problem). But I'm not a lawyer, so please correct me if I'm wrong.

Even if none of this goes anywhere (I certainly hope it does) I do plan to eventually get around to putting up a ROS wiki page for QuickMCL.

Another interesting idea I have had is making QuickMCL usable as a nodelet. This would basically mean instantiating NodeHandle once, and passing it to the constructors, instead of instantiating it everywhere like today. It could be interesting to run it together with the laser driver nodelets and see if that improves performance at all.

[SteveMacenski]

There's alot to unpack so I'll go inline

one issue currently is available time for me to do anything except what I need right now

Of course. My intention would be to help in this process as well. Though I'd hope that long term you'd help be a maintainer of it.

lots of bikeshedding

I think that's an unfair characterization. But you'd have to be more specific about what you think is going on that gives you that impression.

I'm not sure where I mentioned not testing KLD, that must be a typo and I will have to look into it. It is what I use normally and it is the default.

Oh sorry, I meant that for the CPU/memory benchmarks you did without the sampling in your blog post. I wanted to make sure that the KLD sampling does work and is still more efficient, even if in the benchmarking its less deterministic.

Since I did this as course work during the first year of my masters and after that as a side project

Good on you, this is one of the better implementations I've seen. I disagree with some of the architectural decisions, but they're all decisions that I can tell were consciously made and not just mashed together like most graduate student project code 😆

I could send you the report if you are interested.

Sure, more information is always better than less.

One minor issue is that I had not discovered the ROS style guide when writing this. So everything uses under_score rather than camelCase. This could presumably be fixed.

Eh. No one listens to that for the most part anyhow. There's enough refactoring I'd need to do for a ROS2 port that that's the least of my concerns.

QuickMCL has only been tested with Kinetic, but I don't see any reason it shouldn't work with newer distributions, or at least be easy to fix for them.

It'll be fine. Only change is TF2 if you weren't using it already.

The point cloud support really will only work for a 2D pointcloud and should probably be overhauled or removed. Also consider switching away from using PCL

Makes sense, but there are reasons for people with 2D lasers to was a point cloud. For instance that they have multiple sensors on their robot they want to fuse together, this would let them do it more easily. With that said, I'd like to eventually overhaul to support 3D localization, but as a community we need to decide on a 3D map format first.

QuickMCL has some unit tests, but they are far from complete (not like AMCL has much in that department either). There are no integration tests, because I haven't had time to read up on how to do them.

AMCL basically has no tests so some is better than none. Integration tests Navigation2 will take on.

I actually prefer that you didn't do the motion model work yet. I'm in the middle of designing a motion model plugin package so we can reuse motion models for different base types in planners, controllers, amcl, etc. Beam skipping... yeah I didn't think much about it in particular. I have some notes somewhere when I did several thousand automated tests with different AMCL settings and beam skipping really did help the beam model alot but I forget relative to the max liki. model if that was still superior.

I'd be curious to know more about your robot, if you're open to sharing. Just curious.

As for license, I'm open to reconsideration (to LGPL-2/3 or perhaps Apache)

So Apache I think would be the vote I would give (if I get one, which I don't) for a couple reasons

• If its Apache, I can task resources at Samsung Research to help you
• If its Apache, it stops me from having to file paperwork
• If its Apache, I can more easily get the Intel people also maintaining Navigation2 to help easier
• If its LGPL-2, I can only help in my personal non-corporate time. My job is 100% open source ROS development and that would make things move much slower.

to access a web page served by a server licensed under GPL

You're technically right, but what you're missing is the fact that most companies won't touch GPL with a 10 foot pole as a policy. They won't let it on their product mostly out of fear. Most companies also won't let people contribute back to GPL open source projects. Even LGPL-2 is hairy but you can get away with it if there's nothing built on top of it (hence application-level code) and it represents some work so involved its worth dealing with the lawyers.

It could be interesting to run it together with the laser driver nodelets and see if that improves performance at all.

It would help a little bit, but given those messages are relatively small for 2D lasers that it wouldn't be enough to justify the rearchitecture unless you were going to anyhow for othe reasons. ROS2 has the concept of composible nodes that are basically Nodelets but without having to change the APIs.

[VorpalBlade]

Also inline, because I agree it is getting complicated.

one issue currently is available time for me to do anything except what I need right now

Of course. My intention would be to help in this process as well. Though I'd hope that long term you'd help be a maintainer of it.

Long term that sounds good yes.

lots of bikeshedding

I think that's an unfair characterization. But you'd have to be more specific about what you think is going on that gives you that impression.

This is what I have heard from researchers at my university, I don't have any personal experience (obviously). I'm just not interested in politics, so if I can stay out of that, I'm all for ROS2.

I'm not sure where I mentioned not testing KLD, that must be a typo and I will have to look into it. It is what I use normally and it is the default.

Oh sorry, I meant that for the CPU/memory benchmarks you did without the sampling in your blog post. I wanted to make sure that the KLD sampling does work and is still more efficient, even if in the benchmarking its less deterministic.

Ah yes, indeed. Based on looking at the source for the testing scripts I used for the perfomance analysis (https://github.com/VorpalBlade/ros_mcl_performance_test) what I did was use KLD but set the min and max particle parameters to be equal. I specifically wanted to test how the performance scaled with number of particles. The KLD code is still active, but for all intents and purposes the algorithm is disabled.

Since I did this as course work during the first year of my masters and after that as a side project

Good on you, this is one of the better implementations I've seen. I disagree with some of the architectural decisions, but they're all decisions that I can tell were consciously made and not just mashed together like most graduate student project code laughing

I worked with C++ in the industry for 6 years between my bachelor and my masters. That helps.

I could send you the report if you are interested.

Sure, more information is always better than less.

I will try to find a way to send it to you then.

QuickMCL has only been tested with Kinetic, but I don't see any reason it shouldn't work with newer distributions, or at least be easy to fix for them.

It'll be fine. Only change is TF2 if you weren't using it already.

I'm using TF2, so that won't be an issue.

The point cloud support really will only work for a 2D pointcloud and should probably be overhauled or removed. Also consider switching away from using PCL

Makes sense, but there are reasons for people with 2D lasers to was a point cloud. For instance that they have multiple sensors on their robot they want to fuse together, this would let them do it more easily. With that said, I'd like to eventually overhaul to support 3D localization, but as a community we need to decide on a 3D map format first.

That was my original thinking, but now that I'm working with a 3D laser I find it less useful. As for 3D localisation, I'm quite interested in MCL with NDT (Saarinen et al. 2013; Magnuson et al. 2007; etc). But that would be a completely different piece of software.

I actually prefer that you didn't do the motion model work yet. I'm in the middle of designing a motion model plugin package so we can reuse motion models for different base types in planners, controllers, amcl, etc. Beam skipping... yeah I didn't think much about it in particular. I have some notes somewhere when I did several thousand automated tests with different AMCL settings and beam skipping really did help the beam model alot but I forget relative to the max liki. model if that was still superior.

I'd be curious to know more about your robot, if you're open to sharing. Just curious.

Certainly. This spring I was working on a robot that was based on this kit: https://www.makeblock.com/steam-kits/mbot-ultimate
For running ROS, we strapped on Raspberry Pi 3s, then used rosserial_arduino to talk to the microcontrollers. We also had LIDARs from http://ydlidar.com, though they appear to no longer sell the specific model we used (F4 Pro).

Now I'm working on a project using a converted lawnmower robot (Husqvarna brand), with a Velodyne VLP-16 strapped on top and a high end Intel NUC as the brainbox.

As for license, I'm open to reconsideration (to LGPL-2/3 or perhaps Apache)

So Apache I think would be the vote I would give (if I get one, which I don't) for a couple reasons

* If its Apache, I can task resources at Samsung Research to help you

* If its Apache, it stops me from having to file paperwork

* If its Apache, I can more easily get the Intel people also maintaining Navigation2 to help easier

* If its LGPL-2, I can only help in my personal non-corporate time. My job is 100% open source ROS development and that would make things move much slower.

Those are some big company names. I will need a little bit of time to look into what exactly Apache etc entails.

to access a web page served by a server licensed under GPL

You're technically right, but what you're missing is the fact that most companies won't touch GPL with a 10 foot pole as a policy. They won't let it on their product mostly out of fear. Most companies also won't let people contribute back to GPL open source projects. Even LGPL-2 is hairy but you can get away with it if there's nothing built on top of it (hence application-level code) and it represents some work so involved its worth dealing with the lawyers.

Except for the Linux kernel, which gets away with GPL-2 somehow. But yes, I can see that being a special case.

It could be interesting to run it together with the laser driver nodelets and see if that improves performance at all.

It would help a little bit, but given those messages are relatively small for 2D lasers that it wouldn't be enough to justify the rearchitecture unless you were going to anyhow for othe reasons. ROS2 has the concept of composible nodes that are basically Nodelets but without having to change the APIs.

Which is probably another point of friction. I don't have the time (or robot) to run ROS2 at the moment. I'm basically stuck at 16.04 and Kinetic for the forseable future. Looks like my master thesis work this spring might even involve a system that is still on 14.04, which will be intersting given my laptop is new enough to not boot with that.
Also inline, because I agree it is getting complicated.

one issue currently is available time for me to do anything except what I need right now

Of course. My intention would be to help in this process as well. Though I'd hope that long term you'd help be a maintainer of it.

Long term that sounds good yes.

lots of bikeshedding

I think that's an unfair characterization. But you'd have to be more specific about what you think is going on that gives you that impression.

This is what I have heard from researchers at my university, I don't have any personal experience (obviously). I'm just not interested in politics, so if I can stay out of that, I'm all for ROS2.

I'm not sure where I mentioned not testing KLD, that must be a typo and I will have to look into it. It is what I use normally and it is the default.

Oh sorry, I meant that for the CPU/memory benchmarks you did without the sampling in your blog post. I wanted to make sure that the KLD sampling does work and is still more efficient, even if in the benchmarking its less deterministic.

Ah yes, indeed. Based on looking at the source for the testing scripts I used for the perfomance analysis (https://github.com/VorpalBlade/ros_mcl_performance_test) what I did was use KLD but set the min and max particle parameters to be equal. I specifically wanted to test how the performance scaled with number of particles.

Since I did this as course work during the first year of my masters and after that as a side project

Good on you, this is one of the better implementations I've seen. I disagree with some of the architectural decisions, but they're all decisions that I can tell were consciously made and not just mashed together like most graduate student project code laughing

I worked with C++ in the industry for 6 years between my bachelor and my masters. That helps.

I could send you the report if you are interested.

Sure, more information is always better than less.

I will try to find a way to send it to you then.

QuickMCL has only been tested with Kinetic, but I don't see any reason it shouldn't work with newer distributions, or at least be easy to fix for them.

It'll be fine. Only change is TF2 if you weren't using it already.

I'm using TF2, so that won't be an issue.

The point cloud support really will only work for a 2D pointcloud and should probably be overhauled or removed. Also consider switching away from using PCL

Makes sense, but there are reasons for people with 2D lasers to was a point cloud. For instance that they have multiple sensors on their robot they want to fuse together, this would let them do it more easily. With that said, I'd like to eventually overhaul to support 3D localization, but as a community we need to decide on a 3D map format first.

That was my original thinking, but now that I'm working with a 3D laser I find it less useful. As for 3D localisation, I'm quite interested in MCL with NDT (Saarinen et al. 2013; Magnuson et al. 2007; etc). But that would be a completely different piece of software.

I actually prefer that you didn't do the motion model work yet. I'm in the middle of designing a motion model plugin package so we can reuse motion models for different base types in planners, controllers, amcl, etc. Beam skipping... yeah I didn't think much about it in particular. I have some notes somewhere when I did several thousand automated tests with different AMCL settings and beam skipping really did help the beam model alot but I forget relative to the max liki. model if that was still superior.

I'd be curious to know more about your robot, if you're open to sharing. Just curious.

Certainly. This spring I was working on a robot that was based on this kit: https://www.makeblock.com/steam-kits/mbot-ultimate
For running ROS, we strapped on Raspberry Pi 3s, then used rosserial_arduino to talk to the microcontrollers. We also had LIDARs from http://ydlidar.com, though they appear to no longer sell the specific model we used (F4 Pro).

Now I'm working on a project using a converted lawnmower robot (Husqvarna brand), with a Velodyne VLP-16 strapped on top and a high end Intel NUC as the brainbox.

As for license, I'm open to reconsideration (to LGPL-2/3 or perhaps Apache)

So Apache I think would be the vote I would give (if I get one, which I don't) for a couple reasons

* If its Apache, I can task resources at Samsung Research to help you

* If its Apache, it stops me from having to file paperwork

* If its Apache, I can more easily get the Intel people also maintaining Navigation2 to help easier

* If its LGPL-2, I can only help in my personal non-corporate time. My job is 100% open source ROS development and that would make things move much slower.

Those are some big company names. I will need some time to look into what exactly Apache etc entails.

to access a web page served by a server licensed under GPL

You're technically right, but what you're missing is the fact that most companies won't touch GPL with a 10 foot pole as a policy. They won't let it on their product mostly out of fear. Most companies also won't let people contribute back to GPL open source projects. Even LGPL-2 is hairy but you can get away with it if there's nothing built on top of it (hence application-level code) and it represents some work so involved its worth dealing with the lawyers.

Except for the Linux kernel, which gets away with GPL-2 somehow. But yes, I can see that being a special case.

It could be interesting to run it together with the laser driver nodelets and see if that improves performance at all.

It would help a little bit, but given those messages are relatively small for 2D lasers that it wouldn't be enough to justify the rearchitecture unless you were going to anyhow for othe reasons. ROS2 has the concept of composible nodes that are basically Nodelets but without having to change the APIs.

Which is probably another point of friction. I don't have the time (or robot) to run ROS2 at the moment. I'm basically stuck at 16.04 and Kinetic for the forseable future. Looks like my master thesis work this spring might even involve a system that is still on 14.04, which will be intersting given my laptop is new enough to not boot with that.

I now started thinking about fixing AMCL by the way, and here is my take on it:

AMCL has some very specific stupid code in the KLD drawing code. Fixing that would solve the bad complexity for CPU performance. As for the worse base performance and worse linear scaling constants, it is probably a case of many small stupid things. For example: while AMCL precomputes a distance-to-obstacle map, I found that you could precompute it a couple of steps further, thus saving some computation later on.

Quoting myself (https://vorpal.se/posts/2019/apr/04/amcl-reverse-engineering/):

In a strange oversight, AMCL does not precompute the probability, only the distance to the nearest obstacles. It would have been quite possible to precompute the probability on that map. Maybe this is because AMCL has some sort of support for dynamic parameter change, which would break this if sigma_hit would change without getting a new map?

(And this is also why likelihood_sigma_hit is one of the few parameters in QuickMCL which does not support dynamic reconfiguration.)

Another issue that I found recently (far after doing the performance comparison) is the "save initial pose to parameter server" of AMCL. I added that feature to QuickMCL a few months back, but it turns out that that is extremely slow and blocks. So while QuickMCL supports that (using a single vector parameter instead of several, which helps a bit), it is off by default and I recommend against it. Saving to the parameter server can introduce huge unpredictable latency spikes (50-150 ms!). From my understanding, this will work very differently in ROS2 and thus might not be an issue.

As for AMCL using more memory and having a larger scaling constant for memory: I still have no idea what is going on there!

[SteveMacenski]

I'm just not interested in politics, so if I can stay out of that, I'm all for ROS2.

Again, not really sure what you're referring to.

The KLD code is still active, but for all intents and purposes the algorithm is disabled.

I guess my big question is "is it working?" You mention you have it on your robot, do you have KLD enabled there and see it operating as expected?

I worked with C++ in the industry for 6 years between my bachelor and my masters. That helps.

It sure does. I feel like it should be a requirement to work for a couple years before getting a graduate degree, it makes you so much more effective.

NDT

That is what the autoware folks use. Still the same issue with "what's the representation we all agree on". Either way, not really something to deal with right now.

Now I'm working on a project using a converted lawnmower robot (Husqvarna brand), with a Velodyne VLP-16 strapped on top and a high end Intel NUC as the brainbox.

Sounds about what I expected. I have a similar setup.

Those are some big company names. I will need a little bit of time to look into what exactly Apache etc entails.

Well, ignoring the names for a moment, its really just people that care about open source, and within it ROS. None of us work for a particular product line we're trying to leverage open source for, we're here trying to bring Navigation into "modern" techniques. While MCL isn't new, its hard to provide a general localizer that works well for as many cases as it (though usually bad for any particular case specifically). AMCL is such a mess and the license makes it hard to work with. I saw this work and see an opportunity to revive the localization work since AMCL is just so poorly written and aged badly. It could get some fire back into actually improving it.

Look into Apache, let me know what you think. Is there anything in particular you're concerned about? My title is open source robotics lead, I know a bit about licenses.

I don't have the time (or robot) to run ROS2 at the moment.

I got time. And we all hate AMCL. There's alot of motivation to get rid of it. The original authors of it have begged for years to delete it.

Saving to the parameter server

I'm a fan of just deleting it. It only encourages bad behavior. /amcl_pose is published, use that if someone cares. Parameter server in ROS1 was never intended for changing parameters, it was really only for reading in things on initialization. There's a bunch of warnings about it in the docs but no one reads those.

As for AMCL using more memory and having a larger scaling constant for memory: I still have no idea what is going on there!

Personally, I dont really care. AMCL's structure is terrible and if this works as well (or even realistically slightly worse but not that much worse in localization performance) I'm pretty sold.

[VorpalBlade]

The KLD code is still active, but for all intents and purposes the algorithm is disabled.

I guess my big question is "is it working?" You mention you have it on your robot, do you have KLD enabled there and see it operating as expected?

Yes. As far as I can tell it should be working. Also, KLD by far outperforms the two options (low variance and adpative). Might as well remove everything except KLD.

[SteveMacenski]

Is there a parameter or something for that? I didn't look that deeply.

[VorpalBlade]

There is a parameter: particle_filter_resample_type (documented in doc/using.md).

After some deliberation I have decided to switch to Apache 2.0, assuming there are no library dependencies I use that are incompatible with that. I will check that and do the actual switch some time soon. I may have some time for it this weekend, but I'm not sure.

[VorpalBlade]

Looking into the licenses of the dependencies I noticed Eigen uses MPL-2.0, which seems like somewhere in between Apache 2.0 and LGPL. From a quick read it looks like QuickMCL could still use Apache 2.0 and link to MPL code in the form of Eigen. Replacing Eigen would also require a non-trivial amount of work.

Also: to me MPL is more appealing than Apache, so how would it work for you to use MPL-2.0 for QuickMCL?

[SteveMacenski]

QuickMCL could still use Apache 2.0 and link to MPL code in the form of Eigen

That is correct, should you want to go that way. No need to remove Eigen, that would be nuts 🤣

so how would it work for you to use MPL-2.0 for QuickMCL?

That works for me. I need to inquire with my more sensitive colleagues and see if that poses an issue for them.

In the meantime, I need to find some folks with deployed assets to give this a whirl in ROS1 to make sure it makes sense for ROS2 porting / replacement.

This comment:

The MPL fills a useful space in the spectrum of free and open source software licenses, sitting between the Apache license, which does not require modifications to be shared, and the GNU family of licenses, which requires modifications to be shared under a much broader set of circumstances than the MPL.

Is where I need to talk to the lawyers. Any requirement to share modifications is what companies fear in LGPL. Even if its in less-situations, any situations is the problem. But right now we're using LGPL on AMCL, so this is still an improvement. I'm personally willing to go with MPL -- I leave this to you.

[VorpalBlade]

I will be waiting for your followup on this before going further in the re-license then.

[SteveMacenski]

Hi,

Ok, so still having some conversations (and will probably be having them into the new year, so I don't think this is going to move very fast. Yay inter-company bureaucracy). But the highlights of things so far and how I think it'll go

• There's general interest in getting rid of AMCL and this is seen as as good of an alternative as we're going to get without rewriting from scratch or choosing another localization algorithm.
• There's not a clear person that can dedicate their time in the next 3-6 months to testing this extensively in ROS1 to work out the bugs / add the new features needed, port to ROS2, and move into the larger stack. After 6 months, I can probably be the one to directly take the wheel if I can get access to some robots in large warehouse environments to test with. I am chatting with some colleagues that might be able to dedicate resources to this, but remains to be a firm commitment
• This needs to be tested against localization accuracy in a number of varying environments before we're comfortable totally replacing AMCL with QMCL. Lower footprint is good, but also making sure it functionally operates well in varying, large, and dynamic environments. If needed, reintroducing models that are missing for beam skipping, etc if that's determined to be an issue

tl;dr there's general consensus this is a good option, but no one standing up and taking full ownership over making it happen. Moreover it needs to be heavily tested and looking for resources to help with those specific test cases (lots of moving stuff, lots of variations from the map, working in large repetitive warehouse are the 3 I think of as good tests).

[VorpalBlade]

This sounds about what I expected when it comes to speed of bureaucracy.

• I don't have the resources (or access to a ground truth system) to do the accuracy testing. For the supported case (likelihood field with corrected diff drive odometry model) I do believe that (barring any bugs) the accuracy should be equal given equal parameters. The two softwares implements the same algorithm essentially.
• Before I start accepting outside patches, the re-license needs to go through anyway, either Apache 2 or MPL 2. Otherwise it will be a nightmare to change. (And I'm not keen on contributor license agreements. They make it too easy for a single party to take control over the software.) Do you have any update on the acceptability of MPL-2?
• I'm definitely willing to put in some work and I do not want to just hand it off. I see myself as a maintainer or co-maintainer of the software going forward. However I don't know what sort of hardware I will have access to. It looks like I will be doing my master thesis in an unrelated part of robotics, so I might not have access to a suitable robot during the spring. There is always stage and gazebo though.
• Large maps is not an area I have been able to test QuickMCL at all in. At most I have used in an environment where the map measured 33x80 m (but this was a sparse map, the area was essentially T shaped). Resolution was 0.05 m. I don't see any reason it shouldn't work though. I expect global localisation to get worse with very large maps though, unless you increase the max number of particles. At which point performance will obviously suffer. That should however be a niche use case.

[SteveMacenski]

I do believe that (barring any bugs) the accuracy should be equal given equal parameters

Its just externally verifying that fact

I'm definitely willing to put in some work and I do not want to just hand it off.

I'd expect no less. Either a deep copy or the project itself would be transferred to the ros-planning org, up to you, and the ROS2 porting work would begin. It's likely there will be a bit of re-archetecting because of some nitpicky ROS2 things. My hope is to have more people than you testing on hardware, its important we get a number of people in a number of unique places testing and validating.

global localisation to get worse

Yeah, not a big deal. Global localization isn't used in industrial environments. Its more of a fun toy example for students and academics. In practice we have knowledge of general areas where the robot is rather than just assuming anywhere in a map. I'm more concerned about jumping around or that the laser model may have issues with large deviations as happens over weeks or months.

On licenses, MPL would be fine I think. Folks on my end have tentatively approved, Intel doesn't seem to have a problem with it. I haven't gotten a response from the more sensitive groups. I don't think anyone would argue with Apache 2.0 to be in line with the rest of the navigation stuff, but at the end of the day its up to you. I don't think the difference in license would affect my ability to work on it, but if we're going to change it to that eventually, now would be the easiest time before anyone else has their fingers on the code. I agree that a license updates should happen before anyone touches anything. At this moment that person looks like me and I'm not going to have time in the immediate future to do anything. Beyond other groups, I'm also looking at hiring an intern that I would potentially task with this work.

[VorpalBlade]

For me, ROS 1 support is also important for the the foreseeable future. I would like to see any functionality improvements (extra odometry models, beam model, etc) make it's way to both.

I'm not very familiar with ROS2, so:

1. How hard is it too support both concurrently from the same code base? Or is it better to have two branches to avoid a maze of #ifdef?
2. Can ROS1 and ROS2 be installed side by side on the same computer without conflicting? This seems important to be able to switch back and forth.

I'm more concerned about jumping around or that the laser model may have issues with large deviations as happens over weeks or months.

Changes to the environment is always going to cause issues for basic MCL. I assume this is what you refer to. There is of course things like dual time scale mapping, life long SLAM etc that tries to find solutions to that. However, for the time being I think this is outside the scope of this project.

That said, a plugin architecture that allows experiments of that type does sound interesting! If the modularity was split at the right points, the performance impact could be minimized. However, for such work to be viable, there would have to be actual interest in that.

[SteveMacenski]

I don't disagree that ROS1 is important, but personally I won't spend any time on it, I'm only interested in ROS2. ROS1 is out the door in 6 years and most companies and groups will have to move to ROS2 in the next 2-3 years.

Same code base? Near impossible. Different branches are a requirement. Build system is different, APIs are different, code structure is different...

[VorpalBlade]

Hi! Do you have any updates with regards to the acceptability of MPL vs Apache?