cschuet
commented
6 years ago Good thoughts! See my comments inline.
First, I read through the Cloud Mapping RFC. I also searched for documentation on the new gRPC methods but didn't see it. Does it exist somewhere?
Implementation of some pieces is still on-going. Small status update: as you probably saw in the RFC we now have two IPC systems in the cloud-based mapping scenario: ROS on the robot and gRPC for the cloud uplink. We introduce a ROS<=>gRPC bridge which translates ROS messages, does the TF stuff and pushes them as gRPC messages into the new locally running cartographer_grpc binary. The bridge also takes care of exposing the internal state of cartographer_grpc as ROS topics so that you can use rviz as usual for visualization. In the cloud you run the exact same cartographer_grpc binary just configured differently. The robot's cartographer_grpc uploads some sensor data (IMU, odometry, no rangefinder data) and local SLAM insertion results to the cloud. Bridge is mostly feature complete. cartographer_grpc is still under development.
Now imagine a large area with 100 vehicles driving around in it. They each have decent processing power on them.
FYI The use case I am most interested in is the one where that is not the case and the agents only have enough compute to run local SLAM and maybe a small optimization problem, i.e. pure localization.
They communicate through LTE or WiFi mesh. Each vehicle needs its own world built from its sensors. Hence, each runs its own copy of Cartographer. Ideally, vehicles near each other would share their world with their neighbors; the extra data from a different viewpoint helps with obstacle avoidance, path following, etc. There is also a central office that wants to see the big picture. It could be on a connected LAN or routed through the cloud.
My point cloud data is too large to send on the WiFi/LTE, and the IMU data is too frequent. I can't build my central model using that data. In addition, whatever voxel data represents the local world occupancy data -- it would be too much to send that from all vehicles on the network simultaneously. Hence, it seems that the central server would need to query each vehicle for voxel updates in a round-robin fashion. It is generally not critical that the central server be completely real-time in its display; several seconds of delay is probably tolerable.
I think there are various scenarios for cloud-based mapping with varying connectivity models, goals and number of robots.
I see our current work as gRPCication of a highly configurable SLAM algorithm. Where you put what piece will depend on your use case. The use case I am personally most interested in is the one where you have moderately lightweight agents running only local SLAM and a cloud process which assembles an up-to-date model of the environment continuously. Specifically with ML and perception capabilities in the cloud I would hope that this results in some semantically annotated, (almost) real-time view of the world. I think about a 100 robotic eyes continuously committing information to a spatial database.
It would also be handy if the voxel data were compressed. I don't think it needs to be high-fidelity. 4 bits representing unoccupied to occupied may be enough, and with most space being on one end or the other of that scale, it would compress very will with run-length encoding.
As for sharing the data with nearby vehicles: assume that vehicles are broadcasting their position in some kind of global format. (Alternatively, the central server could rectify each individual vehicle so that they are all in the same global frame.) One vehicles realize that another one is in their (user-defined) proximity , they could request voxel updates from their neighbors periodically.
Using ROS2/DDS it's possible to set the time-to-live (aka, max router hops) on a per-message basis. I had wondered if that would work for peer-to-peer map updates. However, it would require the mesh network to be configured as a router-hop-per-tower. I'm not sure that such configuration is generally available, and a single LTE tower may server too much area for this approach.
Thoughts? Can we make the 100-vehicle scenario happen?
Not sure if you were in the Open House, but we measured the local SLAM + IMU + odometry stream at 20 kB / s / robot and I am of course hoping that we can do 100 robots. Eventually for the steady state we need a way to simplify the optimization problem. So any workable cloud-based mapping solution I can think of will necessarily involve identification and deletion of redundant data.
First, I read through the Cloud Mapping RFC. I also searched for documentation on the new gRPC methods but didn't see it. Does it exist somewhere?
Now imagine a large area with 100 vehicles driving around in it. They each have decent processing power on them. They communicate through LTE or WiFi mesh. Each vehicle needs its own world built from its sensors. Hence, each runs its own copy of Cartographer. Ideally, vehicles near each other would share their world with their neighbors; the extra data from a different viewpoint helps with obstacle avoidance, path following, etc. There is also a central office that wants to see the big picture. It could be on a connected LAN or routed through the cloud.
My point cloud data is too large to send on the WiFi/LTE, and the IMU data is too frequent. I can't build my central model using that data. In addition, whatever voxel data represents the local world occupancy data -- it would be too much to send that from all vehicles on the network simultaneously. Hence, it seems that the central server would need to query each vehicle for voxel updates in a round-robin fashion. It is generally not critical that the central server be completely real-time in its display; several seconds of delay is probably tolerable.
It would also be handy if the voxel data were compressed. I don't think it needs to be high-fidelity. 4 bits representing unoccupied to occupied may be enough, and with most space being on one end or the other of that scale, it would compress very will with run-length encoding.
As for sharing the data with nearby vehicles: assume that vehicles are broadcasting their position in some kind of global format. (Alternatively, the central server could rectify each individual vehicle so that they are all in the same global frame.) One vehicles realize that another one is in their (user-defined) proximity , they could request voxel updates from their neighbors periodically.
Using ROS2/DDS it's possible to set the time-to-live (aka, max router hops) on a per-message basis. I had wondered if that would work for peer-to-peer map updates. However, it would require the mesh network to be configured as a router-hop-per-tower. I'm not sure that such configuration is generally available, and a single LTE tower may server too much area for this approach.
Thoughts? Can we make the 100-vehicle scenario happen?