Ask Your Question
1

Set x,y goals and move the robot

asked 2020-03-14 10:20:25 -0500

Marcus Barnet gravatar image

updated 2020-03-15 14:46:07 -0500

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 thecmd_vel topic, I always find ZERO values. Shouldn't move_base update thecmd_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
edit retag flag offensive close merge delete

Comments

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.

gvdhoorn gravatar image gvdhoorn  ( 2020-03-14 11:12:35 -0500 )edit

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.

Marcus Barnet gravatar image Marcus Barnet  ( 2020-03-14 11:51:38 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2020-03-14 16:04:35 -0500

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.

edit flag offensive delete link more

Comments

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?

Marcus Barnet gravatar image Marcus Barnet  ( 2020-03-14 16:25:08 -0500 )edit

I have no sensors, I just have the beacon that gives me the robot coordinates.

Marcus Barnet gravatar image Marcus Barnet  ( 2020-03-14 16:29:47 -0500 )edit
1

"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/Tutori...

http://wiki.ros.org/navigation/Tutori...

stevemacenski gravatar image stevemacenski  ( 2020-03-14 17:19:17 -0500 )edit

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.

Marcus Barnet gravatar image Marcus Barnet  ( 2020-03-14 17:39:29 -0500 )edit

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?

Marcus Barnet gravatar image Marcus Barnet  ( 2020-03-14 19:00:25 -0500 )edit

@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?

Marcus Barnet gravatar image Marcus Barnet  ( 2020-03-15 05:16:53 -0500 )edit

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 ...(more)

gvdhoorn gravatar image gvdhoorn  ( 2020-03-15 05:22:23 -0500 )edit
1

.. 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.

gvdhoorn gravatar image gvdhoorn  ( 2020-03-15 05:26:04 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

3 followers

Stats

Asked: 2020-03-14 10:20:25 -0500

Seen: 1,029 times

Last updated: Mar 15 '20