0
$\begingroup$

Rosanswers logo

I have a robot on mecanum wheels and I installed on it a sensor able to provide x,y,z coordinates of its position at 10Hz. Morever, I placed four beacons in the four corners of the room in order to create a map.

I created a ROS node to publish /odom information:

rostopic echo /odom 
header: 
  seq: 3311
  stamp: 
    secs: 1584301150
    nsecs: 996412185
  frame_id: "odom"
child_frame_id: "base_link"
pose: 
  pose: 
    position: 
      x: 2.877
      y: 3.779
      z: 0.0
    orientation: 
      x: -0.018200000748
      y: 0.033900000155
      z: 0.00289999996312
      w: 0.999199986458
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
twist: 
  twist: 
    linear: 
      x: 0.0
      y: 0.0
      z: 0.0
    angular: 
      x: 0.0
      y: 0.0
      z: 0.00457195335154
  covariance: [0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0]
---

This is my TF tree: image description

Then, I run move_base:

rosrun move_base move_base 
[ INFO] [1584298281.544211877]: global_costmap: Using plugin "obstacle_layer"
[ INFO] [1584298281.550544640]:     Subscribed to Topics: 
[ INFO] [1584298281.556913732]: global_costmap: Using plugin "inflation_layer"
[ INFO] [1584298281.598466274]: local_costmap: Using plugin "obstacle_layer"
[ INFO] [1584298281.601248532]:     Subscribed to Topics: 
[ INFO] [1584298281.609893696]: local_costmap: Using plugin "inflation_layer"
[ INFO] [1584298281.664725185]: Created local_planner base_local_planner/TrajectoryPlannerROS
[ INFO] [1584298281.672399153]: Sim period is set to 0.05
[ WARN] [1584298281.677701194]: Trajectory Rollout planner initialized with param meter_scoring not set. Set it to true to make your settings robust against changes of costmap resolution.
[ INFO] [1584298281.865343424]: Recovery behavior will clear layer 'obstacles'
[ INFO] [1584298281.872604788]: Recovery behavior will clear layer 'obstacles'
[ INFO] [1584298281.996921593]: odom received!

and I publish the first goal:

rostopic pub /move_base_simple/goal geometry_msgs/PoseStamped '{header: {stamp: now, frame_id: "base_link"}, pose: {position: {x: 1.0, y: 2.2, z: 0.0}, orientation: {w: 1.0}}}'

I can see the robot IMMEDIATELY change its position in RVIZ, but if I read the cmd_vel topic, I always find ZERO values. Shouldn't move_base update the cmd_vel topic to send the values to a robot controller?

I just get this from cmd_vel:

linear: 
  x: -0.1
  y: 0.0
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.0
---
linear: 
  x: -0.1
  y: 0.0
  z: 0.0
angular: 
  x: 0.0
  y: 0.0
  z: 0.0

Originally posted by Marcus Barnet on ROS Answers with karma: 287 on 2020-03-14

Post score: 2


Original comments

Comment by gvdhoorn on 2020-03-14:
So is this related to #q340495?

If so, it would be nice to post a final answer/comment there so future readers know what you eventually ended up using.

Comment by Marcus Barnet on 2020-03-14:
It is the same project, but my previous topic is still open because I didnt find a correct solution, yet. I just want to explore this solution and to do so I need to know how to use the waypoint with this method. This topic it is just a branch of the previous one.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Move base in ROS1 or Navigation in ROS2 will do this for you.

There is no requirement of a "well-defined world", though that is as you have found a common application of it. If you are able to produce a global localization estimate, odometry, and some sensor data, you can make move base work for you.


Originally posted by stevemacenski with karma: 8272 on 2020-03-14

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by Marcus Barnet on 2020-03-14:
I edited my first topic by adding more information. I created a map and displayed it in RVIZ, now the robot related to "my_frame" is able to move inside the map. However, I cannot make it move towards waypoints with move_base. What should I do to solve this?

Comment by Marcus Barnet on 2020-03-14:
I have no sensors, I just have the beacon that gives me the robot coordinates.

Comment by stevemacenski on 2020-03-14:
"it doesn't move" doesn't help in debugging -- I'd recommend looking at any warnings or errors and addressing them. There are a variety of resources for properly configuring the navigation stack you should explore

http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide

http://wiki.ros.org/navigation/Tutorials/RobotSetup

Comment by Marcus Barnet on 2020-03-14:
Thank you for your answer. I have no range sensor, no encoders and no Odom frame. I just have my_frame which is the frame of the beacon installed on the robot. I have a transform from my_frame to base_link and my_frame to map. When I play the rosbag, i see my_frame moving in rviz. If i try to set a goal, nothing happens and if i try to rostopic echo cmd_vel, it says that no messages can be displayed.

