-
Notifications
You must be signed in to change notification settings - Fork 2
Troubleshooting
You may see errors like the following:
- error launching XXX: No such file or directory
This and other similar errors are due to ROS being extremely picky about networking.
Firstly, check which network you're trying to talk to Q.bo on. The hostnames will be different depending on whether you are on the wired or the wireless connection.
Secondly, check the following:
- On your machine:
- Your hostname must match the name other machines use on the network. I.e. if your machine is called
student001then typingping student001on the Q.bo must reach your machine. - The
ROS_HOSTNAMEenvironment variable must be set to that hostname. - The
ROS_MASTER_URIenvironment variable must be set to, in this case,http://student001:11311. Replacestudent001as appropriate. - The command
ssh qbo@binkymust log you into the Q.bo without a password. Use the ssh-copy-id program.
- Your hostname must match the name other machines use on the network. I.e. if your machine is called
- On the Q.bo:
- Your hostname must be contactable by the Q.bo. I.e. the command
ping student001must work replacing your hostname as appropriate.
- Your hostname must be contactable by the Q.bo. I.e. the command
NOTE: When we use 'hostname', we mean 'hostname', i.e. student001, not student001.eng.cam.ac.uk which is a fully qualified name.
This is because the version of SSH shipped with ROS cannot understand the ~/.ssh/known_hosts generated by the latest SSH. Firstly remove the existing entry:
$ ssh-keygen -f "~/.ssh/known_hosts" -R binkyThen log in again forcing the use of the RSA algorithm:
$ ssh -oHostKeyAlgorithms='ssh-rsa' qbo@binkySee a related ROS forum answer.
Note: obsolete since we re-installed the Q.bo. The answer is left here because one may still encounter it if someone else has left a copy of qbo_arduqbo running.
If the qbo_arduqbo node keeps dying on the robot, then there's probably already one running. Unfortunately the Q.bo is setup to launch its own copy of ROS on startup. A quick way to kill this process is to run pkill via SSH:
$ ssh qbo@binky pkill -f qbo_startupCheck your ROS_HOSTNAME environment variable. (It should be binky if you're on the wired connection, for example.) As outlined above, ROS is very picky. If ROS_HOSTNAME is wrong but ROS_MASTER_URI is correct then you'll see the topic via rostopic list but no data will be published to them. This is confusing until you know the cause.
The ROS tf system is both a blessing and a curse. It is a blessing in that it handles a lot of the grunt work for us but it is very picky when it comes to time stamps. In general, you want rigidly connected things to be published on the same machine otherwise, even with NTP, the time stamps can get out of sync. A good example of this is the various static transform publishers in our qbo.launch file. These have to be run on the Q.bo itself so as to make sure the time stamps don't get out of sync with /base_footprint and /odom which are published by the Qb.o.
Note: rjw57 at least has lost a day to this.