Decentralized Multi Trajectory

[shreyasgokhale]

This is related to issue #1113.

Hello,

I am developing a feature for cartographer where it is possible to include submaps from other trajectory for -

1. Adding it to the existing submaps list at any point of the time.
2. Using these submaps also for global slam.

Is this feature already implemented? Can developers give some pointers where should I start?

Thanks,
Shreyas

[MichaelGrupp]

Besided multi-master ROS setup you could also consider that Cartographer has "cloud" features that allow to implement client-server architectures using the gRPC framework. This could theoretically be used for decentralized scenarios.

Some resources:

• the cloud/ sublibrary of cartographer, and its server executable
• ...everything else with "gRPC" in it...
• the gRPC node in cartographer_ros, which essentially translates ROS messages into gRPC (& vice versa) and sends them to a cartographer_grpc_server, which then does the actual work.
• presentation of our "joint venture" Google/Magazino cloud SLAM pilot: abstract // video (using a central server, though)
• cloud related RFCs in the rfcs repository

The sad news is that besides that it's not really documented how to get started with that at the moment.
Don't know if this will change soon, as the gRPC API is not set set in stone yet (maybe @cschuet or @gaschler can say more). At least from my side I can't offer more support than that.

You'd need to have gRPC and async_grpc installed and build the cartographer library and cartographer_ros with the CMake buildflag -DBUILD_GRPC=ON. These CI scripts might help: https://github.com/googlecartographer/cartographer/tree/master/scripts (be aware that they do "make install", so I would try it on an isolated test system first, e.g. a VM, chroot, Docker etc).

[shreyasgokhale]

Thanks @MichaelGrupp for your reply, the information you provided is well enough to start with. I'll keep updating this thread with my progress and questions.

[shreyasgokhale]

Update

I was able to bodge together a working version for decentralized cartographer. I've added a rosservice: /send_state_remote <ip_of_remote_grpc_server:port> and a rosnode cartographer_grpc_decentralized_node . It leverages existing mechanism of writing state in a pbstream and sends it to remote grpc_server via a new async grpc channel. This is not a perfect solution as the trajectories are frozen (correct me if I a wrong), but works for now.

You can test the decentralized version by pulling my forked version of cartographer and cartographer_ros and using branch testing-decentralized. Please tell me if you find any bugs or TODOs.

I'd also like to add a PR for this work. @MichaelGrupp do you know if this is possible or if this feature is any useful?

[MichaelGrupp]

IMO it doesn't make sense to put effort in a PR at the moment since this project is not really maintained by the former Google team anymore (see cartographer-project/cartographer#1675 ). The last time I talked to them it wasn't really clear if/how the public project will be continued, so I can't say more at the moment.

[shreyasgokhale]

That's really unfortunate. I also wanted to add a starting position for the remote trajectories (something like #1507) so I am going to keep working on it. But, I'll close this issue for now.

[bofetadas]

Hey @shreyasgokhale what did you mean with frozen trajectories? What kind of impact did it have on cartographers workflow or performance? Have you been able to overcome this issue? Or did you drop the project?

I was able to bodge together a working version for decentralized cartographer. I've added a rosservice: /send_state_remote <ip_of_remote_grpc_server:port> and a rosnode cartographer_grpc_decentralized_node . It leverages existing mechanism of writing state in a pbstream and sends it to remote grpc_server via a new async grpc channel. This is not a perfect solution as the trajectories are frozen (correct me if I a wrong), but works for now.