Comment by Marcus Barnet on 2020-03-14:
I added more information after EDIT2 in the main topic. However, /cmd_vel, /odom and other topics are always not enabled since I get: WARNING: no messages received and simulated time is active. Is /clock being published?

Comment by Marcus Barnet on 2020-03-15:
@stevemacenski In the navigation tutorial, it says The navigation stack uses information from sensors to avoid obstacles in the world, it assumes that these sensors are publishing either sensor_msgs/LaserScan or sensor_msgs/PointCloud messages over ROS. but I have no laser! I just have the beacon installed on the robot and I need to move the robot towards a goal. Can't I use the move_base, then?

Comment by gvdhoorn on 2020-03-15:
Thing is, you're trying to use move_base for something which is not a standard configuration. You may not have the regular sensors, but as @stevemacenski already notes, you have something perhaps even better: an oracle which provides you with the absolute pose of your base_link (or at least, I'm assuming this, it's probably the pose of your tranceiver, but that's just a single transform away from base_link).

You'll need to make sure to provide the appropriate data to the nodes that expect it. At the very least, convert whatever your tranceiver outputs to (fi) a TF frame. Probably (but @stevemacenski correct me if/when wrong), broadcasting a transform between map and base_link directly, as you have no odom (or perfect odom).

move_base should be able to work with that.

One thing I don't understand though: if you have no sensors that will tell you anything about "the world", why bother with move_base at all? It sounds like a very heavy weight way ..

Comment by gvdhoorn on 2020-03-15:
.. to get at a 2.5D position controller for your platform.

Wouldn't a simple position controller be sufficient?

but I have no laser!

please stop fussing about not having a laser and consider things a bit more abstractly.

Take a step back and consider what's really important: the current pose of your base_link, the desired pose and any obstacles in between. If there are no obstacles, you don't care about that bit. So this leaves: current pose, desired pose. As long as you can feed move_base the current pose, it will be able to calculate Twists that will try to minise desired_pose - current_pose (ie: steer your base_link towards the desired pose).

But again: if that's all your interested in then even though move_base can certainly do this, I'm still not sure whether it's not a bit overkill.

Comment by Marcus Barnet on 2020-03-15:
Thank you again for your support! I already have a tf rosrun tf static_transform_publisher 0.0 0.0 0.0 0.0 0.0 0.0 my_frame base_link 1 and I set goals in this way: rostopic pub /move_base_simple/goal geometry_msgs/PoseStamped '{header: {stamp: now, frame_id: "map"}, pose: {position: {x: 1.0, y: 1.0, z: 0.0}, orientation: {w: 1.0}}}' but the 'cmd_veltopic is always blank. I could publish a/odom` since the beacon always outputs the x,y,z coordinates in meters plus the quaternion for the orientation. I do not care about obstacles, I just need to make the robot go straight from goal A and goal B. If I'm not forced to use move_base, how can I make the robot move towards a x,y point in a easier way?

Comment by gvdhoorn on 2020-03-15:
What is my_frame? Is my_frame broadcast by a node which takes the output of your "beacon driver" and converts it to a Transform?

Comment by Marcus Barnet on 2020-03-15:
I updated my first topic by adding the output of the node that contains the my_frame coordinates. I hope this helps

Comment by gvdhoorn on 2020-03-15:
A VisualisationMarker is not a TF transform.

move_base is going to need TF to know where your base_link is.

If you don't have a node which takes in the output from your tranceiver and broadcasts it as a TF transform, I would recommend you create one.

Comment by Marcus Barnet on 2020-03-15:
can you suggest me a tutorial, please? I'm trying to create a node that publishes odometry data for base_link, is this a good solution? I'm following this tutorial.

Comment by gvdhoorn on 2020-03-15:
That tutorial would cover it.

You probably don't absolutely need the Odometry publisher, but it doesn't hurt.

And you'd get your data from a Subscriber to the tranceiver's publications of course.

Comment by Marcus Barnet on 2020-03-15:
I changed my main topic to reflect the updates. Now, the odom topic works fine and the move_base moves the robot in RVIZ, but the cmd_vel reports always ZERO values. Why does this happen?

Comment by stevemacenski on 2020-03-16:
Hi,

It sounds like you're getting on the right track, but frankly, I don't have the cycles to help specifically go through every failure mode or issue that may arise from your application. I can tell you from first hand knowledge I've setup the navigation stack to work with a robot operating in an external frame source (motion capture). Its possible, but its going to require some legwork on your part to read the documentation, try to understand the purpose and roll of the components, and make reasonable decisions to get everything to work.

There is no requirement that anything in particular exists for the navigation stack beyond some source of odometry, some source of global positioning, and some sensors if you're not operating in a vacuum (which it seems you are). Please consult the documentation above and the plethora of examples online.

