Hello,

I have put in place a (custom) mobile robot with a drive controller (taking a desired twist and outputting required wheel velocities) and joint controllers which allow me to actually get the required wheel velocities. This is all done in ros_control.

Now I would like to drive my robot providing it with a desired trajectory (or desired target) and not with a twist (i.e. specify my trajectory in 6D position space, not in twist space). From what I understand, this is the aim of the navigation stack. But the navigation stack's wiki actually states the stack

requires a planar laser mounted somewhere on the mobile base. This laser is used for map building and localization.

Unfortunately my robot is not planning to integrate such a device. Does that mean the stack is unusable to me?

I am not sure I understand why there is such a hard requirement. There are plenty of uses cases for using other localization technique (e.g. triangulation, or video...), or even no localization technique at all (and thus accept drifts), and still expecting to transform a desired positional trajectory into desired velocities (to feed the controllers). Actually I am pretty sure some low layer of the navigation is doing just that. So isn't it accessible to robots having no laser?

Is it me not understanding things or is there something else? As you understood I am looking for a tool taking a desired trajectory or position in input and outputting corresponding twists...

Thanks,

Antoine.

edit retag close merge delete

Sort by » oldest newest most voted

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.

more

This looks promising... (I'll need to dig in bit in the docs now). Thanks for your help!

( 2014-10-24 09:15:45 -0600 )edit

I am using Robotino and I am having a kinect. Though I am new but I struggling very hard to create a map with my robotino. But unfortunatley I got the requirment for Laser. I am a stuent and wil not be provided the laser. I tried to create bag files which will be used to create map but it takes only

( 2016-08-16 09:50:26 -0600 )edit

LasreScan type msg. Then I tried to convert pointcoud2 to LaserScan and try to record the bag file. It creates some bag file but when i tried to save the map it says waiting for map and no response. It shound promising that without laser and faking I can create map but still I could not get the

( 2016-08-16 09:52:42 -0600 )edit

answere. If anyone of you have done map or navigation without using laser, can you provide me the tutorial link or sample work link or even if you have written in any blog to help. I am n seriusly trouble to find the solution. I am getting no clue for that. Thanks in advance.

( 2016-08-16 09:54:35 -0600 )edit

Without a Laser you can use fake_localization to localize the robot. It's basically using only odometry data.

more

I modified my launch file as here to replace amcl with fake localization and it worked!

( 2016-07-28 10:07:38 -0600 )edit

Working example: download and build and source rbx1 , and arbotix_ros for their Turtlebot configuration . Run roslaunch rbx1_nav fake_nav_test.launch to kick off the example, and visualise and control through rviz .

more

Well, actually the "hard requirement" for a laser only applies (as far as I know) to the default global_planner and the default local_planner. They both are plugins for the move_base node.

The global planner calculates a safe path from the current position of the robot to a goal position, given a known (usually static) map. Then the local planner calculates the Twist commands to send to the robot so it actually follows the global_path while taking dynamic obstacles (detected by the laser) into account.

The way the default local and global planer are implemented require a laser sensor to build the costmaps used for planning. But if you implement your own global and local planner, there should be no limit to what you can do.

I hope this helps.

[UPDATE]

As @ahendrix pointed out, I was wrong, the standard global and local planners don't need any laser information. They can be used with an empty or static map, so there is no need to implement your own global and local planners. The only thing you will be missing is dynamic obstacle avoidance.

more

2

Nope. The planners don't require any laser data at all. Of course, without it there's no obstacle avoidance, but it's entirely possible to use the default planners with an empty map, or with only a static map.

( 2014-10-24 03:04:58 -0600 )edit

Thanks for pointing that out. I'm going to update the answer

( 2014-10-24 03:25:02 -0600 )edit

Ha, interesting! Does that mean I do not even need to use fake_localization?

( 2014-10-24 03:54:00 -0600 )edit

Exactly @arennuit. @dornhege explained it very well, please mark his answer as the correct one.

( 2014-10-24 20:31:48 -0600 )edit

Okey dok. Thanks for your help Martin!

( 2014-10-25 05:29:35 -0600 )edit