Ask Your Question

Multiple NAOs, one roscore

asked 2013-02-20 00:45:32 -0500

I.T gravatar image


I would like to use the nao_driver ros stack to control multiple NAO robots at the same time. Does anyone have any experience with this?

The nao_driver stack is run locally on a computer using a roscore instance on the same computer.

When launching nao_driver it uses an environment variable of the NAO robots IP which it then connects to. Ros topics are then available to publish commands to the NAO.

My guess is that if I launch multiple instances of the nao_driver (on the same computer) the ros topics will collide, i.e two topics "/cmd_vel" would be subscribed.

My idea for a solution is to modify the nao_driver stack so that it uses different topic names, for example specified by a launch file. I could then publish commands to for example "nao1/cmd_vel" or "nao2/cmd_vel" on order to make both nao1 and nao2 walk.

Is there a simpler/nicer way to do this?

Did I miss some basic ROS functionality for handling issues like this?

Thanks, Isak Tjernberg

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2013-02-20 01:44:57 -0500

Achim gravatar image

updated 2013-02-20 01:46:34 -0500

That is what namespaces are for. Either set the ROS_NAMESPACE environment variable before using rosrun or make a launchfile that contains a <group ns="naoX"> tag for each robot. There you can define the parameter with the IP and, if the driver nodes work properly (i.e. subscribing to "cmd_vel" and not "/cmd_vel", the topics should now read like /naoX/cmd_vel and so on.

If you want to use tf, you should also set the tf_prefix param and be sure that all software you use (and especially the one you develop) uses the tf methods to resolve frame_ids with the tf_prefix. Look for tf_prefix in the ros wiki.

edit flag offensive delete link more

answered 2013-02-20 02:06:18 -0500

Claudio gravatar image

It's easier done than said.

You have to learn the roslaunch syntax.

The process involves a few different concepts: hardware machines, conceptual machines, tf trees (at least).

The distinction between hardware machines and conceptual machines is paramount:

  • a hardware machine is a unix machine, ie a computer running your choice of OS, with a unique identifier, to which you need to be able to ssh into.
  • a conceptual machine is one of your Naos

What does this mean? I don't know the Nao stack, so I am generalizing here: most of times you have to run nodes that are local to the specific machines (for example nodes that communicate with hardware, like motor controllers and laser drivers) and nodes that don't need to be local (for example navigation nodes: they fetch the data flowing over the network, but don't need to run on the specific machine from which they are fetching their data).

So here is a launch file example

    <machine name="Nao01" address="Nao01.local" user="nao" default="false" env-loader="/opt/ros/<distro>/" timeout="180" />

This doesn't do anything but explains how you setup remote machines.

The next step is to determine where nodes will run (as said before: on the core machine, or on the remote machines).

        <machine name="Nao01" address="Nao01.local" user="nao" default="false" env-loader="/opt/ros/<YOUR_DISTRO>/" timeout="180" />
        <node pkg="nao-stack" type="navigation" name="nao_navi" />

        <!-- == NAO 01 == -->
        <group ns="nao_1">
        <param name="tf_prefix" value="nao_1"/>
        <param name="robot_description" command="$(find xacro)/ $(find nao_stack)/nao.urdf" />

        <!-- Robot State Publisher -->
        <node pkg="robot_state_publisher" type="state_publisher" name="state_publisher"/>       

        <!-- Nao Nodes -->
        <node pkg="nao_stack" type="driver" name="drive" machine="Nao01"/>
        <!-- == END NAO 01 == -->


This most probably won't work (paths and names are surely wrong) but should get you going.

Note the various type of nodes and where they are started.

Remember that to use roslaunch architecture your core machine MUST be able to log into the remote machines via ssh without password. That means loading the core ssh key into the remote machines, and granting it authorized_key status.

This should help you get started setting up ssh.

edit flag offensive delete link more

Your Answer

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

Add Answer

Question Tools


Asked: 2013-02-20 00:45:32 -0500

Seen: 304 times

Last updated: Feb 20 '13