Comment by Marcus Barnet on 2020-03-16:
Just few questions: Does move_base already integrate the planner or do I need to configure one to make it work with move_base? Moreover, do I need to directly publish a move_base/feedback with the current position? Moreover, when I set a new goal, the frame moves in RVIZ accordingly, but the /odom odometry topic doesn't change its coordinates! So I think there is something wrong and that's for this reason that cmd_vel does not provide correct values but always ZERO.

Comment by gvdhoorn on 2020-03-16:\

I changed my main topic to reflect the updates

Please don't do this. All comments and answer(s) that were there before your update now don't make sense / are out-of-sync.

Append to your original question text. Structure it with Edit sections.

Comment by gvdhoorn on 2020-03-16:
re: your TF tree: why are you still publishing all these frames using a static_transform_publisher (STP)?

The whole idea is that you publish a transform based on the data your (global) positioning system is giving you. An STP cannot do this as it does not change, ever. You've essentially locked your robot into a single location, which is not what you'd want.

Just to clarify: odom is a separate topic. Unless there is a node taking in Odometry messages and somehow converting those to a TF frame (perhaps via sensor fusion, like robot_localization does), having an Odometry publisher will not be sufficient -- the TF side will be missing. move_base "only" looks at TF (not entirely true, but having the correct -- and working -- TF structure is very important).

From #q346761 it would appear you also have a TF broadcaster for the global position, so I'm not sure why you included the STPs.

Comment by Marcus Barnet on 2020-03-16:
As you said, I should not use the statis transform, that was an error and I corrected it; in effect, I already have a transform published by the /odom node. So, the TF between odom and base link is defined, but how can I definy a dynamic TF between map and odom? I do not have AMCL or gmapping (they even can't work since i have no laser) so how can I publish a TF for map and odom? I load the map with map_server. I can set map to be coincident with odom with a static TF, but I do not know if it can be OK.

Comment by Marcus Barnet on 2020-03-16:
After having followed the navigation tutorial, I created global and local costmaps, added the AMCL to my launch file, but when I launch move_base, when I try to send a goal, it says that No laser scan received (and thus no pose updates have been published) for 1584395127.621761 seconds. Verify that data is being published on the /scan topic. But obviously I have no laser sensor and my map is already created and I load it with map_server, I have no obstacles in it.

Comment by gvdhoorn on 2020-03-17:
I really don't understand why you start adding AMCL to this setup:

  1. you have no sensor for AMCL to use
  2. you already have a global localisation oracle available

Remove all of it.

You don't need a "dynamic TF between map and odom" necessarily. In the end, the transform map->base_link is needed. odom is added to that normally to account for drift in localisation approaches which depend on things like (noisy) odometry from wheel encoders, or laser scan matching, etc.

You don't have any of that (or: we'll assume the MarvelMind stuff provides a good global, absolute pose estimate).

Your "odom node" (which is not a good name btw) should probably publish either the map->odom or the odom->base_link transform. @stevemacenski: which one would make more sense?

Whichever TF it ends up publishing: use STP to broadcast an identity one for the other.

At this point TF should be setup.

Comment by gvdhoorn on 2020-03-17:
If you don't want to do this, take a look at wiki/fake_localization, which takes in nav_msgs/Odometry and broadcasting it as a Transform. Essentially imitating AMCL.

Comment by stevemacenski on 2020-03-17:
You still require a odom frame. I’d recommend having it publish odom at base link and just have an identity transform from map to odom if you really dont have wheel odometry, which I sort of doubt.

There’s going to be some trial and error if you don’t sit down and try to read documentation and code to fully understand. This part is no different.

Comment by gvdhoorn on 2020-03-17:
If there is already a global pose available through other means, would adding wheel odometry still be valuable?

Comment by Marcus Barnet on 2020-03-17:
I do not have wheel odometry, however, at the moment, after read all the documentation, I'm using an identity TF map->odom and it works, I had to define global and local costmaps and to add a local planner for holonomic robots and now it seems to work, I still have to test it better and I'm going to do it in the next hours, today. I do not like to have an identity TF between map and odom, honestly, but I didn't find any other suitable solution.

Comment by stevemacenski on 2020-03-17:
@gvdhoorn, yes it would be. It adds smoothing characteristics and projected updates between refresh cycles. You will only know your position at 10hz vs if you had odometry and accessed the pose through TF, you could have accurate updates at up to 1kHz. Maybe not required, but certainly part of a balanced breakfast.

I don't know why you don't like the identity transform, its a legitimate thing to do since you have global knowledge and no other odometry. Really, you should think of your external sensor as an external form of odometry not a word-from-god position.

Comment by stevemacenski on 2020-03-17:
If you have things working well enough, can you mark this answer as correct to get off the unanswered queue?

Comment by Marcus Barnet on 2020-03-17:
I will in few hours, i'm just trying to be sure that everything is OK.

Comment by Marcus Barnet on 2020-03-21:
I marked the question as solved since move_base is surely the package I need. I'm opening a new question since I'm still having problems not strictly related to this question. Thank you for all your support.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.