Module API

feed_the_troll

This is the top-level namespace of the feed_the_troll ROS package.

feed_the_troll.feeders

class feed_the_troll.feeders.ROSParameters(server_namespace='', configuration_namespace='~parameters', add_shutdown_hook=True)[source]

Bases: feed_the_troll.feeders.Base

The generic feeder script should lookup parameters, enable remappings to handle setting of the constructor arguments. This interface is a programming interface only.

Warning

this blocks indefinitely if it can’t find the configuration server

feed_the_troll.trolls

class feed_the_troll.trolls.ROSParameters(loading_handler=None, unloading_handler=None, service_namespace='~')[source]

Bases: feed_the_troll.trolls.Base

...

load(request)[source]
Parameters:request (feed_the_troll_msgs.LoadFromParamServerRequest) –

feed_the_troll.servers

Various servers tailor made in the feeder-troll style to suit various purposes.

class feed_the_troll.servers.ReConfiguration[source]

Bases: object

About

Q) What to do when you need to share dynamic_reconfigure variables amongst a collection of nodes?

A good example is sharing navigation motion constraints amongst a collection of nodes that control the motion of the base (general navigation, parking, docking, ...)

This standalone node volunteers for the responsibility of loading and managing dynamic reconfigure servers from a central location. All you need do is feed it with a yaml/rosparam configuration that will define the dynamic_reconfigure servers you wish to fire up along with any initial parameter overrides to use when instantiating them.

It also manages these for free. That is, it is able to bring the dynamic reconfigure servers up and down in sync with the starting up and tearing down of your higher level applications.

Reconfigure your Reconfiguration!

Usage - Reconfiguration Server

You will need to prepare the following (no coding necessary!):

  • A yaml defining the dyn-recfg servers you need
  • A launcher for starting the reconfiguration server
  • A launcher for starting the feeder with your yaml configuration

If you’re familiar with nodelet managers and nodelets, this process is similar. When the feeder node launches it sends a request to the server to fire up the specified list of dynamic reconfigure servers. When it terminates, it will shoot one last service call off to the reconfiguration server to shutdown the previously started dynamic reconfigure servers.

Example - Reconfiguration Server

An example set of files (also available as a demo within this package):

<launch>
  <arg name="debug" default="true" doc="enable/disable verbose loading/unloading/updating information"/>

  <node pkg="feed_the_troll" type="reconfiguration_server.py" name="reconfiguration" output="screen">
    <rosparam command="load" file="$(find feed_the_troll)/parameters/demo_reconfiguration_server.yaml"/>
    <param name="debug" value="$(arg debug)"/>
  </node>
</launch>

feed it using this package’s parameter feeder:

<launch>
  <node pkg="feed_the_troll" type="param_feeder.py" name="$(anon feeder)">
      <rosparam command="load" file="$(find feed_the_troll)/parameters/demo_reconfiguration_feeder.yaml"/>
  </node>
</launch>

Usage - Reconfiguration Clients

Client programs that need to tune into the dynamic reconfigure servers simply need to instantiate a dynamic reconfigure client, or more simply, a subscriber listening to the dynamic reconfigure server’s private parameter_updates topic.

Examples - Reconfiguration Clients

Python:

from dynamic_reconfigure.client import Client
import functools
import rospy
import termcolor


def config_callback(config, namespace):
    print("")
    termcolor.cprint("Reconfiguration Client Callback", 'yellow', attrs=['bold'])
    print("")
    termcolor.cprint("  Reconfigure Client", "green")
    print("    " + termcolor.colored("{0: <23}".format("Name"), 'cyan') + ": " + termcolor.colored("{0}".format("dudette"), 'yellow'))
    print("    " + termcolor.colored("{0: <23}".format("Namespace"), 'cyan') + ": " + termcolor.colored("{0}".format(namespace), 'yellow'))
    termcolor.cprint("    Parameters", "cyan")
    for k, v in config.iteritems():
        if k != "groups":
            print("      " + termcolor.colored("{0: <21}".format(k), 'cyan') + ": " + termcolor.colored("{0}".format(v), 'yellow'))
    print("")
Variables:debug – print verbose debugging information on loading/unloading/updating
callback(config, level, name)[source]

The name is an additional argument not usually in a dynamic reconfigure server callback, but is fixed by a functools partial so that we can provide extra useful debugging information by stating which dynamic reconfigure server it relates to.

Parameters:
  • config (dynamic_reconfigure.encoding.Config) – dynamic reconfigure configuration object, holds all the variables
  • level (int) –
  • name (str) – name of the reconfiguration server for which these configuration variables apply
class feed_the_troll.servers.ReconfigureServerInfo[source]

Bases: object

A simple class holding current information about a running dynamic reconfigure server.

feed_the_troll.servers.namespace_from_configuration(server_name, server_configuration)[source]
Parameters:configuration (..) – troll reconfiguration server parameters (name, namespace, overrides)
feed_the_troll.servers.validate_server_parameters(server_parameters)[source]

Take in a reconfiguration setup on the parameter server (dic of dyn reconf server names with corresponding namespace, module & overrides values) and check if it is in a proper format as well as whether the module too exists.