DFKI-NI / mir_robot

ROS support for the MiR Robots. This is a community project to use the MiR Robots with ROS. It is not affiliated with Mobile Industrial Robots.
BSD 3-Clause "New" or "Revised" License
231 stars 157 forks source link

Issue with move_base - planner active yet an activate planner warning. #90

Closed AsadT-zz closed 3 years ago

AsadT-zz commented 3 years ago

Hello everyone,

I am using Ubuntu 16.04 with a kinetic distribution. The MIR version we have is a MiR 500 with firmware 2.7.9.2.

I made this package work on my computer. I was able to send the move_base_simple/goal from both commandline and RVIZ.

When I transferred the same package to my colleague. He is encountering a strange issue.

The mir_bridge connects perfectly. All topics work as expected as can be seen in the RVIZ screen shot.

RVIZ

However, when we send a 2D Nav Goal from RVIZ, we don't get any response. Instead we get a warning about the planner as shown under;

activate_planner_warning

The planner is working as it should. as shown below. Also from the MIR web-interface we can send mir anywhere perfectly.

MIR_planner_on

There is two way communication between the MIR and our PC. Because the RVIZ updates and shows the information as it should. Also, the 2D pose estimate works as it should. If I set it on the map. The laser scan changes and this change is registered as can be seen in this screen shot of the MIR system log.

systemlog_mir

The only thing different between my computer and my colleague computer is that I had to change the CMakeLists.txt to CMake minimum 2.8.3 from CMake minimum 3.5.1 to make it work otherwise during compiling it was asking for a Catkin_make_isolated.

Also my PC has a CMake version 3.5.1 installed while my colleague has 3.16.3 installed.

It is my hunch that this should not effect the goal sending. I would appreciate any help to get the goals to be sent to the MIR.

mintar commented 3 years ago

You're right, the CMake version doesn't affect this. You probably need to set the following environment variables correctly:

export ROS_MASTER_URI=http://<your-ip>:11311
export ROS_HOSTNAME=<your-ip>
# or: export ROS_IP=<your-ip>

Replace <your-ip> with the IP of the interface you're using to connect (wifi or ethernet).

The sort of problems you describe (subscribing between different PCs works, but publishing doesn't, or the other way around) is 99% caused by ROS_HOSTNAME not being set. Let's say you have two PCs with hostnames pc1 and pc2 with IPs 10.0.0.1 and 10.0.0.2, and you want to publish a topic from pc1 to pc2. This is what happens behind the scenes when you start a publisher on pc1:

  1. The publisher node (on pc1) opens a port and tells the ROS master the hostname:port combination where the publisher can be reached. If ROS_HOSTNAME is not set, the hostname will be used: pc1:45678.
  2. The subscriber node (on pc2) gets notified by the ROS master that there is a new publisher for the topic that the subscriber node is subscribed to.
  3. The subscriber node will try to connect to pc1:45678.

If the network you're using has a full DNS setup (which is mostly not the case), pc1 will be resolved to 10.0.0.1 and everything works. Otherwise, pc2 will not be able to ping pc1 and you're getting the error you described.

To fix this, run export ROS_HOSTNAME=10.0.0.1 on pc1 before starting the publisher node. This causes the value sent to the ROS master in step 1 to be 10.0.0.1:45678. Now, DNS is no longer required, and the subscriber node will happily connect to 10.0.0.1 in step 3.

N.B.: You can use ROS_IP or ROS_HOSTNAME, they are equivalent. If both are set, ROS_HOSTNAME takes precedence, so I personally always use that one.

AsadT-zz commented 3 years ago

Hi @mintar for the comment. I tried what you suggested. It still didn't work and the behavior was the same, but perhaps, I am not following properly.

So some background. The MIR IP is 192.168.12.20. I connect with it via Wi-Fi. It is automatic and I get assigned the IP 192.168.12.253.

When I open a terminal and check the environment variables. I get the following info: `ROS_ROOT=/opt/ros/kinetic/share/ros ROS_PACKAGE_PATH=/home/ali/catkin_ws_test_mir/src:/opt/ros/kinetic/share ROS_MASTER_URI=http://localhost:11311 ROS_PYTHON_VERSION=2 ROS_VERSION=1 ROSLISP_PACKAGE_DIRECTORIES=/home/ali/catkin_ws_test_mir/devel/share/common-lisp ROS_DISTRO=kinetic ROS_ETC_DIR=/opt/ros/kinetic/etc/ros

Since I want to publish the goals from RViz. In the terminal window. I did first: export ROS_MASTER_URI=http://192.168.12.253:11311 export ROS_HOSTNAME=192.168.12.253 As I expected the ROS_MASTER could then not be found by RViz. So I reverted it back to localhost and only changed the ROS_HOSTNAME

I launched Rviz and sent a goal. Underneath the screenshot of the environment variables and system log showing a websocket error. In this case I was still getting good data from the map and laser scan.

terminal-goal-environemnt

rosbridge_websocket

mintar commented 3 years ago

But you said you got it running on your PC, and it's not running on your colleague's PC, right? So we should focus on what the difference between those two PCs is. Double-check all software versions, git commits etc.

I did first: export ROS_MASTER_URI=http://192.168.12.253:11311 export ROS_HOSTNAME=192.168.12.253 As I expected the ROS_MASTER could then not be found by RViz.

"As expected"? No, I would expect it to work. Of course you need to run the two "export" lines in all terminals before you start any ROS processes. It's best to put it into your .bashrc. But I digress, since you're receiving laser scans etc., your ROS_MASTER_URI is working. I just wanted to make sure that you're not using the internal ROS master of the MiR platform.

mintar commented 3 years ago

I'm closing this issue due to inactivity. Feel free to reopen if you want to add something.