Revision history [back]

If my understanding of the navigation stack is correct you won't need any of this, not even fake_localization.

The laser requirement comes from the default setup of the navigation stack with all components, i.e.:

• odometry input
• amcl or gmapping to produce a stable pose from odometry and laser
• cost maps to provide "obstacle information" from a pose and laser data
• global and local planner to steer the robot

The latter two are part of move_base. However, everything is configurable! The relevant parts for your problem will be the fixed frames for the cost maps and observation sources.

The frame can be any frame that you consider fixed, e.g. odometry, data from a motion capture system, ... Set this up to what you expect to have on the robot. fake_localization does only make sense when you plan to employ localization later on. The costmaps itself also do not need to contain a static map for the global costmap.

Observation sources can also be anything that reports obstacles to the cost maps. It does not need to be a laser, e.g. you can input Kinect point clouds.

You'll still need to consider the performance of the system, i.e. if the pose data is not stable the behavior won't be stable, but that is a robotics problem. The same goes for a missing static map or obstacle information. The nav stack will just go through everything that it doesn't know.