-
Notifications
You must be signed in to change notification settings - Fork 37
Issues with upgrading to Kinetic - no ros master being launched #55
Comments
Hi Eric!
Let us know how this works out! |
Hi Alex, Thank you for the reply! We have not yet upgraded the MOVO1 and we are now in the process of trying to get this to function. We have successfully backed up MOVO1; however we are unable to gain access to the internet through the provided script. Is there anything that we may need to change in the script in order for MOVO1 to gain access to the internet? Thank you! |
Hi Eric,
needs the interface on which the Internet is on MOVO2. I put eth1 because my Ethernet to USB adapter was on this interface, but you have to put your own interface there (check out Hope this helps, |
Hi Alex, We were able to update both the MOVO1 and MOVO2 to Ubuntu 16.04 and did all of the necessary steps as outlined by the setup_movo_pc_migration script (I also reran both of these scripts after clearing all past installations to be sure). Both of the movo_ws's build perfectly and the ~/.bashrc hsa the correct aliases so that it uses systemd rather than upstart. Even with all of this setup, there is no ros master being launched and the movo still does not move. What may be the problem? Thank you! Best, |
We migrated to 16.04/kinetic a few months ago. Sounds you are having a systemd issue. have you tried manually launching the movo_system.launch in the bringup package? Also make sure you have your SSH keys setup as the roslaunch machine tags require movo2 to SSH into movo1. |
@belgiumkansas's tips are great starting points.
Cheers, |
Hi @belgiumkansas, Thank you for your suggestions. I just wanted to ask if you could clarify what you meant by setting up the SSH keys? Currently, we are able to ssh into movo1 from movo2. Would this be sufficient? @alexvannobel The Thanks again. Best, |
I just wanted to give you an update on my progress. I determined that there was most likely a networking issue so I went into both the similar errors to For movo1.launch I am getting Any advice would be helpful. Thank you! Best, |
Hi Jonathan, It seems indeed that your network config is not correctly setup. Cheers, |
Hi @alexvannobel, Thanks again for your help. There definitely seemed to be an issue with the networking. Now we have confirmed that MOVO2 has been set to master for both computers and ROS_IP is set accordingly to each computer. I am still, though, getting and error on MOVO1 with opening the sockets for various tasks. The first error that occurs is the following [ INFO] [1542217495.648300493]: Load description from: /robot_description I looked into the python script that is outputting this error and this error is caused when the following occurs in the constructor of the PanTiltIO self.cmd_buffer = multiprocessing.Queue() if (False == self.comm.link_up): I am not sure how I may fix this. Do you have any input? Best, |
Hi Jonathan, There doesn't seem to be any problem with this code, it is most likely a setup issue. ssh-copy-id movo@MOVO2 on MOVO2 : ssh-copy-id movo@MOVO1 Those commands will prompt you with entering the password, and will register the computer as a known SSH host. You can test it worked by ssh'ing to the other computer. Let me know if it fixes your problem! Cheers, |
Hi Alex, So I tried to ssh and was not prompted for a password. Just in case, I ran the above commands and was informed that the relevant hosts already exist. I am still able to ssh from one computer to the other without any problems. The issue with movo1.launch still seems to be a socket issue with movo pan_tilt. Just to provide some extra information, the movo's grippers open and close on startup (as usual), but does not continue with the startup. I was able to fix the socket errors by changing the sockets in multiple scripts located in movo_common/movo_ros/src/movo/ but there were still subsequent errors so I reverted the scripts back to what they were. Do you have any other suggestions? Thank you! |
Hi again Alex, We were just able to fix our movo. The problem was that the environment variable saying that movo has a 7 dof arm was set to false and the 6 dof variable was set to true on the kinetic devel branch by default, but out Movo has a 7dof arm, so moveit was failing on startup thinking the movo was in self-collision. After this success, we tried looking for rostopics and checking the data and noticed that the ROS_MASTER_URI is now set to MOVO1 instead of MOVO2. Is this something you guys did intentionally for the kinetic_devel branch? If not, how could we go about changing the ROS_MASTER_URI to be MOVO2 by default? We also noticed that a lot of the old kinect2 topics that we used to use on the Indigo branch are now gone. Is there any way we can get these topics back or is this by design? Thank you so much for all your help and speedy replies! It has really made this process much better. |
Hi Jonathan! I was about to provide you with some more tips but I'm glad to hear you got it working! I will look closer into the movo_config for the kinetic-devel branch to make sure the environment variables are set correctly because MOVO2 should really still be the master in ROS Kinetic. Thanks to you for your detailed explanations! Cheers, |
We're having similar issues after migration from Indigo to Kinetic. The grippers turn on and off for a bit, but the arms don't move. Appropriate changes to the variables have been made to |
Hello,
I am trying to upgrade our movo to kinetic. We first upgraded our system to 16.04, and then upgraded to kinetic. At first our movo_ws had issues building, but we were eventually able to resolve all the issues and get a fully-built movo_ws. However, even though we now have a built movo_ws, when we restart the movo, there is no ros master being launched, and it does not move at all on start up.
We also apt-get upgraded everything, but that still has not resolved the issue. Is there something we're missing in the upgrade process? How do we get the movo to launch the master ros node at launch so that we can actually use the movo?
Thanks!
The text was updated successfully, but these errors were encountered: