Nodelet Usage and it’s role in designing a complex controller

asked 2014-02-04 23:47:47 -0500

RB
221 ●41 ●46 ●60

updated 2014-04-09 07:45:13 -0500

Why nodelets are required? What are the advantages/disadvantages of it over normal nodes?
I have gone through the tutorial http://wiki.ros.org/kobuki/Tutorials/... Can anyone tell me what are the procedure to implement a velocity command multiplexer with normal nodes (for P3AT)?
Suppose, I have added mux.yaml ( http://wiki.ros.org/yocs_cmd_vel_mux ) and in the move_base.launch file , I include one more line:

rosparam file="$(find usarsim_inf)/mux.yaml" command="load"

So, whenever,I launch move_base.launch ; mux.yaml get loaded. But how I come to know that teleop and autonomous_behavior consult with this mux.yaml?

image description

I am using P3AT on ROS fuerte on Ubuntu 10.04.

Thank you for any help.

I have added a launch file which is in accordance with the ANSWER:

<launch>
  <node pkg="nodelet" type="nodelet" name="nodelet_manager" args="manager"/>

  <node pkg="nodelet" type="nodelet" name="mobile_base_nodelet_manager" args="manager"/>

  <node pkg="nodelet" type="nodelet" name="cmd_vel_mux" args="load cmd_vel_mux/CmdVelMuxNodelet mobile_base_nodelet_manager">

    <param name="yaml_cfg_file" value="$(find turtlebot_bringup)/param/mux.yaml"/>

    <remap from="cmd_vel_mux/output" to="mobile_base/commands/velocity"/>

  </node>

</launch>

Question : Is there any material which explains in detail about How Kobuki's control system use nodelets to switch among different controllers?

command to bring nodelet_manager and velocity_multiplexer

roslaunch cmd_vel_mux standalone.launch

and following is the example_cfg.yaml

subscribers:

name: "Teleoperation"

topic: "teleop_cmd_vel"

timeout: 0.3

priority: 10
name: "Navigation"

topic: "cmd_vel"

timeout: 0.1

priority: 0

UPDATED PART BELOW

What is the role of yocs_velocity_smoother?

I have tried to set the timeout as follows:

slow down (Navigation) : 0.1 (timeout is less, means teleoperation will take over)

speed up (teleoperation): 8 (we will wait longer amount of time.)

Even if the outcome is poor, autonomous navigation try to take over the control. Why autonomous doesn't wait for 8 seconds? If it goes like this then adding dynamic reconfigure server will not be fruitful for my experiment.

What may be the reason that the robot is not following exactly the example_cfg.yaml? Is it yocs_cmd_vel is for only Kobuki control system?

edit retag flag offensive close merge delete

Comments

You've specified a timeout of 0.8 seconds... not sure why you're expecting that to be 8 seconds.

ahendrix ( 2014-04-08 18:50:12 -0500 )edit

@ahendrix, I want to give more priority to teleoperation. Before declaring the /teleop_cmd_vel to be inactive topic for multiplexing, I want the timeout period to be more. So, that autonomous navigator of ROS will not snatch away the driving control. But, I am not getting the proper behavior that I am expecting. The autonomous controller snatch away the control before the 0.8 second (after setting the goal through rviz)

RB ( 2014-04-08 21:22:28 -0500 )edit

@ahendrix, I have updated the question.

RB ( 2014-04-09 07:38:12 -0500 )edit

yes. yes I see. Perhaps you can check out output rate from your teleop node? It may be timing out because the teleop isn't transmitting fast enough.

ahendrix ( 2014-04-09 08:14:36 -0500 )edit

@ahendrix, I have made the timeout parameter of teleoperation to be 180 seconds that is 2 minutes, but still the robot is not smoothly following the commands of teleoperation. I will add a video, then you may have a good idea about the whole scenario. What may be the reason behind this?

RB ( 2014-04-19 20:34:01 -0500 )edit

@ahendrix, I have added a new question http://answers.ros.org/question/155326/proper-working-of-cmd_vel_mux-for-velocity-multiplexing/

RB ( 2014-04-20 06:50:18 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2014-02-05 19:22:37 -0500

ahendrix

47576 ●179 ●367 ●662 http://namniart.com/

All of the documentation you're referencing is for a nodelet. Namely, the yocs_cmd_vel_mux nodelet. This PARTICULAR nodelet is the thing that actually implements the topic multiplexing you're looking for.

For the implementation, I recommend 3 launch files:

Your base controller and the multiplexer nodelet, including:
- the node for the base controller
- a nodelet manager
- the wrapper to load the yocs_cmd_vel_mux into the nodelet manager
- the configuration for the yocs_cmd_vel_mux ( mux.yaml )
Your navigation launch file
You teleop launch file

With this set of launch files, your multiplexer will always be available to pass velocity commands from navigation and teleop if they are running.

edit flag offensive delete link

Comments

cmd_vel_mux (http://wiki.ros.org/cmd_vel_mux) is written for Groovy/hydro. I am using P3AT robot on Fuerte. So can I use this package directly by simply modifying subscriber and publisher in the src folder? Is there any problem with communication between nodelet and normal nodes? I have seen in here http://www.isep.ipp.pt/roswiki/kobuki(2f)Tutorials(2f)Kobuki(27)s(20)Control(20)System.html Where mobile_base has to be a nodelet as well.

RB ( 2014-02-06 06:00:02 -0500 )edit

@ahendrix thanks for your answer. I have update the question to include the launch file. I am wondering whether we need to modify the source code of yocs_cmd_vel_mux? Or just adding the launch file in the package is enough for building velocity command multiplexer?

RB ( 2014-02-06 06:51:38 -0500 )edit

You shouldn't need to modify or even build the yocs_cmd_vel_mux; it should be part of the yujin_ocs stack for Fuerte ( `sudo apt-get install ros-fuerte-yujin-ocs` ). Nodelets work transparently with topics from regular nodes.

ahendrix ( 2014-02-06 07:43:37 -0500 )edit

@Brian Smith If you get your config file (priorities) and your remappings (velocity commands from navi and teleop to muxer, muxer to your base controller's vel input) right, everything should work without touching the code.

bit-pirate ( 2014-02-06 18:36:31 -0500 )edit

@ahendrix, @bit-pirate Thanks for the quick reply. My only concern is my robotic simulator. i.e I am using USARSIM (http://sourceforge.net/projects/usarsim/) 3D robotic simulator. The commands to base controller went through USARSim/ROS interface (http://sourceforge.net/projects/usarsimros/). Whether yocs will be compatible with this or not, I have to check.

RB ( 2014-02-13 03:09:52 -0500 )edit

@ahendrix The manifest.xml file present in cmd_vel_mux package which is included in yujin_ocs (fuerte) don't depend on dynamic reconfigure package. But here in the link http://wiki.ros.org/dynamic_reconfigure/Tutorials/SettingUpDynamicReconfigureForANode#fndef-c6236db8e93751d94e5d67da4ddd0c30c100d829-0; strictly tells us to do so.

RB ( 2014-03-05 18:05:28 -0500 )edit

@ahendrix, Hi, dynamic reconfiguration is not there with yujin_ocs(fuerte version). So, dynamic modification of yaml priority configuration may be hampered because of the absence of dynamic reconfiguration facility. Can we ADD it to YUJIN_OCS(FUERTE version)?

RB ( 2014-03-21 01:28:09 -0500 )edit

YES. You can check the package out, build it from source and add features as necessary.

ahendrix ( 2014-03-21 06:07:53 -0500 )edit

see more comments

answered 2014-02-06 11:23:44 -0500

jihoonl

634 ●11 ●17 ●21

What cmd_vel_mux does is not switching among the input velocities. It "overwrites" the velocity based on each input's priority setting in mux.yaml.

So if you want to "switch" controllers between two continuous input velocities, cmd_vel_mux may not work as you wanted.

edit flag offensive delete link

Comments

@jihoonl As you have said that velocity is overwritten means only one velocity command will flow to control the base_controller. It virtually achieves switching, I think.

RB ( 2014-02-06 17:38:32 -0500 )edit

The main difference is that cmd_vel_mux switches automatically based on messages appearing on a topic and the priority. A "normal" mux switches by specific commands. You'll just have to figure out what you want.

dornhege ( 2014-02-06 23:13:13 -0500 )edit

Yeah @dornhege explains what I meant correctly.

jihoonl ( 2014-02-09 11:50:51 -0500 )edit

I want dynamic modification of priority of the yaml files and I am going through the tutorial (http://wiki.ros.org/dynamic_reconfigure). If both topics contains messages, then I want my cmd_vel to switch based on priority. This priority must not be fixed all the time. Do you have any more suggestion? @jihoonl, @dornhege

RB ( 2014-02-13 03:16:02 -0500 )edit

You'll probably need to modify the cmd_vel_mux to add that functionality.

dornhege ( 2014-02-13 03:41:47 -0500 )edit

Sir, in my case, topic name is same (cmd_vel) for both teleop and move_base. Multiplexer facility says "Arbitrates incoming cmd_vel messages from several topics, allowing one topic at a time to command the robot, based on priorities". So, I have to modify the topic names like teleop_cmd_vel and auto_cmd_vel. Am I write? In yaml file, topics should be like these ; topic: "input/teleop_cmd_vel" and topic: "input/auto_cmd_vel"; am I write?

RB ( 2014-02-14 19:39:42 -0500 )edit

In yocs_cmd_vel_mux; if we modify mux.yaml dynamically can this be tracked by the follow up code which uses its priority field.? i.e we don't have to relaunch the mux.yaml.? Am I right?

RB ( 2014-02-16 06:33:12 -0500 )edit

Yes you are correct that the topics should be renamed as you said And you can reconfigure via dynamic reconfigure service without reloading mux.yaml.

jihoonl ( 2014-02-16 11:39:30 -0500 )edit

see more comments

Nodelet Usage and it’s role in designing a complex controller

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Nodelet Usage and it’s role in designing a complex controller edit

Comments

2 Answers

Comments

Comments

Question Tools

Stats

Related questions

Nodelet Usage and it’s role in designing a complex controller