Hi everyone, your friendly neighborhood navigator here!
I want to announce our newest package pending for Nav2: nav2_loopback_sim. It is designed as a “loopback” from the commanded velocities back into /tf and /odom as the directly executed velocity to replace physical simulation or hardware. It also accepts a standard /initialpose like AMCL and other localizers in order to relocalize the robot perfectly anywhere in the map. Think of it as a ‘frictionless-plane’-style simulation and is drop-in replaceable with other AMR simulators and global localization techniques! This is a simple-to-use, low-parameter solution.
This was created to help better:
Write unit and system tests
Test high-level autonomy behavior not dependent on control and localization behavior
test multirobot systems scalably with low compute footprint
Simulate when in otherwise highly compute constrained environments and need to simulate a robotic autonomy system
Arbitrarily transport the robot to any location and accurately navigate without waiting for a particle filter to converge for testing behaviors and reproducing higher-level issues
I even provide a couple out-of-the-box demonstrations using it in place of Gazebo for nav2_bringup
I’m looking for code reviews before merging, but the documentation for this work is already live at docs.nav2.org! If you have a few minutes, I’d appreciate your thoughts before releasing it at the end of the month in binaries!
I had looked at that and wanted something stand-alone for those that don’t want to use Gazebo at all (there are some in the Nav2 community that use Isaac Sim, O3DE, Unity, etc) to have a simple frictionless plane simulator that was going to be as minimum of compute overhead as reasonably possible and batteries included without other large dependencies.
Even when replacing Gazebo’s physics with TPE, I imagine that isn’t the only compute hog that could cause issues with trying to scale up to 10, 20, 50 robots for high-level behavior simulation. I didn’t nit-pick nav2_loopback_sim for reducing every single operation to be as efficient as possible, but it is very minimal (though could be rewritten in C++ for further performance improvements). I benchmark it to take up 10% of a i7-1365U at 100hz - which is probably overkill - so it could provide simulation for high level behaviors of a fleet of ~10 robots under a single core (out of 12).
With all that said, its a good idea to play around with TPE in our bringup (maybe make it an option?) as yet another way to go! I largely looked at this as an opportunity to have a low-parameter, zero-additional-dependency, easy to understand, and performant solution. GZ could have been used, but it wouldn’t be as portable and still require users to setup a GZ sim to use it (whereas they might not have a GZ SDF when using other simulators). This is secondary concern, but the more I thought about it on a few fronts, the more it felt like it was trying to fit GZ into a related, but not quite correct shaped hole, so to speak.
I was not aware of this previously! Yes, I’d say this is directly analogous. I don’t think this nav2_loopback_sim is particularly novel or inspired, I’m sure its been reinvented time after time at various companies
I do really like your laser scan simulator based on the map though! That looks like a really nice addition to this work. We already publish a ‘bogus’ max-range laser scan for the collision monitor to be happy, it would be great if that was based on some actual map data instead. I’ll file a ticket for that.
@Rayman if I had known about that project, I would have likely worked with you to integrate that instead! I never mean to reinvent the wheel and yours is already in C++.
We could very plausibly replace nav2_loopback_sim’s implementation with an updated version of your work if you’d be interested!
