System constraints for a mobile base / 2D planning

[KXRLYM]

Hi there,

For my project, I wish to deploy this on a mobile base. For now, I am assuming that the camera is fixed at the end of a mobile manipulator. I am using gazebo + move_base to control a 2D mobile base. I am currently making changes to the code such that the conversion from Eigen to MultiDofJointTrajectoryPoint is now Eigen to MoveBaseGoal.

I want to ensure next that the output Eigen value from the planner is essentially a trajectory of x, y and a heading of the mobile base. I can also make use of ros tf to transform to the camera. At this point I don't particularly care about velocity, acceleration and any other information in a hope that move_base will take care of it. e.g.) can I only sample in 2D dimension so that the trajectory is generated just for 2D? Before I dig too deep into it, I wanted to ask if it is feasible, and any tips for me to continue down this way.

Thank you

[Schmluk]

Hi @KXRLYM

Thanks for your interest and for reaching out!

• Output: Our planners primarily create view-points (i.e the goal point of the trajectory). Interpolating the entire trajectory or even velocities and accelerations is optional and just decoding the goal points to MoveBaseGoals should work well! (We added the trajectories for smoother MAV control, but most of the time just the goals worked even better if there is a good controller)
• 2D Sampling: That should be very easy to add, just adapt the sampling step in the TrajectoryGenerator to be only in 2D and everything else should work! We had this running and tested in the past, but I briefly checked and it does not seem the code is around. If you want to add a small 2D-IPP package where e.g. sampling in 2D can be enabled as a param that is off by default we'd love to support a PR!

Hope this helps!

[KXRLYM]

Thank you for your reply @Schmluk!

I have some questions about bounding volumes. I have tried 2D sampling and sending move_base goal poses but the goal from the planner seems to be only at where the robot is. Voxblox traversable pointcloud is looking OK, with one concern that it is not possible to actually traverse on the ground (z = 0.0) since technically that's where obstacle (ground) is (something I will have to look into soon with Voxblox). After all, I noticed that bounding volumes are not set currently, resulting in all samples to be at (0,0,0).

0. I am going to assume \target_bounding_volume is associated with gain and \map_bounding_volume is associated with sampling domain.

1. Do we usually set \target_bounding_volume and \map_bounding_volume prior to running the planner? If that's the case, how do you deal with exploration when the extent of the map is not known prior? Can I perhaps change them dynamically?

2. In my own 2D-IPP planner, I take the bounding "plane" to be the currently available 2D map, which also dynamically changes as the robot explores more. It was made easy using ROS since the size of occupancy grid gets published by the mapping node. Is it possible to do this with the current setup of this planner?

Thanks in advance :)

[Schmluk]

0. The target bounding volume specifies the region of interest (RoI). There is no information gain outside of this, and it can be infinitely large if you just want to explore or have no prior. The map bounding volume specifies the maximal traversable region, it can be infinite if this is unknown, but setting some meaningful bounds (e.g. 100m in all directions) will result in marginally better sampling.

1. These volumes are parts of the problem setup and do not need to be changed dynamically/during operation. Both can be infinite if unknown. If you set a bounding volume to infinite the sampling+planning will still work (This is worth double checking, but I think not setting a volume will have the effect of it being infinite)

2. The bounding plane should be the maximally relevant area (or an overestimate thereof). The planner will draw samples from this global space and automatically move them into the feasible (dynamic) map space to build a feasible tree.

3. 2D planning w/ voxblox: It is not trivial to convert a volumetric map for 2D lookups. Options that have worked in the past is planning at a constant z-offset to have distance from the ground (hacky), planning over the floor mesh (needs extra processing), converting the volume into a 2.5D height map (needs extra processing). If you already have a 2D map for planning you can just write a active_3d_planning-map module that wraps your map type similar to how the voxblox_map wraps a voxblox server. If you can implement collision checks the planner can use it through the map interface without any further changes. You can also (I think, or should be able to add) have two maps, where 2D is used for traversability and 3D for view planning if you need both.

Hope this helps!